Raine 0.92.4

[Tux]

Finally more time to finish this one... I even thought about adding something new to emulate for a while, but too many things to do for that for now, maybe later... So the main fixes are around the game controllers, and the dead zone of some which canceled the moves from the d-pad. Also there are about 100+ new recognized game controllers for linux, and 400+ for windows ! (more people would use windows ? What a surprise !). All these new controllers mappings come from there : http://raine.1emulation.com/download/latest.html
The other big part is the improvement for cps2 rasters, and the priorities in xmvsf, notice the priorities are still not perfectly emulated, there are probably places left in some cps2 games where there are problems.

Except that most of the emulated games are now rendered in 16bpp because most of the emulated games have color palettes of 16bpp or less. 2 exceptions : the taito f3 games, and macross +, for these 2 it's still 32bpp, for all the others it's 16bpp. The reason ? Smaller bitmaps, so it's faster to draw and faster to render to screen.

And there were problems with some taito f3 games, especially in 64 bits, but even in 32 bits there was a black screen for puchcar on boot because of a recent fix. All this should be fixed now... It's almost a Christmas version this time !

http://raine.1emulation.com/download/latest.html

Edited December 19, 2021 by Tux

[mer-curious]

😊 Hey Tux! First of all, thanks a lot for this new release. 🙏 Since I was the one who reported most of the issues in the 0.92.3 thread, I was really eager to test this new version. So, here's my quick feedback:

- 😞 I'm sorry to inform that I still experience the same issue with the controllers in this new version. The Left/Right directions continue stopping registering out of a sudden if you press and hold them. I only tried it with my DS4 controller, but I suppose that if I can reproduce it with this controller it may affect other pads as well eventually.

- I don't know if I've already reported this, but my PS4 controller's d-pad doesn't work in the GUI in any of the SDL2 versions. It works fine in the SDL1.2 versions though.

- The Apocalypse stage in X-Men vs Street Fighter is much better now. Thank you for your work on that. However, these fixes have introduced a small graphical glitch in the pre-stage screen in which the characters face each other before the match. There is a gray wall of dozens of X-men vs Street Fighter logos that works as a transition animation from the versus screen to the fight stage. Normally this animation hides all the elements in the screen, but now it is showing behind the characters in the versus screen. Take a look: https://imgur.com/a/NArIA2t

Version 0.92.3 showed this effect correctly, but the current version presents this glitch. I'm reporting just in case you're unaware of this side-effect. If you'd like another save-state in a point shortly before the versus screen, here it is: https://drive.google.com/file/d/1CBdZuJYqKM3HCUzrHWyXk_dO0MAQIBLj/view?usp=sharing

By the way, this state shows a message when I load it. I don't know why, but it works after confirming.

Well, I guess that's my feedback for now. Thank you so much again for your continuing work. 👍

Edited December 20, 2021 by mer-curious

[Tux]

5 hours ago, mer-curious said:

😊 Hey Tux! First of all, thanks a lot for this new release. 🙏 Since I was the one who reported most of the issues in the 0.92.3 thread, I was really eager to test this new version. So, here's my quick feedback:

- 😞 I'm sorry to inform that I still experience the same issue with the controllers in this new version. The Left/Right directions continue stopping registering out of a sudden if you press and hold them. I only tried it with my DS4 controller, but I suppose that if I can reproduce it with this controller it may affect other pads as well eventually.

I am sorry to inform you that in this case, inputs -> d-pads for movement : no

You'll still be able to use the d-pads for movement by mapping them explicitly. Sorry the dead zone is too big here, these pads were not supposed to have one in the beginning and I won't resurrect the old calibration screens because of that.
Try that and see how it works...

5 hours ago, mer-curious said:

- I don't know if I've already reported this, but my PS4 controller's d-pad doesn't work in the GUI in any of the SDL2 versions. It works fine in the SDL1.2 versions though.

Curious... I can't test one now, maybe one day.

5 hours ago, mer-curious said:

- The Apocalypse stage in X-Men vs Street Fightder is much better now. Thank you for your work on that. However, these fixes have introduced a small graphical glitch in the pre-stage screen in which the characters face each other before the match. There is a gray wall of dozens of X-men vs Street Fighter logos that works as a transition animation from the versus screen to the fight stage. Normally this animation hides all the elements in the screen, but now it is showing behind the characters in the versus screen. Take a look: https://imgur.com/a/NArIA2t

Version 0.92.3 showed this effect correctly, but the current version presents this glitch. I'm reporting just in case you're unaware of this side-effect. If you'd like another save-state in a point shortly before the versus screen, here it is: https://drive.google.com/file/d/1CBdZuJYqKM3HCUzrHWyXk_dO0MAQIBLj/view?usp=sharing

By the way, this state shows a message when I load it. I don't know why, but it works after confirming.

Well, I guess that's my feedback for now. Thank you so much again for your continuing work. 👍

Yeah it's a side effect of what I chose to do here, since I don't have the masks for the priorities I decided that these big 32x32 sprites should mostly be use for background and not foreground, so I force them in the background when they are at the highest priority. It allows to have the shoulders of the giant drawn correctly. I'd say this glitch is minor in comparison, for now I can live with it...

[Augusto]

0.92.4 controller d-pad hold issue was fixed.

Thanks :)

[pmc2]

hi,
unfortunately this version is clearly worse than the previous one for controls, there is no doubt.
In fact, the controls no longer work correctly again. We can adjust all the keys in the menu, but it does not match in games (at the level of the directional cross).

 

edit: well I delete all the config and I start again and again, and I see, it may be a conflict.I will keep you posted

edit2: remove gamecontrollerdb.txt  and joypad D work again.
          So file is useless in my case (but what should it be used for originally?).

Ps: I noticed that there are no more "mappings" in the root

Edited December 20, 2021 by pmc2

[Tux]

1 hour ago, pmc2 said:

hi,
unfortunately this version is clearly worse than the previous one for controls, there is no doubt.
In fact, the controls no longer work correctly again. We can adjust all the keys in the menu, but it does not match in games (at the level of the directional cross).

 

edit: well I delete all the config and I start again and again, and I see, it may be a conflict.I will keep you posted

edit2: remove gamecontrollerdb.txt  and joypad D work again.
          So file is useless in my case (but what should it be used for originally?).

Ps: I noticed that there are no more "mappings" in the root

the old mappings which contained only 2 mappings was replaced by this file gamecontrollerdb.txt, which contains 100+ mappings for linux and 400+ for windows.

I don't understand why you have problems with it, and it would be too long to test and I am really tired of it. I don't have the 400 controllers used to make this, and I am glad I don't have them because I wouldn't have the patience to test all that.

I'll probably make "d-pads for movement" = "no" the default for next version, which will avoid this kind of posts.

[Tux]

Ok, since I forgot to upload the linux version last night, I took the time to fix the dpad in the gui which I completely forgot. Actually xbox controller dpad worked, it's only the playstation dpad which didn't work since it isn't advised as a hat. For info in sdl-1.2 versions the playstation controller had no chance to see its dpad work in the gui because it wasn't seen as a hat at all. Anyway now the hat works in the gui only if the controller is recognized, otherwise you'll just have to use the stick or the keyboard.

There was also a small bug in dealing with controllers events, this one probably could show only if using more than 1 gamepad at the same time. So I'll upload 2 new binaries with the same version number. Just check the compilation date it should show december 20... there is no proxy on this server afaik, so redownloading the file should work without problem.

Just uploaded the 2 new windows binaries, and the 2 linux packages, mission done, merry christmas, and see you later !

edit : oh, and also I took back the options to control the automatic repeat of joystick events in the gui. They were removed from sdl2 for the bad reason that it's easy to do without it, actually I used only the 2 constants for the default delay and then interval for the auto repeat. Anyway it's back in the options, and it works (and the default interval is now 50 instead of 30, which was too fast).

Edited December 20, 2021 by Tux

[mer-curious]

9 hours ago, Tux said:

I am sorry to inform you that in this case, inputs -> d-pads for movement : no

You'll still be able to use the d-pads for movement by mapping them explicitly. Sorry the dead zone is too big here, these pads were not supposed to have one in the beginning and I won't resurrect the old calibration screens because of that.
Try that and see how it works...

Hey Tux! Thanks for the tip and for the quick update on the d-pad GUI navigation. I didn't know you had added an option to address the cases in which the controller doesn't work correctly. After changing it to "No" and manually reassigning the directions, I was finally able to use the d-pad in the game correctly as far as I've tested. Thanks again for that! 👍

 

9 hours ago, Tux said:

Yeah it's a side effect of what I chose to do here, since I don't have the masks for the priorities I decided that these big 32x32 sprites should mostly be use for background and not foreground, so I force them in the background when they are at the highest priority. It allows to have the shoulders of the giant drawn correctly. I'd say this glitch is minor in comparison, for now I can live with it...

Ok, no problem. Thank you so much for the thorough explanation, as always. 👍

 

6 hours ago, Tux said:

I'll probably make "d-pads for movement" = "no" the default for next version, which will avoid this kind of posts.

Maybe this would be indeed the better to do for the time being so new Raine users don't eventually experience the "d-pad issues" with their controllers in Windows. Also, the option is not so clear the way it is currently written because by changing it to "No" you don't actually disable the d-pad for movement "at all", you just have to reassign it manually in the game inputs. So what do you think of renaming it to something like "Enable analog stick to d-pad simulation" with options such as "Yes" or "No"?

By the way, I've noticed that setting this option to "No" doesn't fix the issue with the directions in the GUI, that is, if I try to navigate with my PS4 controller's d-pad in the GUI the up and down directions will still eventually stop registering just as happens with the games. This makes it a little difficult to scroll through the GUI in places such as the game list or the game history (if you're looking for hints or just game curiosities). I know I could simply use the analog stick instead, but perhaps this option could also make the d-pad fully usable in the GUI environment?

As a final report, I was able to test the "blank screen" issue with an NVIDIA GPU and unfortunately it showed there too. This was something introduced with the SDL2 update.

Anyway, that's it for this post. Thank you so much again for your time and work! 👍

[Tux]

1 hour ago, mer-curious said:

Maybe this would be indeed the better to do for the time being so new Raine users don't eventually experience the "d-pad issues" with their controllers in Windows. Also, the option is not so clear the way it is currently written because by changing it to "No" you don't actually disable the d-pad for movement "at all", you just have to reassign it manually in the game inputs. So what do you think of renaming it to something like "Enable analog stick to d-pad simulation" with options such as "Yes" or "No"?

Maybe it can be improved, but it's not a simulation... we'll think of something eventually...

1 hour ago, mer-curious said:

By the way, I've noticed that setting this option to "No" doesn't fix the issue with the directions in the GUI, that is, if I try to navigate with my PS4 controller's d-pad in the GUI the up and down directions will still eventually stop registering just as happens with the games. This makes it a little difficult to scroll through the GUI in places such as the game list or the game history (if you're looking for hints or just game curiosities). I know I could simply use the analog stick instead, but perhaps this option could also make the d-pad fully usable in the GUI environment?

It works when you put the setting to no because it's back to what there was for the sdl-1.2 version : the d-pad totally separated from the sticks, that's also why after that you need to reassign it in the inputs if you want to use the d-pad. But the gui accepts movement from everywhere : the left stick, the right one, or the d-pad ! So your problems are back for good, the move is canceled again here. Well as long as the sticks are not used for analog inputs maybe the dead zone can be increased... Not sure about that, I'll try to borrow a ds4 controller to see how it behaves in windows... I thought 2500 was already very big for a dead zone, it's quite scary that this thing needs something bigger, for me everything works perfectly here with these settings (ok I almost never play in windows...). For now you can always use the stick or the keyboard, autorepeat works with the sticks too, or use the keyboard it's way faster to control the gui !

1 hour ago, mer-curious said:

As a final report, I was able to test the "blank screen" issue with an NVIDIA GPU and unfortunately it showed there too. This was something introduced with the SDL2 update.

Anyway, that's it for this post. Thank you so much again for your time and work! 👍

There were much worse cases with the sdl-1.2 version, that was the main reason for upgrading to sdl2, and I delayed it as much as possible.

Here I can't reproduce it for now, and it's easy to work around, you don't switch from windowed to fullscreen all the time if you save your settings, and when it happens just press esc to call the gui and have everything back to normal, so it's manageable. If you want to test, the other rendering option "sdl2 native" probably doesn't have this problem, but yeah it has a lot less settings too !

[Tux]

Got a new idea for this mess between d-pads and sticks, and easy to implement, so I just uploaded a new binary still with the same version, compilation date december 21st this time, I hope it will be the last !

The idea is very simple, I should have thought about it earlier : when receiving an event from the d-pad, just cancel any event coming from the sticks until a stick move of at least 16000 in value, which is half the maximum distance it can move in any direction. This replaces the previous dead zone detection which didn't work with some models.
This filtering is done for the games and for the gui, so it should fix everything.

Update for linux unnecessary since linux does that at its driver level !

(the idea came while playing a native windows game which was using the ps3 gamepad, I could use their menu using the d-pad, so it occurred to me that the only way for this to work in windows reliably was to cancel the stick events in this case... ! The game very probably used sdl2 for its input)

Edited December 21, 2021 by Tux

[Robert]

Happy Christmas to you, thanks for all the work you're putting into this. It must get quite frustrating at times.

I don't have any controllers, sticks, whatever - just keyboard - so none of these reported issues show for me.