mer-curious

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

I'm also experiencing some issues with my D-input controllers. The d-pad curiously works fine in the GUI but not in the game. I've noticed that in the Inputs menu the directions are automatically assigned to "Stick 0", but my controller doesn't have this stick. So I manually map the directions to "Stick 2" (which seems to be my d-pad), but it still doesn't react in the game. Xinput works fine, but XBox 360 controller's d-pad is not ideal for 2D fighting games, unfortunately. 😕

Hey Tux! Thanks a lot for the technical details! In full-screen the menu does show properly, as you can see here: https://imgur.com/a/uq2yW4p But the path isn't that big, is it? I guess the glitch happens because this dialog does not resize to the 640x480 window, that's why it becomes unreadable. You have already fixed some things related to this resizable menus before, if I'm not wrong. 🤔 That's why I thought this one could be fixed too. Anyway, let's hope it doesn't break anyone's experience with the program eventually. I'm sorry for this one, I just thought you had fixed it, then I went to test it and reported it wasn't working yet. But it was an interesting testing in the end because now we know the crash has to do with the Xinput, since my Dinput controllers don't trigger it. But I did! It's in the other thread. It's because there are so many messages and quotations that you may have missed it. Here it is: And then I reported this issue again here because I didn't know whether you had tried to fix it. Anyway, it's not fixed yet. I'm sorry for bothering you with these little nuisances about the GUI. I just care about it being as usable and orderly as possible for the default configuration and possibly for new Raine users too. And since we didn't have this distortion in the previous (SDL1.2) versions, I thought maybe it was something unexpected and so it could possibly be fixed. Unfortunately I cannot help you with coding, otherwise I would try. Thank you so much again for your work in this crazy bug! Thank you again for your incredible work and time!

🙂 Hey Tux! I've started my testings with the new release and here's my preliminary feedback: - the first thing I noticed is that the mouse wheel is not working properly in a certain part of the menu, specifically in the ROMs directory select screen. I can scroll down using the mouse wheel but I cannot scroll up, so if I reach the bottom of the directory I'm stuck there. I've recorded a video in which I show you this glitch happening. Take a look: https://drive.google.com/file/d/1X9cMmImh5zIz4IxC4YnSjbtdy0FXbKTo/view?usp=sharing - I've found another GUI glitch: Go to Change/Load ROM -> Options -> Rom directories, then click on Raine's default ROM directory and you should get something like this: https://imgur.com/a/6vfR5qh - the "Analog controls" option still crashes the emu if I select my X-input (Xbox 360) controller, but not my D-input game-pad. Maybe the crash is related to the X-input API then? - CPS2 games still have a "bi-linear-filter-like" effect automatically applied to them if you load another game first. When this bug is triggered all the following loaded games will also be affected, regardless of the driver. - Raine's game list is much more readable now "out-of-the-box" with the bigger font size. 👍 - Even though it is more readable, there is some weirdness in the title of some games. Take a look at the KOF '98 and The Last Blade 2 titles, for example, and compare them with the others: https://imgur.com/a/gEmgyVr - the Shuma-Gorath moves have been fixed indeed! But I'm concerned about whether this fix would also work for another game that possibly use the same command? 🤔 I guess that's it for this quick report. Thank you so much for your incredible work! 😉

Hey Tux! Thank you so much for this new release! I'll check it out and then report here if I find anything odd. 👍 Just to let you know that the "Old versions" page is not updated with the previous (and first) SDL2 version. As someone who is worried about hardware obsolescence, I think it's really interesting that you are still using such an old version of Windows to play game emulators these days! Did you see Tux's suggestions in the other thread regarding this situation? I'll put them here and also some other work-arounds I thought of: - use a Linux distribution compatible with your old hardware and use Raine SDL2 for Linux instead; - upgrade to Windows 7 and see if Raine SDL2 works fine there; - stick to Raine with old SDL version and use another emulator more compatible with XP alongside Raine (I currently do this if I want to play CPS2 games perfectly with the raster effects, but I'm on Windows 8/10); - ask Tux to support both SDL versions of Raine (this could be time-consuming and I don't if it's possible at all); Anyway, if none of these tips work I hope you can find a good use for your old PC/laptop! 👍

Hey Tux! This is really great news! I'm so happy you could finally "smash" this "mystic" bug, if you forgive the pun. 😂 We were not crazy after all! Edit: But I'm curious on why would this move sometimes work when loading a CPS1 game first. 🤔 I happened to forget to attach a picture of FBNeo's default mappings for 4-button games such as Neo-Geo. See if you like it like this: https://imgur.com/a/tOyC7ji Thank you so much again for your great work! 🙂👍

Thank you so much for taking the time to check it. The name of the move is "Sonic Boom" in Street Fighter, not in Marvel Super Heroes. I call it "Sonic Boom" because it became famous with the Street Fighter franchise. You hold back for ~2 seconds, then front + punch. Shuma-Gorath in Marvel Super Heroes has the same move with both punches and kicks. There it is called "Mystic Stare" and "Mystic Smash". https://imgur.com/a/CNILYI7 I can easily perform it in the left (Player 1) side of the screen, but it's impossible to do it in the right (Player 2) side. I can only do it if I load another game first, such as a NeoGeo game or a CPS1 game. I've also tried loading another CPS2 game first and it worked with Cadillacs and Dinosaurs but not with Street Fighter Alpha 1. Perhaps because it also uses a six-button configuration? But Street Fighter 2 also uses it, although it is from another driver... Anyway, I hope you can figure it out eventually. Thank you so much again for investigating it! 🙂👍

Where is this option? I couldn't find it to test it. But I'd still prefer a background without this graphical effect just like in the previous versions... I don't know if it's really bi-linear, but that's the most common filtering effect for emulators. It applies a smoothing effect to the picture. Take a look: https://imgur.com/a/rycFR0N The smoothing effect shows as soon as the game is loaded, even before hitting "Play game". And it also happens if you change one CPS2 game for another too, not just from different drivers/systems. Yeah, the problem is that I can perfectly and repeatedly perform it on the left side (P1 side) of the screen and can perfectly perform it on both sides of the screen in FBNeo. But I've noticed something interesting: I loaded Street Fighter 2 and selected Guile to perform his Sonic Boom move and everything worked correctly. Then I changed to Marvel Super Heroes in the same Raine session and I could perfectly perform the same command with Shuma-Gorath too! Now if I load MSH in a new Raine session I can't perform the move in the P2 side of the screen. Pretty weird! Anyway, I wish other Raine user could test it to confirm that I'm not crazy... 😞 What do you think of the FBNeo bindings? https://imgur.com/a/UFpbssk I'm sorry, I think I made a mistake. I was judging by the behavior we had in the SDL1.2 version, which mapped the Up, Down, Left and Right directions to the game-pad's analog stick, which is not convenient for fighting games. Now in SDL2 the directions are mapped both to the analog stick and d-pad. By the way, I guess there's an error with the mappings for an X input /X360-like controller. The middle kick and coin controls are mapped for the same "Back" button (Select in the PS2-style controller), which is not functional for 6-button fighting games such as Street Fighter. The same goes for the strong kick, which is currently mapped to the Guide / PS button. I haven't noticed that yet. One thing that I noticed though is a glitch that happens if you visit Video options or Console once a game is loaded. The GUI gets out of bounds and has a smoothing/bi-linear effect applied to it. Take a look: https://imgur.com/a/Gr24j02 I guess that completes this long post. Thank you so much again for your continuing support and development of this emulator. 🙂👍

Wow! That came fast! 🤩👏 Thank you so much for your hard work in this super upgrade! I guess you deserve to rest now. I'll leave this preliminary feedback here just in case you wish to play with it again sooner or later: - the mouse wheel does not work to scroll in the GUI. - the background effect makes reading the games list a little more difficult than in previous versions. Perhaps the default option could be a clean background? - CPS2 games seem to load with bi-linear filter on when you load them after another game from another driver (such as Neo-Geo) has been loaded. - the new default key for full screen mode (Return) is not so easy to guess because generally this key is used for confirming actions, not switching between screen modes. Perhaps you could finally swap it to Alt+Enter in SDL2, which is the default for most programs and emulators? - the input bug which does not allow executing the "Sonic Boom" command on the Player 2 side is still present in Marvel Super Heroes. Curiously I was able to perform this command the first time I tried the emulator in a clean install, but then I couldn't anymore. Very weird. - The default keys for Player 1 are a little unusual. It's really rare, for example, to have the Caps Lock key mapped for actions in a program. Maybe they could be the same as for the SDL1.2 version? - The emulator still tries to automatically assign the controls to your game pads, but the assignment is not ideal for many arcade games, especially fighting games, which work better with the d-pad and not the analog stick. Isn't it better to turn this feature off and let the user decide the best mappings for every game or driver? - When I click on Analog controls and select "Controller (Xbox 360 Wireless Receiver for Windows)", the emulator crashes. That's it for now. Thank you so much again for your time! 🙂

Thanks for keeping us informed about your progress on the SDL2 update. I hope you get better soon. 🙂

Yes that's it. I have some close friends and relatives that sometimes get together so we play beat'm-up, kart racing and also rythm games. Nice addition with the vertical rotation. I believe FBNeo has an option like that too. My current Samsung monitor also rotates vertically, but I've never used it that way with emulators because I virtually don't play shoot'm-ups except for Metal Slug, which is side-scrolled. Thanks again for considering checking the input bug in the future and for your time and work dedicated to the SDL 2.0 upgrade. 😃

Thanks for your work, Tux! I'm glad it was an easy fix for that. By the way, the B1+B2 button combination for P2 and P3 are currently unavailable. Is this right? Anyway, I hope a fix for the "Sonic Boom" command bug in Marvel Super Heroes would be as easy as that too. Thanks again for your time and support. 😃

Hey Tux! Seeing that you have been releasing new versions again, I'd like to report another bug related to the inputs. While playing Captain Commando with two players, the setting for B1+B2 for player 2 doesn't work and will actually trigger the B1+B2 setting for player 1. I'm using one generic USB controller for P1 and one X360 controller for P2. By the way, I've already reported somewhere else that the X360 controller will always be automatically assigned to the P1 controls. So if you have your games assigned to one specific game-pad, this configuration will move to the P2 as soon as you plug an X360 controller to your PC, as you can see in the screenshot below: Before connecting an X360 controller: https://imgbox.com/Gl3sQkun After connecting: https://imgbox.com/qfkdTfms Maybe this could be resolved by removing the automatic bindings for game-pads which Raine currently does. I suppose it could be a good change because the automatic binding doesn't work very well, especially in relation to the sticks. For example, my 10B game-pad is incorrectly assigned to "stick 0", when it actually had to be assigned to "stick 2" in order for the d-pad to work in the game. Thank you so much in advance if you ever try to fix these issues. 🙂👍

Hey Tux! It's good to see you're back to updating Raine! 🤩 When doing some tests with the 32 bits 0.91.20 version I came across the 32 bits DLL packages in the downloads page. Which should I download, the 0.90 or the 0.91.7? This "7" in 0.91.7 can be a little misleading. One may think it's only valid for the previous Raine 0.91.7 release, which was my case, and so I downloaded the 0.90 package and realized it didn't work. Maybe you could make it clearer which package people should download, especially ones that are new to trying Raine? 👍

Six months later and no dark theme yet. 😂 Anyway, I followed Tux's advice and installed a browser extension to change the colors. I'm using Dark Reader (https://github.com/darkreader/darkreader), which is compatible with Chrome, Firefox, MS Edge and also Firefox for android! But I don't know if they work in Linux. 🤔 I have to say I can no longer live without this extension. It saves my life when I'm having a headache and have to use the computer or smartphone.

Hey Tux! I'm experiencing a weird bug with the inputs in Marvel Super Heroes. I cannot perform a specific command with Shuma Gorath when I'm facing left (P2 side). The command is press back for 2 seconds, then forward + any kick button. Shuma Gorath should transform himself into a ball-like creature and perform a rolling jump forward in the air leaving some replications of him. You can see this move many times in this video, for example, in the first round after the K.O.: https://www.youtube.com/watch?v=hqggeCP_G68 You can also use the same command (charge back for two seconds, then forward) with any punch button. The character should throw forward a ring made of eyes. These moves work perfectly when the character is facing right (P1 side). I've tried it with other emulators and the move works normally there in both sides, which confirms it's an issue in Raine. I've also tried performing them with the keyboard but it didn't work either. Never seen an issue like that before. Anyway, I hope you can reproduce it if you ever play with Raine again. It's not hard to perform I guess. If you have ever played any Street Fighter games, it's the same command as Guile's Sonic Boom. Thanks in advance for your support.

Hey Tux! Thanks for this release (and for the previous one too)! Do you have any idea of your progress porting Raine to SDL2? Maybe 20, 30%? Perhaps you could set smaller goals for your work in this transition? And then someday another coder could eventually help you finish this job? Anyway, I'd be very glad if you could still support Raine in current SDL1.2 architecture, even if this limited you in fixing some things in the emulator. By the way, I've recently noticed that when playing Raine with a game pad in Windows, the screen will fade after a while and then turn off. I suppose the next thing is make the computer sleep, but I always press a key in the keyboard or move the mouse and interrupt this process (it probably resets the timer set in the power plan for this function). I've searched a little about it and it seems this happens when the program doesn't send to the system a "no sleep" command when it's running, or maybe it doesn't detect the inputs from the game pad. Is it possible to add such a function to Raine? Or would this require a change to the SDL2 library?