mer-curious

So, I'm also experiencing a weird slowdown in the order select screen in KOF2001. The cursor movement becomes very slow when I try to move left or right. I also notice that the animations in the screen as well as the CPU order selection are also affected by this slowdown. For comparison, I went and tried this game with FBNeo and couldn't reproduce this slowdown there. I've made a video of the issue showing in Raine and then comparing it to how FBNeo performs with this game: https://drive.google.com/file/d/1SaypCppv08YnY5WZ5XRjsWO1XB5McJpR/view?usp=sharing I don't if it's possible to see the slowdown, but it's very easy to feel it when trying to move the cursor with a controller or keyboard. When the CPU order is finished, the speed returns to normal. It's not an issue that hinders the game-play though, but maybe it could also affect other moments of the game which I'm yet to realize if I start playing more KOF2001. Anyway, I'm reporting it in case it was an unknown issue. Thank you so much again for your time and attention.

Hey Tux! I was trying to create sound associations for the KOF2001 game and then stumbled upon some issues which I think could be fixed or improved. I'll number them below to help us with the discussion on each of them: 1. The "play track" function is broken in the new SDL2 versions. When we select "play track" both the associated track and the sound command are played simultaneously. 2. The loop check-box is no longer functional in the SDL2 versions, neither by pressing the space bar or by clicking in the box with the mouse cursor. 3. It would be useful that when we had the loop check-box marked for a track it also looped in the Raine player so we could preview the looping effect before starting the game. 4. I don't know what the "Test this" option is for. 5. Since the loop feature is broken in the SDL2 versions, I used an SDL1.2 version to create the sound associations for KOF2001. Then when I tried it with the latest Raine version I noticed there is an issue with the loop feature and the track played in the KOF2001 character select screen (file SND01_00041.mp3 from my pack). The loop is applied before the end of the track (maybe 1 or 2 seconds to the end). This produces a noticeable seam effect when the track loops, which doesn't happen in the SDL1.2 version I tested. I suppose this is happening because the track is too short (just 8 seconds)? Anyway, it would sound better if it could loop perfectly in the most recent versions as well as we had in the SDL1.2 ones. 6. There is a bug in a part of the game in which we leave a stage straight to a story demo. Two tracks are played at the same time, which wasn't supposed to happen. The only track that should play in this part is file SND01_00048.mp3 (sound command 37h). Here's a save state right before you enter this cutscene: https://drive.google.com/file/d/1FjLgfoq8zvRf1AEWQbAUrfzq3KjBT2_L/view?usp=sharing 7. I don't know if this is related to the "Sound associations" settings, but if you click on "Manage associations" and then return to the game the colors will be pinkish, take a look: https://drive.google.com/file/d/1Db0Den6qU0ttR_Qt2CJEy2lywwXinadh/view?usp=sharing I guess these are all the issues I've found so far with the sound commands feature. I'm sharing my games.cfg file together with my KOF2001 soundtrack pack to help you reproduce the problems: https://drive.google.com/file/d/15V40Yph1yVsw1crovgIDJ9oKIfdSV84O/view?usp=sharing Thank you so much in advance for your help. PS: In the following post I will report a slowdown issue which I'm experiencing in KOF2001.

Hey Tux! I suppose the fix you have provided to FaustXXX's bug report should also deal with Neville's freeze as well, right? In case it doesn't, I just found out that you don't have to go full-screen nor play with the Video settings to trigger the issue. Just try to load a game after populating the game list and this should make the program freeze. A video of it happening: https://drive.google.com/file/d/1YC16cm52TfcY-hG4Rck7TbHGzmbOuPEt/view?usp=sharing I suppose it should definitely have to do with the lack of a config file in the config folder because this is what we all had in common in our setups. So in the end it wasn't a CPU overclock or video drivers issue. Anyway, thank you again for your super fast work!

Hey Neville! I could reproduce this bug by following these steps. I'm using the 64 bit version of the emulator, so it's not limited to the 32 bit apparently. In relation to the Full-screen activation, I do it by switching it to "Yes" in the Video settings. And as for the new 4:3 aspect ratio option, I change it from the default "Close" to "Always". Perhaps it's related to the Intel OpenGL drivers? I'm using Intel integrated graphics with the latest Windows drivers for the 6th gen+ (Skylake) CPUs. This is the ROM directory string associated with Raine: D:\unzipped\games\Arcade Let's hope Tux can reproduce it eventually. 🙏

Hey Tux! Talking about FBNeo, I once inquired the FBNeo team about an option to set the aspect ratio in the Retroarch FBNeo core. The developers replied me that virtually every CPS1, 2 and 3 game is 4:3. You can take a look at the discussion here: https://github.com/libretro/FBNeo/issues/366 So now that you changed something related to the aspect ratio this reminded me of that issue I opened in the FBNeo GitHub page. So, is it wrong to display these CPS games in 16:9 in terms of emulation accuracy? Maybe what Raine does is show them in integer scaling and then I'm misunderstanding it as 16:9? Anyway, except that, I just wanted to let you know that the button mapping is working pretty fine for my crazy Saturn adapter as far as I've tested. To be a little picky, just the message in the third line is slightly cut in the 640x480 window size, as you see below: https://imgur.com/a/mkRhUuR But I don't know how you could fix that except by reducing the font size? 🤔 Also, you could capitalize the option "d-pad for movement" just to match the capitalization of the other options in this menu. Well, just some cosmetic details due to my brief testing of this new version. Thank you so much for your continuing work. PS: by the way, the load-state error message which we discussed privately is gone indeed.

Ok, no problem. I can use it with the "gamecontrollerdb.txt" trick for the time being. But would it be possible to have two different controller layouts to the same identification number? That's correct, it doesn't detect the directions. I can't navigate the GUI neither using the controller. I can reach the Inputs configuration using the keyboard but nothing happens there when I try to bind the D-pad to the directions. The buttons are detected on the other hand, but with a weird naming layout. For example, the Saturn left shoulder button is called "trigger right-". By the way, the adapter is identified as "HRAP2 on PS/SS/N64 Joy..." and I can't read the rest of the name due to the character limitation in this menu. Anyway, I hope this can be of any help to you in trying to improve the detection of these weird adapters eventually. Thank you so much again for your time. PS: I was able to read the full name given to the adapter by generating a log file. It's called "HRAP2 on PS/SS/N64 Joypad to USB BOX".

Hey Tux! Thank you for your assistance. I've tried what you asked and it worked! I didn't even have to rebind the directions, just the Coin input because even with my controller data the Coin input was still mapped to "Back" in Raine, which is generally the Select button that the Saturn pad lacks unfortunately. But it worked after manually rebinding it to the left shoulder button. This controller data that comes already in the gamecontrollerdb.txt file is a little weird. It has data for the left stick but not for the d-pad, which is normally present in a standard PS1/PS2 controller. Perhaps it was mapped to a very unique game console controller type (because "joypad to usb" is very generic in the end)? Anyway, is it possible to ask for a revision for this identification number in the data-base? Thank you so much again for your help. PS: if I completely remove the gamecontrollerdb.txt file from Raine folder I'm still not able to bind the directions in the inputs configuration unfortunately.

This is interesting. I didn't know about that. Perhaps you could choose one of these pages to link in Raine's download page? No problem. My suggestion was to include these commands in the Raine controls because this is where I intuitively looked for when trying to find the basic program controls. But maybe there's a better place for that. I was able to create the log file in Raine, which is attached to this post. Fortunately I could also generate a mapping file with the Testgamecontroller program and the directions were detected there. I followed the Sega to Xbox layout in this mapping because I'm using a Sega Saturn pad with the adapter, but it also supports PS and N64 controllers, so I don't know which standard could be used to include it in the SDL database. Perhaps three entries could be generated specifically for each of these controller models? I also have some PS and N64 pads, by the way. Anyway, I hope these logs can help you figure this issue out. Thank you so much again for your help. PS: this is my Saturn pad: https://segaretro.org/Control_Pad_(Saturn) . As you can see, the Saturn didn't have a Select button, which is generally mapped to the Coin input in the emulators. If I could choose, I would rather map the Coin input to the left shoulder button (LB in the Xbox mapping). log sega saturn controller

I agree, but I guess it would be more user-friendly to have this stated somewhere in the program (even if as a non-configurable option), since we don't have a "readme" file or any other file in which we would normally find this kind of information. Anyway, just a suggestion thinking as a new-comer to the emulator. Maybe you could change the name and make Raine detect the old filename and copy the information to the new one? Thank you for your willingness to help. Actually I do have something new now. It's about the new SDL2 inputs behavior. I think I've found another bug in it. I have a Mayflash Sega Saturn/Playstation/Nintendo 64 to USB adapter which was borrowed with my brother and I finally asked him to bring it back to me so I could make some tests with Raine and my Sega Saturn controller. This is the adapter: https://www.amazon.sa/-/en/Mayflash-Sega-Saturn-Controller-Adapter/dp/B006ZBHXEO So, the issue I'm having is that Raine does not detect the directions in the inputs configuration when I try to bind them. When I go to the Windows Game Controllers setup, this is how the directions work with this adapter: https://drive.google.com/file/d/1m-WbQSHU1ICdcDJEQNlO42u1vUhWkbxh/view?usp=sharing So as you see, whenever a direction is pressed, it seems that a button is detected too. I don't know why this adapter works like this, but maybe this is what is avoiding Raine detect the directions when I try to bind them. I have already tried disabling the "D-pads for movement" option, but it didn't work either unfortunately. Curiously the Raine SDL 1.2 versions work normally with this adapter. The Sega Saturn controller has better detection of diagonal movements, so it's more suitable for 2D fighting games. That's why I would be glad if you could work around this issue in the new versions eventually. Thank you so much in advance for your time and work.

Hey Tux! Thanks for the clarification. Now I understand what happened. I'm sorry about coming to this subject again. It's because I always create a new installation folder for every new release, so I easily noticed this difference. Yes, I finally recently realized that. I guess I took some time to realize it because this command/action is not present in the "Raine controls" menu. Perhaps you could include it there but make it non configurable, that is, just for information? Ok, no problem in relation to the changes. I just thought this dialog could be more easily understandable by layman users. I personally had some difficulty in understanding what to do to make my Hori pad be associated with player 1 (the X360 controller has the priority for that), that's why I suggested repositioning and rephrasing the questions/messages to the user. By the way, I guess I know why you use space for entering colons, exclamation points and question marks in your texts in Raine. It's because this is correct for French orthographic rules, so your keyboard should insert it automatically. But for English, this is not standard as far as I know. 🤔 Yes, but I'm not really playing a lot lately. But I'll try to report any bugs I find. One last suggestion is related to the raine32_sdl.cfg file. Do you think it's a good idea to rename it to to just "raine_sdl.cfg" once we now have a 64 bit version of the program? I thought about this when I checked the Config folder and finally realized it seems a little misleading to have a "raine32" citation in a 64 bit installation of the program. So maybe removing this mention would make it sound more generic and suitable for both 32 and 64 bit versions? Anyway, just a small detail that came to mind due to the lack of more important bug reports. Thank you in advance for your time and continuing work. 👍

Hey Tux! I finally played a little with this new version and it seems to be working fine as far as I can tell. 🙌 However, when I unpacked the updated DLL files to the Raine folder it asked me if I wanted to replace the SDL2 file already in the folder. Is it ok to do this? They seem to be the same to me. I ask because this didn't happen with the previous versions. Except this, I've happened to start using the joystick indexes option and I guess it could be a little improved to make it more user friendly. For example, the question near the top of the window is a little too distant from the selectable options, which makes it a little difficult to observe. Also, there isn't a "Cancel" option in case the user accidentally enters this dialogue or just doesn't want to change anything. Maybe this question could be placed above the options for better reading? Actually, this configuration could be made simpler and clearer for layman users with a question/title such as "Joystick index order", and then we would have the indexes order such as: Player 1: joystick name Player 2: joystick name Player 3: joystick name Player 4: joystick name Change the index order Cancel That is, practically the same way it currently is but with the addition of the player number and some additional options below. And then by selecting the "Change the index order" option Raine would take us to a dialogue with a message such as Select the joystick for player 1 Xbox 360 controller Ascii controller And then if there are only two controllers, Raine automatically associates the remaining controller for P2. If there are 3 controllers, the emulator will prompt the user to order the first two players sequentially and then associate the third controller for P3 automatically, and if there are four joysticks, the user will be prompted three times and the remaining game-pad will be set automatically for P4. Anyway, I guess this would be a nice change to make this configuration more intuitive, but this is not something urgent, so feel free to think about it before implementing this or any other change you might come up with, if you ever think they make any sense. That's it for this quick feedback post. Thank you so much again for your time and work. 🙂👍

Hey Tux! Thanks for this new release. I haven't tested it yet because you said you would update the DLLs package but, as far as I've noticed, the modification date for the packages in the Downloads page is still from December 2021. Is this OK for this new version? Or perhaps I may have misunderstood what you said about updating the packages? Anyway, thank you so much again for your continuing work on the program.

Hey Tux! Thank you for this new version! Just a quick report to let you know that the "Sound options" crash and the "slow mp3 tracks" have been fixed in this version thankfully. This got me curious. Do you intend to add the Konami drivers for Sunset Riders and TMNT Turtles in Time some day eventually? Also, perhaps you could add some more shaders to enrich this feature in Raine. There are quite some interesting shaders in the libretro pack, but I don't know whether they can work on Raine without some kind of conversion. Anyway, thank you so much again for your continuing work on the emulator.

Yes, precisely. In the video clip I provided above you can see it sounds as exactly as that. The track playing in the KoF'97 intro is track 46 from the NGCD version of the game, if you'd like to check how it should sound normally. I'm using 192kbps, 44100hz mp3 files. Maybe it's a Windows-related bug again? Anyway, thank you again for your super fast assistance.

Hey Tux! Thank you for the super fast reply and for the fix on the Sound options crash. Were you also able to reproduce the distorted sound with the associated tracks? I can reproduce it with all the games for which I have sound associations. It seems related to the changes in this new release. Thank you for the information. And I agree with you. I think it would be better to have the hiscore.dat file in the emulator package "out of the box". Anyway, thank you so much again for your continuing support.

Hey Tux! Thanks for releasing this new version! 👍 So I went to try some KoF'97 game-play to see whether the save-states are working normally but when I loaded the game I immediately noticed the BGM sound is broken. It seems that only the associated tracks are affected though. Also, if you visit the Sound options, return to Main Menu, then visit the Sound options again, Raine will crash. Here's a short video in which I reproduce both of the issues I've mentioned above: https://drive.google.com/file/d/1u6XMFeDxGD4hgHuNAVdB87EcxCpzPq9l/view?usp=sharing As you can see in the video, sometimes you have to enter and leave the Sound options more than once in order to trigger the crash, but it does crash eventually, whether it's in the first, the second or perhaps the fifth time you come and go the sound settings. Anyway, I hope you can reproduce those issues and fix them whenever you have the time. Thank you again for your work. PS: do I need the hiscore.dat file in Raine's executable folder in order to save high scores for CPS1 and 2 games?

Hey Tux! Thanks for the fast reply. This save was created using the latest 0.92.4 version. I might have probably made a few load states before in this turn, but everything went well until I reached this stage, saved and then when I loaded I had this random voice samples loaded there too. I still haven't experienced something similar in KoF'98, but I'll let you know if I do. Thanks again for your attention. 👍

Hey Tux! Thank you so much for the latest 0.92.4 update. I've just tried it and couldn't find more issues with the controllers. I also tested Captain Commando with my four controllers plugged in at the same time and everything was fine as far as I've tested. So hopefully everything is fixed for the time being. 🙏 Except this, I've stumbled upon a weird bug while loading a save-state in KoF'97. Suddenly after loading this state many conflicting voice samples are heard in the game (they seem to be from the character Kyo, but he is not even in the match). I don't know if you'll be able to fix it because the issue might be already triggered in this save file. Anyway, here you have it if you'd like to check it eventually: https://drive.google.com/file/d/10wEwA7_9QGo08ut-SRUMoKiNUCVr8Cmi/view?usp=sharing That's it for this brief feedback. Thank you so much again for your time. 👍

Hey Tux! Thank you so much for keep trying solutions for this crazy controller issue. I've tested your latest update (the one from December 21st) and I'm finally glad to say that I no longer have the left / right directions issue with my PS4 controller! 🙌 Well, at least for most of the time, because I'm still experiencing a weird issue related to the directions in Raine. Eventually I won't be able to perform double tap forward or double tap backwards to respectively make the character run and jump back in the King of Fighters games. Hopefully I have found an easy way to reproduce this bug so you can check it out. Here is the procedure: - load a KoF game such as KoF'98; - select the Practice option in the game menu, then choose "Advanced" and finally your character for practicing; - when the fight starts, practice the double tap forward and double tap backwards moves for a while so you get used to performing them. Use your controller's d-pad for that. Double tap forward will make your character run (if you keep holding forward), and double tap backwards should make him jump back; - now hit Esc to show the GUI and move the analog stick up and down and then return to the game by pressing the button to confirm actions in your controller; - from now on you should have the bug triggered and so you won't be able to perform those moves anymore. Please notice: - if you hit Esc to leave the GUI instead of using the controller button you may trigger the bug only temporally. Leaving the GUI with the controller button triggers the bug permanently; - if you press up and down with the controller d-pad in the GUI instead of using the analog stick you may also trigger the bug but your character should get stuck in the crouch position; - I was able to reproduce this bug with all my controllers, even with the Hori pad which doesn't have an analog stick (I used the d-pad in the GUI in this case). Here's a short video of how I reproduce this issue using the instructions above: https://drive.google.com/file/d/11aTvE1uHXhR3O9NeZhmRXpc230FnWuBG/view?usp=sharing I hope you can reproduce it whenever you have the time to work on the emulator again. Thank you so much for your attention.

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! 👍 Ok, no problem. Thank you so much for the thorough explanation, as always. 👍 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! 👍

😊 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. 👍

Hey Tux! Thanks for letting me know. I've already replied there with my GitHub account. Let's see if they have all the info they need now. I understand. My brand new DS4 controller has the same dead-zone sensibility as we have noticed, so it's not a sign of wear in your PS3 controller, it's just the way they work with the drivers. I also have some PS2 controllers since 2001. They have been opened for cleaning a couple of times, but still work quite reliably. I hope my PS4 controller lasts as long as those. Great! This fix will be really useful when saving a long play during the activation of the raster effects. No more worries about that. Thank you so much for your continuing work on Raine. 🙂👍

Hey Tux! Now I think I know what you mean about providing the correct layout. You're talking about the log files from the ControllerMap program, right? So, since the layout of the program is based on the X360 my previous mappings tried to follow that design. But now I've redone the mappings of my ASCII pad to follow that picture in the Git database which shows "Sega -> Microsoft". The Hori pad kept the same because I maintained the PS/XBox design. By the way, in the Git you informed that the Hori pad has 3 sticks, when it actually has only has one, the d-pad. Anyway, I'm attaching the updated logs to this post. That's exactly what I do here. I load a game in windowed mode, then hit Esc or "Play game" to leave the GUI, press Alt + Enter to enter full-screen mode, finally Alt + Enter again to return to windowed mode and then the screen is blank. Yes, if I press Esc the GUI shows with the game picture again. Perhaps it's related to the Intel OpenGL drivers because I currently only have integrated graphics to test (d-gpus are way too expensive in my country unfortunately). So in my old laptop I have a 3rd gen (Ivy-bridge) i3 CPU with Intel HD Graphics 4000, and in my desktop I have a 10th (Comet Lake) i5 with Intel UHD Graphics 630. From 6th (Skylake) to 10th (Comet Lake) Intel uses the same micro-architecture as far as I know, so if you have anything Skylake or above with integrated graphics you should probably be able to reproduce it. I'm using the latest drivers. Here's a quick video of the issue showing: https://drive.google.com/file/d/1OjWQ0ffO_xlkI7n13uvIvRJWAgb6DtxU/view?usp=sharing Notice that OBS recording takes longer to show the picture in full-screen mode and introduces a glitch in the top left of the screen when I leave it, but I don't experience these symptoms using Raine. I'll let you know if I come to test this issue with a NVIDIA or AMD video chip. Thank you so much again for your work. 🙂👍 Ascii and Hori update.7z

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! 👏 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? Ok, no problem. In case you need, this is how it should look like: https://imgur.com/a/mpeSAuz Just for information because I don't know if you checked this, but it's still not fixed in the test version. 👍 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).

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. 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 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.