mer-curious

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.

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

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

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.

Hey Tux! Thank you so much for trying to fix these issues which I've been reporting lately. So let me focus on the controller issue for this post: That's precisely it! But I don't know if I try to match the version in the mappings file, I just remap the directions to the d-pad in my controllers and then go testing it in the games. That's it. So, one of my DInput controllers (the ASCII Seamic Controller) does have one analog stick and one thing I've noticed about it is that I can move the cursor in the GUI very fast with its analog stick, just as if I was pressing the arrows in the keyboard. I can wrap around the options going up or down indefinitely if I want. But that doesn't happen with the d-pad. For example, if I press and hold down in the d-pad the cursor will eventually stop registering and be stuck in one of the GUI options. If I want to move it again I have to press the direction again and repeat this for every other random stop that occurs. This also happens when I have the mappings file in Raine's executable folder, so it seems it doesn't really matter having it there or not. What I'm guessing is that as soon as I use the analog stick and then switch to the d-pad, Raine may randomly detect a move in the analog stick which triggers a random stop of the cursor in the GUI. Is this possible? If so, the same could be happening in the game. I remember you saying in a previous post that in the SDL2 update you chose to mimic or mirror the stick movements in the d-pad, so maybe this is what's causing all these issues? Because that didn't happen in the SDL1.2 versions, did it? This could be something to investigate because I notice that even after remapping the directions to the d-pad in the Inputs menu the analog stick continues working within the game! So maybe a random register of the analog stick is also happening there, which is interfering with the movements from the d-pad. I guess this is exactly what Augusto was trying to report in this post: What Augusto reports there is also what I'm experiencing while playing, for example, Street Fighter 2 Champion Edition. Sometimes if I quickly press back the character will go back as if I was holding in that direction, and sometimes if I press and hold forward the character will not continue walking but just take one or two steps forward and get stuck there, just as what randomly happens in Raine's GUI. So maybe disabling the stick/d-pad mirroring could resolve this issue? Or perhaps changing what Raine understands as an "arcade stick", that is, bind the directions to the controller' directional pad rather than the analog stick (because back then the sticks were digital just like the d-pads, no?). Or finally, ignoring any inputs from an analog stick if a d-pad is being used? Anyway, these are just some of the solutions I thought to work-around this issue, but perhaps there's a better way to solve it. I couldn't generate a log with this testjoystick program. Actually the log is created but without any info there, it's totally blank. I couldn't generate a proper log not even by testing my Xbox 360 controller (which uses XInput). But I'm willing to try it again if you guide me. 👍 Finally, I guess you could reproduce this issue with the directions by using your PS3 controller in the following way: - Go to the Inputs options and bind the directions to the d-pad in your controller. - Run Street Fighter 2 or any other game that you're very familiar with and start it by using the analog stick (you'll notice it wasn't unassigned at all even after forcing the bindings to the d-pad). - Eventually switch to the d-pad and try to make as many movements as you would normally. - Luckily you should experience the random stops / interference in the directions. You could also try to use your Dual Shock 3 controller with DirectInput in Windows. You need to connect the controller via USB cable and install the official Sony drivers. There are some quick instructions in this page (scroll down to "Wired connection - official drivers"): https://www.pcgamingwiki.com/wiki/Controller:DualShock_3 Notice that the DirectInput drivers do not support features such as gyroscope sensor, pressure sensitive functions from the DS3 buttons and possibly not the vibration motors, but these features are not important for this testing. Lastly, I was wondering if there could some kind of incompatibility with the SDL2 after all? I found this page about Duckstation controller support and they say some controllers are "incompatible with SDL", which is something I didn't expect. Take a look: https://www.duckstation.org/wiki/Controllers One way or the other, let's hope this issue can be resolved. Thank you so much again for your time. 🙏

Hey Tux! Thank you so much for this super update! I guess most of the issues I reported have been fixed. 😃 So this is my quick feedback: - The blur effect with the second loaded game is gone, the same for the GUI glitches in 640x480. - I haven't tested the raster effects in the CPS2 games, but I saw your work in Marvel Super Heroes and it's good that we no longer have the black floor in the lava stage. But it's not perfect yet, there's a rectangle in the right side of the screen which doesn't seem to fit in the rest of the background, see if you can notice it here: https://imgur.com/a/LK5F62E - There's one left GUI glitch which I forgot to report in my previous posts. It happens when you load more than one game in the same Raine session. The "Loading Game" progress bar will become out of bounds, as well as happened with the other glitches which you have already fixed. Perhaps this one is easier to fix now that you acquired knowledge in fixing these nuisances? Anyway, I've recorded a short video-clip so you see it happening: https://drive.google.com/file/d/1HMt-tc2bKPzEy9thhdNB1ek_Ihu5z09R/view?usp=sharing - I don't know if this is a glitch, but when you change the video renderer to OpenGL, the "Renderer options" dialog will not be transparent as the rest of the other dialogs in the GUI. Take a look: https://imgur.com/a/h5JRqyw - Still on the video renderers, clicking on "Renderer options" for SDL2 native gives me a "No options for this renderer? Strange." message. Is this expected? - Finally, the mappings file in Raine's executable folder does make my d-input controllers work correctly hopefully! But if I remove this file I cannot use the d-pad by reassigning the "Stick 0" to "hats", as I used to do before the SDL2 update. Even before I do this the games seem to register directions randomly. For example, in Street Fighter 2 Champion Edition the character goes back as if I were pressing left in the d-pad, and I can't perform any special moves or move the character correctly, making it impossible to play. I don't know if this was the test that you wanted me to do, but that's what happens if I remove the mappings file from Raine's folder. Let me know if I should test it differently! - And now something new to my testings: the sound associations are broken! Raine doesn't load the external files and when we look at the games.cfg file we notice that it overwrites the entries with an empty entry. So, if the user doesn't have a backup of the games.cfg file, all of the work in binding the sound codes for the games is erased if any of these games are loaded in the SDL2 update. - And one last comment: now that Raine works with SDL2 would it be possible to support the libretro shaders? Or they are totally unrelated? That's it for this long report! Thank you for taking the time to read this post and for keeping working in Raine! 🙂👍

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 Yes, I'm sorry. I only looked at the 64 bit one. 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? 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. Ok, thank you so much for your time and help again! I should certainly give you some feedback after testing it. 👍

Hey Tux! Now I think I understand what you meant. So, I don't change any of the default video options in this testing. I just load a game and the pixels are crystal clear, as expected. Then if I load another game in the same Raine session the picture becomes blurred (similar to a bi-linear filtering), either before and after leaving the GUI. This didn't happen before the SDL2 update. I can remap it but strangely it doesn't work in the game, only in the GUI. Actually I don't even need to remap it to use it in the GUI. I don't know if it's important, but in the "Game Controllers" properties in Windows it informs that the d-pad in my controller is a "point of view hat". Thank you for your assistance on this. So I downloaded the zip and the program was not starting, it was asking for this DLL file: https://pt.dll-files.com/libgcc_s_dw2-1.dll.html Then I placed this DLL in the executable folder and it finally launched. I guess I could generate the logs by doing "controllermap.exe > log" in Command Prompt. I'm attaching the files to this post. Finally, I tried the testgamecontroller.exe but it returns an error that "SDL_GameControllerHasRumble was not located in the dynamic link library". Anyway, I hope the logs can help you address the issues with my controllers. However, I'm afraid of how this is going to work with new users using newer controllers in Raine, especially d-input ones, which I suppose are the ones not currently working in the emulator. Thank you so much again for your help and work. PS: I don't know if this is an issue, but when I run controllermap.exe, it doesn't have the buttons' labels as we see here: https://github.com/glebm/opendingux-controllermap-sdl2/releases/tag/v0.1.1 Mine looks like this: https://imgur.com/a/VKJ0lOo Controller Logs.7z