Raine 0.92.1

[mer-curious]

2 hours ago, Tux said:

Well sorry but I don't see that here, in windows or in linux. Screenshots maybe, e.g screenshot of a game when loaded 1st and the same game when loaded 2nd to see this effect in action ? By the way sorry, I just noticed the function to take screenshots from raine in opengl is broken, that's probably the one you'd need here since by default it saves at the size of your screen, just take a screenshot of your window then...

This is interesting. I can reproduce it all the time with both the 32 and 64 bit versions. Well, here you have the screenshots. I hope you can notice the difference: https://imgur.com/a/VbWKKr0

 

2 hours ago, Tux said:

Tsss it was in the dlls for raine 32 bits of course... !

Yes, I'm sorry. I only looked at the 64 bit one.

 

2 hours ago, Tux said:

You messed up the SDL2.dll version, it used an old version here, just unpack the archive in the raine32 0.92.1 and it should get all it needs correctly, but anyway now that you have what looks like a working mapping you don't really need that anymore.

So, I unpacked the dlls32-0.92x.7z in the same folder of the controller program and now the Testgamecontroller.exe finally worked. This is my results:

- with my d-input controllers the window title shows "Waiting for controller..." and it doesn't react if I press anything in these game pads.

- with my X360 controller the window title shows the name of the game pad and I can test all the inputs.

So there seem to be some kind of incompatibility with simple d-input controllers, no?

 

2 hours ago, Tux said:

And I have another question then, already : I actually didn't know when using sdl-1.2 that some gamepads handled the dpad as a hat when some others handled it as buttons, yours are both handling it as a hat apparently.
So the question is : in raine < 0.92, it tried to remap the events coming from a hat to joystick events, so how did it work ? You could use it for movement, or not at all ? Or could you remap it to something else, buttons actions ?
This code is not supposed to be used anymore if your controller is correctly recognized as a gamecontroller, which will be the case if we add these mappings you just made, so it's interesting to know how it worked before that...

The versions before the SDL2 update would automatically assign the directions to "Stick 0" as we have in Raine SDL2, but this stick doesn't seem to exist in my d-input controller, which is a Hori Fighting Commander 3. So I had to manually reassign the directions to be able to use the d-pad with this controller. When I remap the directions Raine calls them "Stick 2", as you can see here: https://imgur.com/a/bxE2iOK

So it worked pretty much the same as with the SDL2 update, except that I could use the d-pad in-game, while with the recent versions I cannot.

 

2 hours ago, Tux said:

We're not in a hurry so I'll wait at least a day to see if I get some news from your blurry effect, but I am starting to have a few interesting changes for a new release, even if this time there are not many changes... I'll release the next one for windows with your mappings as an external file "mappings" in the archive, you'll be able to test with and without it to see the difference...

Ok, thank you so much for your time and help again! I should certainly give you some feedback after testing it. 👍

Edited December 8, 2021 by mer-curious

[Tux]

26 minutes ago, mer-curious said:

This is interesting. I can reproduce it all the time with both the 32 and 64 bit versions. Well, here you have the screenshots. I hope you can notice the difference: https://imgur.com/a/VbWKKr0

On your screenshots sure, but you have to look carefully, I probably missed it in the emu, I'll have a closer look tomorrow... (1:40am here).

26 minutes ago, mer-curious said:

 

Yes, I'm sorry. I only looked at the 64 bit one.

It was for xp originally, even if I heard a 64 bits xp exists, it's quite rare... !

26 minutes ago, mer-curious said:

 

So, I unpacked the dlls32-0.92x.7z in the same folder of the controller program and now the Testgamecontroller.exe finally worked. This is my results:

- with my d-input controllers the window title shows "Waiting for controller..." and it doesn't react if I press anything in these game pads.

- with my X360 controller the window title shows the name of the game pad and I can test all the inputs.

So there seem to be some kind of incompatibility with simple d-input controllers, no?

It's not some incompatibility, it's just you have 2 gamepads which are not recognized, the ones you sent the mappings... They can still be accessed as normal joysticks, but in this case we don't know how the inputs work...

26 minutes ago, mer-curious said:

 

The versions before the SDL2 update would automatically assign the directions to "Stick 0" as we have in Raine SDL2, but this stick doesn't seem to exist in my d-input controller, which is a Hori Fighting Commander 3. So I had to manually reassign the directions to be able to use the d-pad with this controller. When I remap the directions Raine calls them "Stick 2", as you can see here: https://imgur.com/a/bxE2iOK

Stick 0 is the default input, movement assigned to 1st stick, but yeah it doesn't know what stick 0 is for (it must exist though !), well if you use the mappings you sent, default inputs for movement will be assigned to the left stick you chose in your mapping.

26 minutes ago, mer-curious said:

So it worked pretty much the same as with the SDL2 update, except that I could use the d-pad in-game, while with the recent versions I cannot.

Yeah because of the removal of the code for the hats ingame, I was too confident about this part, I took it back for now.

26 minutes ago, mer-curious said:

 

Ok, thank you so much for your time and help again! I should certainly give you some feedback after testing it. 👍

I'll look into your blurring effect tomorrow, it shouldn't be too long, thanks for the infos !

[Tux]

For your filtering issue, not sure it's fixed, all I found is the filtering option for sdl2 itself (that's what is used in sdl2 native mode and also when displaying the animation behind the gui), so I fixed that to follow the open gl setting in rendering option (linear or nearest). But for opengl rendering itself, the filtering option is enforced for every frame, so I don't see how it could create problems here, if you still have some problems you'll have to give more details with a precise way to reproduce that and I'll try that in windows... Anyway 0.92.2 released, thread change !

Edited December 8, 2021 by Tux