mer-curious

Hello Tux! Thanks for this new release! So, I've checked the new "Recent games" feature and it seems to be working good, except that the default time which comes for the played games is a little random, as you see here: I didn't play these games in that time passed, so I don't know why it's showing that. Also, every time I visit and leave the list it updates the time, which I think distracts me a little there. Perhaps it would be better to just show the date in which the game was last played, instead of the immediate time? It probably doesn't make much of a difference if a game was played "yesterday morning" or "afternoon", so maybe just showing the date would let the list more static for a moment. It could be something like this: "game name 10/14/2022" (using the standard English date notation). And if you thought it was doable, the date notation could adapt to the applied translations. For romance languages, the format would be 14/10/2022. And for Asian translations such as Japanese, it would become 2022/10/14. Anyway, if it's too complicated I would also be happy with just the game names there (in the order they were last played, I mean). Except that, I've noticed there are still some few text messages which I missed in my revision. So I should be requesting you to review those later in GitHub. Finally, I came to remember about that small graphical glitch in KOF94 which I have already reported in the old forum. I think you said back then it was related to the raster effects. Now that you have added some K.O.F. hacks, I was wondering if you were in the mood to check it again. I've made a short video showing the bug, here: https://drive.google.com/file/d/1xi1mHtqkQKDQTNRKdwB8KHb3p_ugXlLD/view As you see, when the camera goes through the ground in the stage animation effect it will break and become black in the end, which doesn't occur in FBNeo, for example. It's surely a very minor issue, but maybe it's what's left to fix in the KOF games emulation in Raine. Thank you so much again for your work.

Hello Tux! I'm sorry for creating a lot of pull requests. I didn't know how to gather them all in one pull only, so I did what I could to do it quick. Anyway, I'm grateful for your understanding. I meant the "Decrease cpu skip" option in "Raine controls". I couldn't find any of those options in the source looking in the cpp files using the browser find tool. I wanted to be able to review the "Load game" and "Save game" there too and possibly other text. Thanks for pointing me the file. I have already pulled a request for the changes there. I'm OK with keeping the same folder name if it would cause problems both for you in the code and for the current users who update by replacing the executable. The change would be mostly for keeping the reference with the new wording adopted for the function. Either way, I think that "savestates" is clearer in terms of what files are there, because the saved game data is in "savedata", therefore in "savegame" we actually find the saved game states, hence the folder being called "savestates". But you can decide however is better in this case. Thank you! It was a pleasure to help you on that. I would certainly do more if I understood a thing about coding. By the way, I guess you forgot to merge the changes in the sound options. At least I couldn't notice it in the master files. Curiously this was the only changed file which created a "dezraj-patch 1" branch instead of a standard "patch" branch. Anyway, I deleted it from my repository. Please let me know if you can merge that, otherwise I can recreate a new patch with the changes in this menu. Thank you so much again for your work.

Hello Tux! Thank you so much to take the time to walk me through this process. I went the bold way and just forked the code to my account and edited the files on-line using the GitHub page, then I created some pull requests. Please check them and add them to your code if you agree with the changes. I made all the changes I suggested above and also changed "NeoCD" to "Neo-Geo CD" and "bios" to "BIOS". I couldn't find the strings for "Raine controls" to edit the "Load game" and "Save game" options there. I looked for "Decrease" in many files, and that is a very unique word in this menu, but couldn't find any instances of that. It looks to be very hidden in the code or I simply couldn't find them using the browser find tool (Ctrl+F). I would be glad if you showed me where it is. Finally, have you thought about renaming the "savegame" folder to "savestates" in order to match the new wording for this function? Or it isn't necessary at all? I was thinking if it would be better to add the new folder name for new installations but also look for save state files in the old "savegame" folder in case a user updates the emulator by just replacing the executable in the folder. Anyway, I'll wait for your comments on that. Thanks a lot again for your willingness to help me with the code.

Hello Tux! Thank you for the fast reply. I would be glad to help you in reviewing these little suggestions for the GUI. I've looked at the Raine code in GitHub and it looks like most of this information is on raine/source/sdl, right? So I just need to edit the text, create a pull request and then wait for your approval? Or is there something else to do? I can't tell much about the new "Recent games" changes you made because I haven't tested it yet, but I think it's great that you found a better way to implement it. I'll let you know my impressions on it when I test it. Yes, I also noticed this little margin in the left side of the window and I agree that it would be indeed better to remove it to match the other side. Anyway, just little changes that I've recently noticed and decided to report when looking for text to update in the GUI. Thank you very much again for you continuing work.

Hello Tux! Thank you so much for implementing these changes. I was thinking about some cosmetic changes in the GUI and would like to know if you agree with them. - Change the term "ROM" to "game" in "Change/Load ROM", since the term "game" is used in "Game selection", "Load NeoCD game", "Available games", "Play game", "game inputs", "Save per game screen settings" and will also be used in "Recent games", so the reference will be more consistent. - Capitalize "ROM" in "Rom directories" and "Rom dir". - Change "Load game" and "Save game" to "Load state" and "Save state" to not create confusion with the real "load game" function of the emulator and to also use the term which is more widely adopted by emulators out there. Perhaps this would also require renaming the folder to "savestates"? - Fix the alignment of the "Year" and/or "Category" info in the game selection list, as you see in the screenshot below: It seems that either "Year" is placed in the limit of the window or "Category" is a little too far from it. I don't know which one should be better aligned in comparison with the other information in the left. - Rename "Always stop CD music while loading" to "Always stop NeoCD music while loading" to contextualize the usability of the option in Sound options. - Do the same for "Mute SFX" (so, "Mute NeoCD SFX") and "Mute CD" (therefore, "Mute NeoCD music tracks"). - Capitalize "SFX" in "Sfx volume". That's it! Maybe there are more, but for now this is what I found could be slightly changed in terms of the interface. Not a real difference, but perhaps it could help a little new Raine users using the emu, no? Anyway, I'll wait your thoughts on those suggestions. Thank you so much again for your work. PS: I'm sorry Augusto to deviate a little the thread. It's just that Tux started to make some changes in the GUI here, so I thought I could also make these suggestions.

Hello Tux! Thanks for considering those changes. Just to be clear, when I mentioned it would be better to have a "Recent games" list, my idea was to put a list inside the game selection list. So we would click on "Change/Load ROM" and below "Options" there would be this new option called "Recent games" and there the recently opened games in the order they were lastly opened (from the most recent on the top to the oldest on the bottom). I think this way we could be unlimited in terms of how many games to show because it would be a separate list from the "Available games" list. The way it currently is (two different lists piled up) do not allow that due to visual organization. I'm OK in keeping the playing stats if you like it. I'm more concerned about the ease of navigation and the possibility of showing over five played games, which are currently the issues of this feature, I guess. Thanks again for your continuing work. 👍

Hello Augusto and Tux! I have finally used this feature for some time now and I guess I can share some feedback on that: - It looks to me that the recently opened games list inside the game selection list works better when we use Raine in full-screen mode, as in here: - If we use it in windowed mode, especially in the default window size, the menu gets a little visually confusing: - I don't pay much attention to the amount and number of times that I've played a game. What is important to me is keeping track of the games that I've opened, from the most recent to the oldest one. Also, sometimes I am just testing some stuff in a game or checking it to see if I'm in the mood of playing it and it looks like this time is also marked as "playing time", no? So this information becomes a little misleading in the end. For me, it could be discarded or marked as optional to be shown in the menu. - I know that we haven't been able to play as many games as we wanted, but we can eventually end up playing more than five games occasionally, so this feature would not allow to keep track of all those games as of now. For all the issues I have reported above I think it would be better to have a "Recent games" list inside the game selection list if possible. This would probably resolve the menu visual organization in any resolutions and also allow for more games (perhaps an infinite number?) to be recorded as opened. These are my impressions for now. Thank you so much in advance for your attention. PS: While capturing the above screenshots I have noticed that the GUI background effect is not maximized with the window when we click on "Maximize" already in the game selection dialog. You can check the result above. Is this a glitch?

Hello ffman1985! I couldn't reproduce the music change issue with Rugal in KOF94. I tried to reflect the CPU's "fire ball" move (Reppu Ken) and tried to have the CPU reflecting mine as well but unfortunately it didn't trigger the music change. I tried this for a few times without success. Perhaps you should try to create a save state right before the issue happens or follow Tux's advice to record a demo. Thank you Tux and ffman1985 for your willing to test and fix those issues with the sound associations feature.

Hello Tux! You are correct! I just uploaded a sample picture to Imgur and could finally see that there's a direct link to the picture in the BBCode. Now I can use the Other media feature on this forum. I can also resize it, give it a title and include an external link to it, which I have done. It was taken from my Facebook feed. 😂 Anyway, thank you for this tip and also thank you Robert for the information on that issue. PS: it seems that the picture title is not working. I can't see it.

Hello Tux! Thanks for the assistance on the picture attachment. I think that I have had difficulties in embedding the pictures because the forum attachment limit is just 56kb here and most PNG pictures exceed this size limit. Also, the majority of online image servers like Imgur don't offer a direct link to the picture, so it's impossible to use the "other media" in these cases. That's why I may have never used that option and so have just kept leaving the Imgur picture links in thread instead of embedding them in the posts. Imgur does provide BBCode links for the uploaded pictures but the forum does not support them unfortunately. Anyway, thank you again for your help.

I miss that forum! 😊 At least it was easier to embed pictures in the posts. 😅 (Seriously, this function seems to be broken here, the BBCode bracket syntax with url and img doesn't work, so I have leave the link to the server where the picture is hosted). Anyway, I wish we could have that color theme back for nostalgia and it would also match Raine's classic download page.

Hello ffman1985! I don't think you need to edit this track if you manage to get it from the Dreamcast or PC release of KOF99. Those ports have a full length How to play/Here comes a new challenger/Continue service music track. I have taken mine from the Dreamcast release. If you want it, it's here: https://drive.google.com/file/d/1znv_5RZbVf6OcI0AG6iJJKvbregOyXRJ/view?usp=sharing Also, in KOF99 for the NGCD the arranged music track for Kyo's encounter is missing, but it is available in the DC and PC releases too. I also have it uploaded in case you need it, here: https://drive.google.com/file/d/104AbijsZ4F59PRsTU4lQm3lsVfAld-d4/view?usp=sharing You can get the sound command information in my games.cfg posted in the previous page of this thread.

Hello Tux! I'm sorry for bothering you with this issue for the last days. I just wished the DS4 would be as seamlessly supported in Raine as the other controllers. Anyway, at least we have now finally unveiled the source of the problem. Hopefully another coder will join you in developing Raine and possibly help you with that. It shouldn't be so difficult since most other emulators out there have managed to fix that already. I'm sorry to ask that, but isn't a remapping function already available through the "Controller mapping" option in the Inputs menu? Anyway, I just suggested reverting those changes because they were thought to fix the DS4 controller issue and they didn't, so they haven't served their purpose. Now as a result they have taken the possibility to bind the "Confirm" and "Back" functions to other random buttons in a controller (for instance, buttons 3 and 4), right? The issue is that some controllers may feature a non-standard button layout and have, for example, buttons 0 and 1 positioned as triggers. If Raine does not allow users to rebind the "Confirm" and "Back" functions to other buttons as it did before, maybe the user experience with such controllers will be compromised from now on, no? Perhaps I may be wrong in my concern, but if those changes hinder some user configuration possibilities (according to what I've understood from Raine's GitHub page), I think they could be reconsidered. Thank you so much in advance for your time.

Hell Tux! I'm glad that you finally found the root of this problem with the DS4 controller. So in the end the controller was really necessary for that. Thanks to your nephew for his help! Answering to your question, in fact I don't see many use cases for this fix. I stumbled upon this issue by accidentally playing with the left analog stick and later slightly pressing one of the analog triggers against my lap while trying to make some difficult combos in KOF97. So I guess it would mostly be a fix for this "rare" cases in which this could occur, and, of course, to improve the overall compatibility of this pad with the emulator. There are some other open source emulators out there such as Duckstation, Dolphin, PCSX2, Cemu, Yuzu and Retroarch that don't show this issue as far as I've tested, so maybe you could see what they did in the code to work around the drivers issue in Windows? By the way, now that you found the real issue perhaps the previous fixes could be reverted from the program once someone could potentially want to bind the "Confirm" and "Back" actions to other buttons rather than button 1 and 2 in the controllers, no? It wouldn't be so usual, but maybe depending on the controller button layout the user could need that, so it would be better to give them this possibility, as it was before these experimental changes. Just to confirm that it is a problem really with the DS4, I've tested other two Dinput sources that I have here, one which is a generic dual PlayStation to USB adapter, like this: https://www.aliexpress.com/item/1219835437.html and the other which is a Mayflash PS/N64/SS to USB adapter, like this: https://www.ebay.com/itm/204050755634 which I generally use to play with my official Sega Saturn pad. Gladly none of these adapters show the issue with the right analog stick using my official PS2 DS2 controller (I cannot test the triggers because they aren't analog in the DS2 and the adapters don't support them either). So it wasn't a Dinput API issue as I had suggested. Anyway, hopefully you will find an easy fix for that in the source of another emulator if you eventually try that and then it would put an end on this dead-zone issue in Windows. Thank you so much again for your time and attention. PS: as for the light bar meanings in the DS4, I also had this doubt. The light bar changes the color to indicate the player connected (player 1, 2, 3 or 4). It also interacts with some games and informs some diagnostic messages to the user. I don't know if all these features work in Windows games since I mostly play emulators. But when I connect the controller to the PC some times it glows orange, which I think means charging. I took this information from here: https://www.ps4storage.com/ps4-controller-lights/

Hello Tux! Thanks for the fast reply. Just to be sure, did you observe the condition that I mentioned in my previous posts about the way to trigger the analog interference? You first need to use the left analog stick so the other analog sources (the right analog stick and the analog triggers) can interfere in the d-pad movements. If you don't touch the left analog stick first the other analog sources won't interrupt the d-pad movements, which is quite curious. Also, there are two revisions of the DS4 controller as far as I know. I have the revision/generation 2, which has the light bar bleeding in the controller face. I think this is the most noticeable difference between the two versions. You can see a picture here: https://www.neogaf.com/threads/ps4-controller-questions-differences-in-production-how-to-differentiate-v1-vs-v2-also-packaging.1605140/ Maybe your nephew has the version 1 model and then it would not show the issue in Raine because of that? Anyway, I hope you can figure out what's happening. It's a pity I don't have the DS3 here now to enrich my report. Thank you so much again for your help.

Hello again Tux! Thank you so much for finding a way to get a DS4 controller in Raine in order to test this analog detection issue. If you couldn't borrow one from your nephew you could perhaps buy and then return it after testing if it was really necessary. I think most retailers accept returns in a due time, although you would have to go through the hassle of taking it back. Anyway, I think I also have a relative of mine which has a PS3 with some DS3 controllers and I should be contacting him to borrow one of his controllers to test in Raine and see if the analog issue happens there as well. I took the time to hook my X360 controller to the PC again (it was stored in a drawer waiting some parts to arrive for maintenance) and interestingly I cannot reproduce the issue there neither in version 0.94.1 nor in the new 0.94.2 one. I have tried both in the GUI and in-game and the only analog source that interferes in the directional pad movements is the left analog stick, which is expected according to they way you have implement it (they share the same bindings). So the issue seems to be specific to Dinput controllers, no? I just tested the new 0.94.2 official release with my DS4 pad and unfortunately I can still experience the same issues there as in the previous version: the right analog stick and the analog triggers will still interrupt the d-pad movements both in the GUI and in-game. So there's still something not working right for Dinput sources in Raine in comparison with Xinput ones. I should post my results with a DS3 controller as soon as I get one. It will be a good addition for all of this report since the DS3 also uses Dinput drivers in Windows. Thank you so much again for taking the time to test and solve this issue.

Hello Tux! I'm sorry if I haven't been so clear in my previous posts. But what I was trying to say is exactly what you have supposed here. I can accept that the left analog stick may interfere in the continuation of a d-pad movement because this seems to be the way you have implemented it in Raine: both the d-pad and the left analog stick share the same configuration and work at the same time, so one may interfere in the other. But I don't understand why both the analog triggers and the right analog stick are also interrupting the d-pad movement if these analog inputs aren't even bound to anything in the inputs settings? This happens both in the GUI and in-game (respecting the condition that you first use the left analog stick, otherwise they won't interrupt the d-pad). This is my complain and what I think could be changed. Anyway, I think it would be easier for you to reproduce and fix those issues if you had a DS4 controller to test. It's not a great controller for 2D fighting games in my opinion, but since you don't play those that much it could be an overall good acquisition for both old 2D arcade games and new 3D ones as an alternative for your cheap controller. Perhaps you could find a good deal for one used or new if you're ever interested. I have been noticing that for a few emulators such as Retroarch and Raine Xinput controllers are currently better supported. It's a pity that Sony went with Dinput drivers for both the DS3 and DS4 controllers (I'm not sure about the Dual Sense 5). But I would be surprised if your generic Xinput controller had analog triggers such as the DS4 and the XBox 360 (and newer consoles) controllers, so this may alleviate the symptoms that I experience here with the DS4. Thank you so much again for your time and attention.

Hello Tux! Just to complete my report, I only have the DS4 connected to the PC via USB. In Control Panel it is identified as Wireless Controller. I asked about whether the fix would apply to the in-game environment because that's where the issue may affect the player the most. But as you see it does occur in the GUI too. In order to reproduce it you have to respect the condition that I found. No worries about an urgent fix since this is not a huge issue. At least the DS4 has been useful to find and fix these bugs in Raine's input system. Thank you again for your work.

Hello Tux! Thank you for the fast reply. Yes, this is exactly the configuration I have here, take a look: https://imgur.com/a/qsw8Bw7 I use all the default settings suggested by Raine for the DS4 controller. By the way, you said that you the analog triggers detection are ignored in the GUI but you also meant in-game, right? Anyway, now that you mentioned the GUI I went and tried to trigger the interruption there and interestingly it does occur in the GUI too. I've also checked a little longer with the right analog stick to confirm that unfortunately it still interferes in the d-pad movement. So it seems that the fix hasn't worked as intended according to my tests. Just to remind that I used the experimental version provided in the other thread compiled on September 13, 13:29, according to the "About" information. But the condition I mentioned above in my previous post is also valid for the GUI: you first need to use the left analog stick so that all the other analog inputs (the right stick and the R2/L2 triggers) can interfere in the d-pad movement. If you don't touch the left stick first, these analog inputs will never interrupt the d-pad movements. Perhaps this could help you come up with a work around for that? Anyway, thank you so much again for your attention.

Hello ffman1985! It's interesting to know that the save state file works for you and not for Tux and me. Did you happen to use unibios 4.0 when you created it? This is the bios I'm using here. Perhaps a different bios setting could trigger the corruption? The setup in the unibios for me is "Japan" and "Console". I don't think the romset we use could be different because it has been widely made available in the internet for many years, so we probably use the same roms. If you want to compare, here is a screenshot of my romset with the CRC codes: https://imgur.com/a/1jLj1DP Interestingly, I think I have already experienced this kind of corruption in a save state before when playing Art of Fighting 3. I couldn't reproduce it to file a bug report and so I just forgot about it for a while. Unfortunately we need to be able to trigger the corruption so Tux can check it and fix it. If you had a save state before the one you shared here maybe we could trigger the corruption from it and possibly fix it. If I'm not mistaken, it was in the last stage of a normal team play. I was playing against the Masters Team (Heidern, Takuma and Saisyu) in the Japan Temple stage. I was possibly using the Korea Team (Kim, Chang and Choi), but I don't remember exactly the characters I was using. Yes, I know the "Here comes a new challenger" sound command is divided in two different tracks in the NGCD version. I have edited both tracks in a single one using a sound editor. If you don't have it, you can grab it here: https://drive.google.com/file/d/1OUfecbMG0TMk11EDDNIgoAThyHzmIx34/view?usp=sharing I have created sound associations mostly for the games which had sprites cut in the conversion for the NGCD. So for instance, I didn't have sound associations for KOF94 because the NGCD conversion is perfect as far as I know (maybe that's why I never realized the sound issues you have reported here), so I just use the KOF94 for NGCD if I want to play the game with the arranged sound tracks. But I haven't tested many games to be sure about the sprites cut. It's probable that, for instance, the Samurai Spirits franchise have received either sprites cut or sprites censorship in the NGCD conversions, so for these games the sound associations would be welcome, but since I don't play these games much I haven't created the associations yet. It would be a great idea if we had here in the forum a data base for sound associations. If this feature ever comes to other emulators the emulation community would surely benefit from our work here. I have always had this idea but it is a little time consuming to check all the games and create associations for all of them. Here's my games.cfg file with all the associations that I currently have: https://drive.google.com/file/d/1LpbYDWrc16tmuQMuY2LSLL3H8cekTkNO/view?usp=sharing Thank you for your attention.

Hello Tux! So I made a quick test with my DS4 controller using the experimental 0.94.2 version posted in the other thread and here are my results so far: - the issue with the analog triggers is still present in this version, that is, if I am using the d-pad the movement will still be interrupted if I press any of the analog triggers. - I have noticed that the issue with the triggers will only occur if I first happen to use the left analog stick to move in the game, that is, the analog triggers movement won't interfere if I don't touch the left analog stick first in the game. - the right analog stick apparently no longer interrupts the d-pad movement. Ah, what a pity! I wasn't expecting it would be so hard to fix. Anyway, I just reported it because the result of two tracks playing at the same time is really awkward. But it's just a minor glitch though, so we can live with that for the time being. Thank you so much again for your help.

Hello Tux! I wasn't able to test this very experimental version because the forum says the attachment is "unavailable". But I did try the second one which you posted later and could no longer reproduce the music stop issue in KOF95. I tried both my save state and ffman1985's one with Rugal. By the way, I also experienced the graphics corruption in his save file. I wonder how he triggered that? Perhaps he could provide some more details... I also went and tried to reproduce the music change issue reported by ffman1985 in KOF94 and could replicate it consistently here by pressing ABC together to fill the power gauge with the Ryo character. Gladly this issue has also been fixed by the test version you provided. And just to correct what I said about KOF98, I experienced the "music stop" issue there once, but the "music change" bug was actually noticed in Art of Fighting 3. Unfortunately I wasn't able to reproduce it there easily to file a bug report, so I simply let it pass. Anyway, I hope that your fix for KOF94 and 95 can also work for AOF3 at least. I'll see if I can eventually reproduce the issue in KOF98 again. Thank you so much for your work.

Hello Tux! Thanks for considering a work around for this nuisance with the controllers configuration. I just would like to report that while trying to reproduce the sound associations bug in KOF95 discussed in the other thread, I guess I found a glitch in the sound associations menu. If you use "Test" to test a command and then "Play a track" in "Manage associations", both the sound command and the track will play simultaneously, which will result in a confusing sound. Perhaps selecting "Play a track" could stop the command which was playing before? Anyway, that's just it for now. Thank you so much again for your time and work in the emulator.

Hello guys! If you allow me to help, I was able to reproduce the "music stop" sound association issue in KOF95. I don't really know if it is indeed related to the Art of Fighting team (Ryo, Robert and Takuma characters), but I was using these characters as recommended by ffman1985. Gladly I was doing save states before every round started so I think I found a good place to easily reproduce it. You just have to hit the character Kyo with any punches or kickes. It doesn't matter if he guards or not your attacks, as long as they reach him. Here's the file: https://drive.google.com/file/d/1L1kd7eqmGFS9Nt5FjBJkBwUn9iYOuGja/view?usp=sharing Hopefully you both will be able to reproduce it in your setups. Curiously I had already experienced this music stop (and possibly the music change) issue in KOF98 before, but it happened so randomly during a match that I couldn't even find a safe way to reproduce it in order to file a bug report here in the forum, so I just forgot about it for a while hoping that I could finally reproduce it again some day. Well, maybe this day has come? Hopefully the KOF95 bug will be the same as the one in KOF94 and KOF98. I'm also posting my associations configuration for KOF95 in case you need it, here: [kof95:assoc] 33 = d:\unzipped\games\NEO-GEO CD\King of Fighters '95\King of Fighters 95 - Track 02.mp3 34 = d:\unzipped\games\NEO-GEO CD\King of Fighters '95\King of Fighters 95 - Track 09.mp3 loop34 = 1 35 = d:\unzipped\games\NEO-GEO CD\King of Fighters '95\King of Fighters 95 - Track 11.mp3 loop35 = 1 36 = d:\unzipped\games\NEO-GEO CD\King of Fighters '95\King of Fighters 95 - Track 13.mp3 loop36 = 1 37 = d:\unzipped\games\NEO-GEO CD\King of Fighters '95\King of Fighters 95 - Track 16.mp3 loop37 = 1 38 = d:\unzipped\games\NEO-GEO CD\King of Fighters '95\King of Fighters 95 - Track 19.mp3 loop38 = 1 39 = d:\unzipped\games\NEO-GEO CD\King of Fighters '95\King of Fighters 95 - Track 21.mp3 loop39 = 1 40 = d:\unzipped\games\NEO-GEO CD\King of Fighters '95\King of Fighters 95 - Track 23.mp3 loop40 = 1 41 = d:\unzipped\games\NEO-GEO CD\King of Fighters '95\King of Fighters 95 - Track 25.mp3 loop41 = 1 42 = d:\unzipped\games\NEO-GEO CD\King of Fighters '95\King of Fighters 95 - Track 29.mp3 loop42 = 1 43 = d:\unzipped\games\NEO-GEO CD\King of Fighters '95\King of Fighters 95 - Track 39.mp3 44 = d:\unzipped\games\NEO-GEO CD\King of Fighters '95\King of Fighters 95 - Track 04.mp3 loop44 = 1 45 = d:\unzipped\games\NEO-GEO CD\King of Fighters '95\King of Fighters 95 - Track 27.mp3 46 = d:\unzipped\games\NEO-GEO CD\King of Fighters '95\King of Fighters 95 - Track 28.mp3 48 = d:\unzipped\games\NEO-GEO CD\King of Fighters '95\King of Fighters 95 - Track 06.mp3 49 = d:\unzipped\games\NEO-GEO CD\King of Fighters '95\King of Fighters 95 - Track 08.mp3 51 = d:\unzipped\games\NEO-GEO CD\King of Fighters '95\King of Fighters 95 - Track 31.mp3 52 = d:\unzipped\games\NEO-GEO CD\King of Fighters '95\King of Fighters 95 - Track 36.mp3 53 = d:\unzipped\games\NEO-GEO CD\King of Fighters '95\King of Fighters 95 - Track 37.mp3 54 = d:\unzipped\games\NEO-GEO CD\King of Fighters '95\King of Fighters 95 - Track 38.mp3 55 = d:\unzipped\games\NEO-GEO CD\King of Fighters '95\King of Fighters 95 - Track 33.mp3 loop55 = 1 56 = d:\unzipped\games\NEO-GEO CD\King of Fighters '95\King of Fighters 95 - Track 03.mp3 loop56 = 1 57 = d:\unzipped\games\NEO-GEO CD\King of Fighters '95\King of Fighters 95 - Track 35.mp3 80 = d:\unzipped\games\NEO-GEO CD\King of Fighters '95\King of Fighters 95 - Track 41.mp3 The track that plays in the save state is track 09. Thank you for your attention! 👍

Hello Tux! Thanks for this new quick release! So I made a quick test here and I can no longer feel the imprecision in the mouse cursor, so I guess it has been definitely fixed! Except that, no other bug report for now. But I have a feature request: would it be possible to have an option to deactivate the analog inputs from the controller? I felt the need for that because sometimes I play with my Dual Shock 4 controller resting in my lap and eventually this will make the R2 or L2 triggers be slightly pressed. Unfortunately these triggers are analog in the Dual Shock 4 controller so Raine will register those presses as analog inputs too. If this happens during a d-pad movement, the d-pad will immediately stop working for a moment, which will cancel the movement I'm making. Here's an example comparing with what we have in FBNeo: https://drive.google.com/file/d/1TqIDy8Zb5acE2uCAlPJaSu5rvW4Tsz_V/view?usp=sharing As you see in the video, if I'm pressing, for instance, up in the directional pad to make the character jump in King of Fighters and suddenly hit any analog inputs, this will interrupt the d-pad registration and stop the character from going up. Maybe if the analog inputs didn't interrupt the d-pad registration this could avoid the sequence break? Anyway, it's not really a huge issue if you take care to not press those analog triggers and sticks accidentally, but it could happen eventually. Interestingly these triggers aren't even bound to any command in Raine but still they interfere in this analog detection. I'm using all the default bindings suggested by Raine for the Dual Shock 4 controller. Perhaps a "D-pad for movement: D-pad only" would work around that? I'll wait your comments on that. Thank you so much for your time and work. 👍