Raine 0.92.3 : mer-curious version !

[Tux]

Yeah I think I can call it like that, that's him who reported all the bugs to fix, with great descriptions to be sure to be understood, he was perfect on this one, even if I was a little disappointed to see 0.92.2 disappear so fast ! Anyway here are the fixes this time :

 - the sound associations were deleted if you loaded any game which had some. This reason alone was enough to make a new binary to avoid that people delete all their associations !
 - yet another gui problem where the loading dialog was zoomed too much. Fixed, and the default is now to use opengl for rendering, which makes much more sense since it has more options and is much more tested.
 - cps2 rasters are better, see the details in the 0.92.2 thread if you want to know how.
 - and the joysticks configuration changes again, which obliged me to reset again the keys configuration since they are saved with the keys. Sorry, it should be the last time I do that. This fixes a conflict between the hat of a gamepad and a stick direction if the gamepad was not recognized as an sdl2 game controller. This one was hard to precisely pinpoint, but anyway it's fixed too.

Very few changes, but they were necessary. I hope to rest longer this time !

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

[Tux]

A short word on the linux version : I forgot to update it yesterday, just did it, and I noticed I forgot to update the new dependencies for version 0.92 (sdl2, sdl2_ttf, sdl2_image instead of sdl, sdl_image, sdl_ttf). That's a weakness of this PKGBUILD, dependencies are not dynamic. There was also an old dependency to GLU, I don't even remember why it was added but it's been ages since it's not needed anymore, fixed that in the makefile too. So there is a brand new PKGBUILD for this version, and I slightly updated the text on the download page to tell the 32 bits and the 64 bits packages are now built using only standard libs from the standard repository since sdl_sound was merged into the source of raine.

[mer-curious]

Hey Tux! I have some good and bad news about this new version. The good news are:

- the sound associations are working again.
- the glitch in the "loading game" progress bar has been fixed.
- the lava stage in Marvel Super Heroes is looking good now.
- I can now use one of my controllers (the one without an analog stick)

The bad news:

- it seems that the raster effects has made the Apocalypse stage in X-Men vs. Street Fighter look really bad. The character stays behind the floor, Apocalypse is blending with the scenery and part of the background is cut. Take a look: https://imgur.com/a/BOJTqUW

I have made a save-state just before this stage is loaded so you can quickly check it: https://drive.google.com/file/d/19-nmRTCsGOk3jRsHWnmQ9t67LywESNXb/view?usp=sharing

Beware that if you load this state after the stage has been loaded, Raine will crash!

- If I leave full-screen mode after a game has been loaded, the windowed screen will be blank. See: https://imgur.com/a/RUMYkdN

Even though the screen is blank, the game continues running because I can still listen to the game sound playing.

- the controller issue persists with my ASCII Seamic controller, but now it doesn't get stuck in the directions. What I'm experiencing now is that I cannot perform the special move "shoryuken" facing left (player 1 side). To be sure that it wasn't me failing the execution of this command I tried Raine 0.91.18 and FBNeo and I could repeatedly perform this movement there. It's an issue that happens eventually, so perhaps it's being triggered by something else.

- I've bought a brand-new Dual Shock 4 controller which arrived this weekend and I'm having the same "stuck directions" issue with it. There seem to be something not right yet with the SDL2 update. I generated the mappings for this controller with the Controller program you provided and then placed the data in the mappings file. Sadly it didn't fix it. Perhaps you could try your PS3 controller in Windows with the DirectInput driver I linked in the other thread and see if you could reproduce this issue there. The PS3 and PS4 controllers are very similar in design and functions, I guess. 🤔

Anyway, I'm sorry for bothering you again with this controller issue. Thank you for your time and help, as always.

PS: I don't know if this matters, but the ASCII Seamic controller has one analog stick, the PS4 controller has two, and the Hori Fighting Commander 3 (the only one which is working correctly now) doesn't have any. I don't have any of these issues with the controllers in the Raine SDL1.2 versions.

Edited December 13, 2021 by mer-curious

[Tux]

Just some quick reply for your gamepads before going to bed : Last time I heard about your gamepads, you had 2 gamepads recognized as game controllers because of the mappings you sent and everything worked fine. Now you buy a new one, and 2 gamepads get broken ? !!!! It doesn't make any sense, I don't know what you are doing with that but it sounds crazy !

Anyway it was useless to try to make a mapping for a dual shock 4, it's recognized out of the box since it's a recent controller, you should know by now that if you see "leftx" or "lefty" instead of "stick 0" it means the gamepad is recognized and doesn't need any mapping.

No I won't change my driver on my side, I don't have an official driver, I have something unofficial, at the time we didn't even think sony would make an official driver... and no I don't want to change a setup which works, it's windows, it might explode if I change anything !

Anyway, just load a game like sf2, go into the dipswitches and select test mode in the last dipswitch. Once in the test mode, navigate to io test using the keyboard and not touching your gamepads before you are there, then inputs. When finally you are on the inputs screen try all your gamepads inputs 1 by 1 until you find the one which leaves a direction stuck, and report. Good luck, !
You can try that with or without the mappings file, but maybe it's better to use the one which was in the archive before you modified it...

Edited December 13, 2021 by Tux

[mer-curious]

2 hours ago, Tux said:

Just some quick reply for your gamepads before going to bed : Last time I heard about your gamepads, you had 2 gamepads recognized as game controllers because of the mappings you sent and everything worked fine. Now you buy a new one, and 2 gamepads get broken ? !!!! It doesn't make any sense, I don't know what you are doing with that but it sounds crazy !

Hey Tux! Thanks for the quick reply!

So, as I reported in the other thread both of these game-pads I have were having issues with Raine SDL2. The Hori pad seems to be working good after the 92.3 upgrade, so I could finally play a little to the test the rasters in X-Men vs. Street Fighter. But the ASCII controller sometimes presents the issue related to the directions. Now with the DS4 I can confirm that something is still not quite right in this SDL2 update.

 

2 hours ago, Tux said:

Anyway it was useless to try to make a mapping for a dual shock 4, it's recognized out of the box since it's a recent controller, you should know by now that if you see "leftx" or "lefty" instead of "stick 0" it means the gamepad is recognized and doesn't need any mapping.

Yes, I noticed that Raine names it as "PS4 Controller" while Windows calls it just "Wireless Controller", which is the name associated with the default Direct Input drivers. "PS4 Controller" is probably how it is registered in the SDL controller database.

 

2 hours ago, Tux said:

No I won't change my driver on my side, I don't have an official driver, I have something unofficial, at the time we didn't even think sony would make an official driver... and no I don't want to change a setup which works, it's windows, it might explode if I change anything !

Perhaps you are not having any problems with your PS3 controller in Windows because this unofficial drivers works with XInput? This would make Raine think you're using an XBox 360 controller, which seems to not be affected by the issues I'm experiencing.

Now I'm curious if Augusto was using official (Direct Input) or unofficial (XInput) drivers... 🤔

 

2 hours ago, Tux said:

Anyway, just load a game like sf2, go into the dipswitches and select test mode in the last dipswitch. Once in the test mode, navigate to io test using the keyboard and not touching your gamepads before you are there, then inputs. When finally you are on the inputs screen try all your gamepads inputs 1 by 1 until you find the one which leaves a direction stuck, and report. Good luck, !
You can try that with or without the mappings file, but maybe it's better to use the one which was in the archive before you modified it...

Thank you for suggesting this test. Now I think I have a clearer understanding of what's going on.

According to my observation, the issue is related to detecting the continuing input of the directions. For example, if you press and hold up + right, one of the directions will eventually stop registering. It mostly happens with diagonals, but also with straight directions, for example, just left or right. That's why the commands would fail and the character would suddenly stop in the game if going back or forward. Curiously, when I tested my PS4 controller it was registering the directions correctly, but then I started playing with the buttons a little longer doing some commands such as "hadouken" and "shoryuken", and the problem appeared. So perhaps something is triggering it?

Anyway, here is a summary of my testings in the Input test menu of Street Fighter 2 - Champion Edition:

Dual Shock 4: the issue is easily reproduced after it is triggered
Ascii Seamic Controller: the issue happens sometimes
Hori Fighting Commander 3: the issue happens more rarely
XBox 360 controller: I could not reproduce the issue with this controller

For the controllers which have analog sticks (Ascii, DS4 and X360), I couldn't reproduce the bug by using their analog sticks. The issue looks to be related to the d-pad solely.

One thing I noticed about the X360 pad is that sometimes Raine doesn't recognize it and then I'm unable to use it even in the GUI. I have to close and open Raine again and see if it is working. Maybe it could be a problem with XInput detection?

Anyway, I hope this can help you figure out the source of this problem. Thanks again for your time. 🙏

Edited December 13, 2021 by mer-curious

[Tux]

You describe a low level problem, either hardware or driver level but more likely hardware : a direction which can't be maintained. Nothing comparable to the problem fixed in 0.92.3 where as soon as an unmapped dpad was pressed, a direction was stuck. I have that partially on the dpad of my ps3 controller, but it's very old now, so it's normal (and only on the very old one, the new xbox controller clone works flawlessly !).

There isn't much I can do here. For info I found a way to disable xinput for sdl2 if you want to test it, see there : https://wiki.libsdl.org/SDL_HINT_XINPUT_ENABLED

So to try that without recompiling raine you need to have some command line like what you did for the controlmap thing, then type :

set SDL_XINPUT_ENABLED=0

and then run raine from the same command line. The default is to have xinput enabled, so you'll see how it goes without it. For me on my real windows it doesn't make any difference. You have the list of hints there : https://wiki.libsdl.org/CategoryHints

They say one of the differences with xinput is that it supports only up to 4 gamepads, but we never support more than 4 players at the same time in raine anyway.

For now I have no idea for your problem, eventually try to plug only 1 gamepad at a time, they should not interfere with one another, but what you describe is not normal for sure !

For the rasters, sorry but it was to be expected, I was too lazy to test all the uses cases for it, and the lava level in the attract mode was the simplest one, I would have been very lucky if everything had worked without testing. msh is the kind of game I like watching but not playing, so it makes testing harder, thanks for the savegame, I'll look in more detail later.

Edited December 13, 2021 by Tux

[mer-curious]

Hey Tux! I tried disabling X Input and then running Raine via Command Prompt but, as you expected, it didn't change a thing.

Anyway, I'm sure this issue with the controllers is only related to Raine SDL2 versions because I don't experience it with the SDL1.2 versions nor in other emulators. It's neither something with my setup solely because Augusto also reported it in the other thread. I've sent him a private message to see if he is using official Direct Input or alternative X Input drivers, but as we have tested, it seems this wouldn't make much difference.

For the time being I'll be using the SDL1.2 versions if I want to play with these controllers.

Let's hope you can figure it out someday. Thank you so much for your time and fast assistance. 👍

PS: I don't know if this is still relevant due to the SDL 2 update, but version 0.91.21 is not detecting the six-button layout of CPS1 games such as Street Fighter 2, take a look: https://imgur.com/a/koGuA2i

 

Edited December 13, 2021 by mer-curious

[Tux]

1 hour ago, mer-curious said:

Hey Tux! I tried disabling X Input and then running Raine via Command Prompt but, as you expected, it didn't change a thing.

Anyway, I'm sure this issue with the controllers is only related to Raine SDL2 versions because I don't experience it with the SDL1.2 versions nor in other emulators. It's neither something with my setup solely because Augusto also reported it in the other thread. I've sent him a private message to see if he is using official Direct Input or alternative X Input drivers, but as we have tested, it seems this wouldn't make much difference.

For the time being I'll be using the SDL1.2 versions if I want to play with these controllers.

Let's hope you can figure it out someday. Thank you so much for your time and fast assistance. 👍

PS: I don't know if this is still relevant due to the SDL 2 update, but version 0.91.21 is not detecting the six-button layout of CPS1 games such as Street Fighter 2, take a look: https://imgur.com/a/koGuA2i

 

?!? I really don't have any idea how it could happen only in this version and not with the sdl-1.2 version...

Even the way you describe it : if you can't maintain a direction, the source of the end of the release of the direction can come only from the controller (it works by events, it means an event was sent to release the direction). Anyway we can stop talking about that, for me it's exactly the same in linux, windows, or with the sdl-1.2 version and I really don't see how it could be different, I have absolutely no idea how it could be different...

Yeah this bug has been fixed in the very 1st changes for 0.92, and no I won't maintain another sdl-1.2 build, even if this version can be compiled for it. Crazy story... !
And Augusto has totally disappeared from here apparently... !

[Tux]

23 hours ago, mer-curious said:

- it seems that the raster effects has made the Apocalypse stage in X-Men vs. Street Fighter look really bad. The character stays behind the floor, Apocalypse is blending with the scenery and part of the background is cut. Take a look: https://imgur.com/a/BOJTqUW

I have made a save-state just before this stage is loaded so you can quickly check it: https://drive.google.com/file/d/19-nmRTCsGOk3jRsHWnmQ9t67LywESNXb/view?usp=sharing

It's fixed, it was quite easy, I had a doubt about sprites priorities being updated only on vbl so there was a commented piece about that, it was almost only about uncommenting it (and updating this part).
Well you clearly see the screen separated at the places where the raster has an interrupt for the save state you sent, which gives it a very weird look, but apparently it's the way it's intended. Anyway the background is now behind the sprites which makes it playable despite its strange look...

23 hours ago, mer-curious said:

Beware that if you load this state after the stage has been loaded, Raine will crash!

For that I can't do much, it's because the savegame is done with the speed hack enabled, but it's disabled when the raster becomes active, so if you load it then the 68000 arrives in the middle of nowhere and it crashes if using musashi in 64 bits (with starscream it's not a crash but the game is frozen anyway).
To fix that I would need to find a way to save the modifications of the rom made by the speed hack, which is not obvious... I'll think about it...

 

Edited December 13, 2021 by Tux

[Tux]

16 hours ago, mer-curious said:

Hey Tux! I tried disabling X Input and then running Raine via Command Prompt but, as you expected, it didn't change a thing.

Anyway, I'm sure this issue with the controllers is only related to Raine SDL2 versions because I don't experience it with the SDL1.2 versions nor in other emulators. It's neither something with my setup solely because Augusto also reported it in the other thread. I've sent him a private message to see if he is using official Direct Input or alternative X Input drivers, but as we have tested, it seems this wouldn't make much difference.

For the time being I'll be using the SDL1.2 versions if I want to play with these controllers.

Let's hope you can figure it out someday. Thank you so much for your time and fast assistance. 👍

PS: I don't know if this is still relevant due to the SDL 2 update, but version 0.91.21 is not detecting the six-button layout of CPS1 games such as Street Fighter 2, take a look: https://imgur.com/a/koGuA2i

 

And then I have a new binary to test for you, 64 bits since it seems it's what you use. The exe alone, drop it in a raine directory so that it finds its files.
It adds all the hints from testgamecontroller, the sdl2 test program since some of these hints are not even documented, and remove a SDL_PumpEvents which shouldn't harm anything but which is useless. I noticed the dpad on my ps3 controller seems to work better in this config. Which is strange, but anyway. Test that on your side. It also includes the update for the rasters. These attachments are quite convenient, I wonder if there is a size limit ? I might delete the attachment once tested.

Also I found a user maintained database of gamecontrollers for sdl2 on github, and the 2 mappings you sent were not in the db, I just proposed them !
I'll probably use their db in the next version... It's here : https://github.com/gabomdq/SDL_GameControllerDB

... and they replied :

Hi, thank you for these! Can you please refer to the mapping guide for button layout to ensure the mappings are correct?

https://github.com/gabomdq/SDL_GameControllerDB#mapping-guide

Thanks again.

so if you can take a look... !

raine.7z

Edited December 14, 2021 by Tux

[mer-curious]

7 hours ago, Tux said:

And then I have a new binary to test for you, 64 bits since it seems it's what you use. The exe alone, drop it in a raine directory so that it finds its files.
It adds all the hints from testgamecontroller, the sdl2 test program since some of these hints are not even documented, and remove a SDL_PumpEvents which shouldn't harm anything but which is useless. I noticed the dpad on my ps3 controller seems to work better in this config. Which is strange, but anyway. Test that on your side. It also includes the update for the rasters. These attachments are quite convenient, I wonder if there is a size limit ? I might delete the attachment once tested.

Hey Tux! Thank you so much for your interest in fixing this weird controller issue.

So, I've tested this version with my controllers and curiously I could no longer reproduce the directional issue with the Hori and the Ascii pads. However, the PS4 controller is still affected by it, but only sometimes. So I don't know if the changes in this version have really had any effect on that, because it seems the issue is triggered by something else eventually, and when it's not, then I can't see it with the controllers.

But now I've noticed the issue is not related to the diagonals, but to the left and right directions only! These are the directions affected by the bug. I've recorded a short video using FBNeo and Raine simultaneously side by side so you can see what I experience, take a look: https://drive.google.com/file/d/1CkIAyerK_MkVNvV5oo2B77YnCRRG2tiw/view?usp=sharing

As you can see, everything works the same in both programs, except the right and left directions become suddenly undetected in Raine.

I'm still trying to figure out a way to easily reproduce this crazy bug so you can try it with your game pads and setup. I'll let you know if I ever find that.

 

18 hours ago, Tux said:

It's fixed, it was quite easy, I had a doubt about sprites priorities being updated only on vbl so there was a commented piece about that, it was almost only about uncommenting it (and updating this part).
Well you clearly see the screen separated at the places where the raster has an interrupt for the save state you sent, which gives it a very weird look, but apparently it's the way it's intended. Anyway the background is now behind the sprites which makes it playable despite its strange look...

Ok, so what you mean is that it's not completely perfect yet? Because I've noticed the floor has been fixed in the stage, but Apocalypse is still merging with the scenery (we can't see his shoulders), take a look: https://imgur.com/a/8jZWH8p

 

7 hours ago, Tux said:

Also I found a user maintained database of gamecontrollers for sdl2 on github, and the 2 mappings you sent were not in the db, I just proposed them !
I'll probably use their db in the next version... It's here : https://github.com/gabomdq/SDL_GameControllerDB

... and they replied :

Hi, thank you for these! Can you please refer to the mapping guide for button layout to ensure the mappings are correct?

https://github.com/gabomdq/SDL_GameControllerDB#mapping-guide

Thanks again.

so if you can take a look... !

This is my ASCII controller: https://segaretro.org/Seamic_Controller

You can remove the weird microphone from the controller face so it becomes like this:

https://external-preview.redd.it/Ol_CfRMT21xCTGQX_zD8WlOBb9EJc9vXzZrFclKWkBQ.jpg?width=640&crop=smart&auto=webp&s=99c2cbf5be030913ec4260b189b5463cdea3ea9c

And we have L and R as shoulder buttons.

And this is my Hori controller:

https://i.ebayimg.com/d/w1600/pict/283353630372_/SONY-PS3-Controller-Hori-Fighting-Commander-3-Black.jpg

As shoulder buttons we have L1 and R1, and as triggers, L2 and R2. The R1 and R2 buttons are repeated in the face buttons, so you can either use them above or in the front (that is, these buttons are internally connected, they are not independent, unfortunately).

The ASCII pad seems to fit the Sega button layout from the SDL database, but the Hori is similar to a Sony controller, which I can't see a layout available there. So I don't how this particular pad could be registered there.

Thank you so much again for your work. 👍

 

PS: I forgot to say that in the video comparison I provided above the buttons are mismatched between the emulators because they are mapped differently.

Edited December 14, 2021 by mer-curious

[Tux]

39 minutes ago, mer-curious said:

I'm still trying to figure out a way to easily reproduce this crazy bug so you can try it with your game pads and setup. I'll let you know if I ever find that.

No need I can do it even in linux, left and right, I thought you knew already. In fact until yesterday I thought it was simply because the ps3 was becoming too old, before getting a doubt because of you. The way to reproduce it before this version was simply to turn around the dpad until the left/right direction becomes unresponsive.
I couldn't do it with this version, hence the idea that you test it. I might be able to get a ps4 controller for testing, but it's not sure, and it's a hassle...

39 minutes ago, mer-curious said:

 

Ok, so what you mean is that it's not completely perfect yet? Because I've noticed the floor has been fixed in the stage, but Apocalypse is still merging with the scenery (we can't see his shoulders), take a look: https://imgur.com/a/8jZWH8p

Yeah I know it looks weird, but I don't know what it's supposed to look like !

39 minutes ago, mer-curious said:

 

This is my ASCII controller: https://segaretro.org/Seamic_Controller

You can remove the weird microphone from the controller face so it becomes like this:

https://external-preview.redd.it/Ol_CfRMT21xCTGQX_zD8WlOBb9EJc9vXzZrFclKWkBQ.jpg?width=640&crop=smart&auto=webp&s=99c2cbf5be030913ec4260b189b5463cdea3ea9c

And we have L and R as shoulder buttons.

And this is my Hori controller:

https://i.ebayimg.com/d/w1600/pict/283353630372_/SONY-PS3-Controller-Hori-Fighting-Commander-3-Black.jpg

As shoulder buttons we have L1 and R1, and as triggers, L2 and R2. The R1 and R2 buttons are repeated in the face buttons, so you can either use them above or in the front (that is, these buttons are internally connected, they are not independent, unfortunately).

The ASCII pad seems to fit the Sega button layout from the SDL database, but the Hori is similar to a Sony controller, which I can't see a layout available there. So I don't how this particular pad could be registered there.

Yeah it's just that xbox & sony are the 2 main ones, they just represented the less known ones.

For sony it's X = A, O = B, the square = X, the triangle = Y, I thought you knew that, everybody who tries to use a sony controller on windows has to learn this since windows tries very hard to force everyone to use the xbox controller convention. It's exactly the same layout as the xbox controller this way.

Yeah I agree your 1st looks like the sega, the 2nd is a little extreme since there are no sticks, but I guess it can be useful to know at least where the dpad is. It can't redirect the dpad to any stick in this configuration though, but it should work anyway. You didn't say if you need to upgrade your mappings to follow their choice of button layout, but probably for at least one of them. Well it's not an emergency but try to do it so that I'll update them and send all that...

39 minutes ago, mer-curious said:

Thank you so much again for your work. 👍

PS: I forgot to say that in the video comparison I provided above the buttons are mismatched between the emulators because they are mapped differently.

It's your mapping !

Well I don't have many ideas on how to follow on that for now, I'll try to get a ps4 controller for a while at least, it will be easier. Maybe the thing is easier to reproduce in windows than in linux ? At least it works better for 2 of your controllers, the xbox one already worked, so it's almost perfect, just the f*** ps4 one which has some problems left...

[Tux]

Ok, I finally understood !

The problem is simply that the sticks on the ps3 / ps4 controllers are too sensitive ! The stick gets very easily moved from its center position and once that happens it keeps on sending move commands around the center position. While you use only the stick for direction it has no consequence, it's just a rounding problem, you don't even notice it.

But if you use the dpad for direction which is mapped to the same stick, the direction gets continually cancelled by the stick movement around the center position !

There are 2 solutions to deal with that : deal with the dead zones of the joysticks, that is, ignore these stupid parasite movements around the centre position, problem being this dead zone can change from 1 joystick to the next so we would have to add a way to define the dead zone for each joystick or try to define 1 large enough so that it will work everywhere.
Or decide that using the dpad at the same time as a stick for the direction was finally a very bad idea, and just forget it and remove all the code about it !

I'd say I am for the last solution, this thing was too much trouble. You'll still be able to use the dpad for direction if you want by mapping it explicitly in the inputs, but in this case it will replace the joystick, and you'll be able to save that as custom inputs if you want, that's what was done in sdl-1.2.
I'll sleep on it and decide tomorrow, but that was the problem, something stupid finally !

The sdl2 mappings for the game controllers are still useful to have sane defaults for all these controllers, but that's all.

After some more testing : linux has some builtin compensation for this dead zone, it's impossible to trigger it on the ps3 controller.
On windows, it's very easy, just move very slightly one of the sticks, it will start to report continually some movement, for me it's easier to do on the left one than on the right one.
So it's a driver problem in the end... ! I am tempted to try to ignore the dead zone at our level, it's not hard to do :
central position is 0,0, extremes are 32767, -32767, when this dead zone problem happens it sends moves around position +-1000-1200, so I could just ignore anything < 2500 in absolute value, it should get rid of all this mess in just 2 lines. I'll try it, it's just 2 lines of code.

But after this, if I have ever some other problem with this, it will be time to remove the dpad as a directional stick !

The shoulders problem is yet another problem with the priority bitmap in cps2. It's not fully implemented in raine, it's a very complex thing, they use masks instead of simple priorities... It was already broken in the versions before the rasters it's not directly related to them, it's "just" a priority problem, but a very complex one, so no promise here... !

Edited December 14, 2021 by Tux

[mer-curious]

5 hours ago, Tux said:

Ok, I finally understood !

The problem is simply that the sticks on the ps3 / ps4 controllers are too sensitive ! The stick gets very easily moved from its center position and once that happens it keeps on sending move commands around the center position. While you use only the stick for direction it has no consequence, it's just a rounding problem, you don't even notice it.

But if you use the dpad for direction which is mapped to the same stick, the direction gets continually cancelled by the stick movement around the center position !

Hey Tux! I'm really glad you could pinpoint the source of this issue! 😃 I guess I would have never come to this assumption, even though I noticed from my tests that playing with the analog sticks in the SF2 Input test menu would greatly increase the chances of triggering the problem, just as you have reported in your testing with the PS3 controller. Now everything makes sense: I couldn't experience this problem with the previous SDL1.2 versions because they didn't have this connection between the d-pad and the analog stick. Also, it's interesting that although my PS4 controller is genuine and brand new, the analog stick wobbles very slightly when I shake the controller in my hand and the driver does register this movement in the Windows controller properties.

Anyway, thank you for this great troubleshooting! 👏

 

5 hours ago, Tux said:

After some more testing : linux has some builtin compensation for this dead zone, it's impossible to trigger it on the ps3 controller.
On windows, it's very easy, just move very slightly one of the sticks, it will start to report continually some movement, for me it's easier to do on the left one than on the right one.
So it's a driver problem in the end... ! I am tempted to try to ignore the dead zone at our level, it's not hard to do :
central position is 0,0, extremes are 32767, -32767, when this dead zone problem happens it sends moves around position +-1000-1200, so I could just ignore anything < 2500 in absolute value, it should get rid of all this mess in just 2 lines. I'll try it, it's just 2 lines of code.

But after this, if I have ever some other problem with this, it will be time to remove the dpad as a directional stick !

This seems to be a good solution to keep both d-pad and analog stick configured and working by default, but wouldn't it be possible to just completely ignore the analog data received in this connection? The directional pad is purely digital, so the analog variations are unimportant, no?

Also, have you thought about making the d-pad the default for the automatic binding of the directions? For me it makes more sense to use a d-pad with arcade games, no? But then if someone remapped the directions to the analog stick, would they possibly face the same issue with the controls?

Anyway, I'm opened to testing whatever solution you may try. You can share another test version here if you want. 👍

But something still bugs me: the apparent impossibility to reproduce this issue with my X360 controller, even if it has a very noticeable wobbling dead-zone. Perhaps the X Input drivers made the difference here, as you said? But what about the "controller inoperative" issue which I experienced sometimes with this controller in Raine, how could it be explained? An issue with the detection of X Input drivers maybe?

 

5 hours ago, Tux said:

The shoulders problem is yet another problem with the priority bitmap in cps2. It's not fully implemented in raine, it's a very complex thing, they use masks instead of simple priorities... It was already broken in the versions before the rasters it's not directly related to them, it's "just" a priority problem, but a very complex one, so no promise here... !

Ok, no problem. In case you need, this is how it should look like: https://imgur.com/a/mpeSAuz

  

On 12/12/2021 at 9:10 PM, mer-curious said:

- If I leave full-screen mode after a game has been loaded, the windowed screen will be blank. See: https://imgur.com/a/RUMYkdN

Even though the screen is blank, the game continues running because I can still listen to the game sound playing.

Just for information because I don't know if you checked this, but it's still not fixed in the test version. 👍

 

7 hours ago, Tux said:

For sony it's X = A, O = B, the square = X, the triangle = Y, I thought you knew that, everybody who tries to use a sony controller on windows has to learn this since windows tries very hard to force everyone to use the xbox controller convention. It's exactly the same layout as the xbox controller this way.

Yeah I agree your 1st looks like the sega, the 2nd is a little extreme since there are no sticks, but I guess it can be useful to know at least where the dpad is. It can't redirect the dpad to any stick in this configuration though, but it should work anyway. You didn't say if you need to upgrade your mappings to follow their choice of button layout, but probably for at least one of them. Well it's not an emergency but try to do it so that I'll update them and send all that...

I guess you can suggest the Sega layout for the ASCII pad and the Sony layout for the Hori one, if it's available in the SDL database.

There are some changes I would make to the mappings but they are more related to the arcade systems, so I don't know if they could be implemented in the database. For example, for six-button CPS1/2 games, it would be better to have six face buttons, so button 1, 2, 3 down and 4, 5, 6 up (in this order). For Neo-Geo games, the configuration is already good (it follows the NG game-pad layout: A, B down, C, D up, in this order, as seen here: http://www.hbgamespy.com/uploads/81lkb7rxjul-ac-sl1500-684.jpg).

 

I guess that's it for this long post. Thank you so much again for your great work and support. 🙏

 

PS: I went and test shaking my X360 controller with the Windows controller properties opened, and the axes didn't register a thing. So you are correct, the X Input drivers do have better detection of dead-zones (they seem less sensible to this kind of "natural" movement).

Edited December 15, 2021 by mer-curious

[Tux]

Yeah it could be a good idea to be able to use the dpad only for direction, fixing this problem for good. Also I'll limit the dead zone filtering to when using the dpad + the stick for direction only.

There was no magic here, I just added some printfs for all the events raine recieved for the controller, and sometimes it received storms of moves which never seemed to end, actually it's possible to end it by re centering the stick manually, but it's not so easy to do. With this, the problem became quite obvious !

No didn't see your fullscreen -> windowed problem, it's an old problem, windows only. So you start the emu in fullscreen, load a game, then use alt+return to switch back to windowed mode ? I'll try to have a look...

So you used already the sega layout in the mapping you sent, and the playstation one for the other ?

By the way all the arcade cabinets (or so) use real sticks and not dpads but it's right they are used like a dpad, contrary to the sticks on our modern game controllers.

Edit : can't seem to be able to reproduce your blank window. Normally if it happens pressing esc brings back the gui and after that it's ok but still I'd like to be able to reproduce it. Tried starting from fullscreen with a game loaded or not, switching using alt+return or the gui, the whole thing in opengl, everything worked fine. And tried in windows of course. Oh well... !

Edited December 15, 2021 by Tux