mer-curious

Hello Tux! I guess I found a good place in a game to clearly see the issue of vertical sync. In this stage in KOF97 there is an energy beam in the center of the stage as well as other beams around the scenario that are clearly affected by the way v-sync currently works. I've recorded a short video using both my desktop environment capture and my webcam. The screen tearing is more noticeable in the webcam, take a look: https://drive.google.com/file/d/14_WER63Hnp4jSn_9X7olbpMgJ7aD3CeU/view?usp=sharing As you see, the tearing in the light beams are very noticeable in the webcam, aren't they? You also have tearing when the red and white colors start flashing after a character is defeated. When I go to "Video info" it shows it is using "adaptive", and if I disable double buffer unfortunately nothing is changed. So I went and tried to add Raine to the programs list in the Nvidia Control Panel and then forced it to use V-sync "On". This way I could no longer see the screen tearing, it becomes virtually unnoticeable. Would it be possible to do this within the emulator? Maybe you could allow us to change the v-sync to "On" instead of "Adaptive" and this could fix this issue? Anyway, I guess at least it would be more user friendly than messing with the driver settings. For comparison, here's how it looks in FBNeo: https://drive.google.com/file/d/1VbwIqy5cF8qXdIcmCDLvet-5-DszSAZd/view?usp=sharing This is mostly the result I get in Raine when I force the V-sync option to "On" in the Nvidia settings. Thank you so much for your work.

Hello Tux! Thank you for the tip. But I don't seem to have this issue here in Firefox/Windows, take a look: https://imgur.com/d0j5mzA As for Alpha's promise for a dark theme in the forum, it is almost completing it's first anniversary. 😂😅

Hello Tux! Thank you for taking the time to test this issue. I'm happy to know you couldn't reproduce it there because this made me recall I didn't experience this slowdown before, at least as of some past versions of Raine. So I started thinking what might have changed in my setup to trigger this slowdown and when you said you reproduced it in the 64 bit version I finally realized this was exactly the change I made: I moved from the 32 bit to the 64 bit version of the program. So I went and tried the 32 bit version and you are totally right, there is no slowdown there neither in the KOF97 "how to play" animation nor in the KOF2001 order select screen. I will be then switching to the 32 bit version again for the time being. Do you think it is worth it to warn users about this choppiness of the 64 bit version? Perhaps adding in the downloads page that the 64 bit is "experimental" or something like this. I guess many developers do this for their 64 bit versions. Anyway, thank you so much again for your time and work. 👍

Hey Tux! I was finally replaying some K.O.F games lately in Raine and stumbled upon another place in which a slowdown clearly happens, much more noticeable than the one in KOF2001 which I reported some time ago in this thread. I've recorded a video so you can check how slow it compares to FBNeo, here: https://drive.google.com/file/d/1UvuYiH-cM93vl_TU3pTefNuZGUb_f2G7/view?usp=sharing I've also went and tried it with a pre-SDL2 version and curiously it's the same there, so the problem isn't really the SDL2 shift. Anyway, I'm reporting because maybe in this case it could be easier for you to see what could be happening here. Thank you in advance for your time and work. 👍

Hey Tux! I'm glad you could reproduce and fix this little issue. Maybe you should release a new version soon since the previous one in the Downloads page is crashing? I guess it could affect new users trying Raine. Or you could just remove revision C from there if you'd prefer. But in the end it is being good to release these revisions so users can try them and possibly report some minor issues, which is what I am doing lately. Anyway, thank you again for your great work. 🙂

Hello Tux! I would have edited my previous post for this, but since you have already replied to that, I decided to create another one. So, it seems that the crash is only triggered when using the mouse to navigate the "Change/Load Rom" menu. What I do exactly is: - I enter the "Change/Load Rom" option - I put the mouse cursor over the "Options" string (there is just that when you don't have a config file already setup) - As soon as I do that the program crashes It seems that if you remain using just the keyboard there, the crash won't happen. Anyway, just a quick update that might possibly help you reproduce the problem. Thank you again for your super fast support. 👍

Hey Tux! I'm so sorry for your being sick lately. Curiously I was feeling really sick too a couple of weeks ago. I don't know if it was Covid or "normal" influenza virus because I didn't go to the health care center to test (I preferred to just rest at home), but I suffered a lot in the first days. Hopefully I'm much better now. About the bug in the GUI, I went and tried version 0.93.5c but couldn't see if the fix worked because the emulator is crashing every time I visit the Change/Load Rom menu. I'm coming from a new installation (without the raine32_sdl.cfg file), so maybe this is triggering the crash? Anyway, I hope you get better soon and, when you do, check this issue if you have the time. Thank you again for your work.

Hey Tux! I guess I've just found a bug in the game selection screen in which the highlighted string will not follow the mouse cursor. It seems that the highlighted string remains stuck in the first page of the game list, which makes the navigation with mouse very confusing. I don't remember experiencing this issue before revision 0.93.5b, so maybe it was introduced in it? Anyway, I didn't want you to make a third revision of this version, but I'm reporting it so you can check it if/when you have the time to. By the way, I've recorded a short video so you can check what I'm experiencing here. Take a look: https://drive.google.com/file/d/1vumoOjPwnsBo-9Ve_foFCDM-r41JyacG/view?usp=sharing Thank you so much again for your work. 👍 PS: I tried deleting my raine32_sdl.cfg file but it didn't help much unfortunately.

I did that and it kept the same unfortunately. Now that you said it could be a browser issue (I was using Firefox) I went and tried loading the page with another browser (Chrome) and still couldn't see the updated link. Anyway, thanks again for your fast response.

Hello Tux! I'm so glad you could reproduce and fix these little issues. I hope it haven't taken too much of your time. I went and tried it and everything is fixed indeed. Thank you so much for that. 👍 By the way, you forgot to update the download links in the Downloads page. I was clever enough to remember the first revision link was "0.93.5a.7z", then I just edited the link to "0.93.5b.7z" and gained access to the file. Anyway, thank you again for your work.

Thank you. I think this behavior is present for some versions already as far as I remember. Perhaps since introducing the Joystick indexes option? Interesting. I did some more tests here and it seems to affect all the games that I've tested. I tested KOF99, KOF97, Captain Commando and Marvel Super Heroes, so it seems to be happening with the NG, CPS1 and CPS2 drivers. Maybe it's exclusive to the Windows version? Anyway, let's see if you can reproduce it somehow if/when you have the time for that. Thank you so much again for your continuing work. 👍 PS: now that Raine is in SDL2, would it be easier to implement a vertical sync option to avoid screen tearing? I think this option would come in handy to avoid messing with the Nvidia Control Panel (or Radeon Adrenalin), especially when you don't want to enable it globally in the drivers for all the programs and when you create different installations to test Raine, for instance.

Thank you for the super fast fix, Tux. 😊 In fact, I didn't even realize there were two "mouse sensitivity" options there because I was very used to seeing the "Joystick indexes" option available. That's why I may have not tried clicking on those mouse options in the first place, I guess. I've just tested it and it works now. Thanks! 👍 By the way, when we use the mouse to navigate in the Inputs menu we have to have the cursor placed in the mouse sensitivity slider in order that the Joystick indexes option may be highlighted and selected. It's a little difficult to get used to this since it doesn't happen in any other place in the GUI. But anyway, just a little nuisance. Finally, the Driver info and History options in the "About" dialog are swapped. At first I thought I had clicked on the wrong option but then I realized the names are indeed swapped. That's my little feedback for now. Thank you so much for your time.

Hey Tux! I'm so sorry for your dog. He/she must have been a dear member of your family for being with you for so many years. I also have a cat that is with us for over 10 years. Anyway, I wish he/she may have had a good passing. 😴 Talking about Raine, I tested this new version and so far it seems to be working correctly, except that I can no longer find the "Joystick index" option in the Inputs menu. Has it been removed? Without that option I cannot decide which controller will be assigned to what player. I'm currently working around this by unplugging the controllers I don't want to use, but it was more user-friendly to have that option available, if it could be re-added. Anyway, thank you so much for this new release and, indeed, for keeping Raine alive. 👍 PS: I may have missed the bugs with NGCD emulation because I haven't been using it so much lately since I associated most of the NGCD arranged sound tracks to the NG rom version of the games to avoid the NGCD sprites cut. So that's why I didn't report it here before.

Hello Tux! Thanks for letting us know about this improvement! I may have stumbled upon this issue with one of my game controller adapters but I didn't realize it was a bug and just thought it was the way the unconventional controller worked with Raine. Anyway, thanks again! 😊

Hey Tux! Thank you so much again for your fast support. So again, I went and tried this new test version and gladly the problem seems to be gone finally! 🙌 I tried both desktop and real full-screen modes and could no longer see the blank screen when leaving full-screen mode using the keyboard Alt+Enter shortcut. I also took the opportunity to try it with the intel integrated graphics, both the Skylake+ drivers (buggy OpenGL) and the old HD 4000 (good OpenGL) and the issue is fixed with them too fortunately. So in the end it was good to update this thread with my driver update testings. But I'm curious on what was causing this issue. Was it really the SDL2 upgrade as I guessed? Anyway, thank you so much for your work in this little nuisance. 😊👍 PS: the new raine.exe version for testing in the 7z file has a "modified date" of 2022-05-06 14:09, perhaps because of the different time zone? And in the "About..." dialog it shows "May 6 2022 13:48:53", but I suppose it's this the version I had to try, right?

Hey Tux! Thanks for the super fast reply! I guess this "mode" I was referring to in my first post was the real full-screen mode which you were discussing in Raine's Github. But, as we can see, it didn't fix the blank picture issue. I'm really glad you could reproduce this problem again there, since it was very easy to trigger it here in different setups and Windows versions. You are right, you just have to leave full-screen mode in-game and the picture should be blank in windowed mode. So, I went and tried the test version you have made available (for Windows 10 only?) but unfortunately I can still reproduce the problem there. I even tried enabling real full-screen mode to see if it would help but it didn't. Since it didn't happen before the SDL2 migration, my guess is that it should be something related to it? Or the way the window is composed after leaving full-screen? Anyway, I wish I could help you further on that but my coding knowledge is nonexistent sadly. Oh, this observation is still valid for this test version. If you leave full-screen mode from the GUI the issue isn't triggered, which is quite interesting. 🤔 Thank you so much again for your continuing support of Raine. 🙂

Hello Tux! I was finally able to test Raine again with an NVIDIA GPU and with updated drivers and unfortunately I can confirm that the "blank-screen after leaving full-screen mode" issue still persists even with the newer drivers. Previously I was using driver version 456.71 (from October 2020) which was quite old, that's why I thought maybe updating them could resolve the issue. But even after installing latest 512.59 (from April 2022) I can still see the blank-screen in Raine. 😔 I can reproduce this bug 100% of the times I test it, so it should be easy for you to test it if you try it on Windows. I've tried it both in Windows 10 (with intel and nvidia drivers) and in Windows 8.1 (with intel HD 4000 graphics). Anyway, just a quick update to keep my promise on testing this again with updated drivers. Thank you so much for your time and attention.

Hey Tux! Thank you so much for providing a test version to see how this new full-screen mode could work with the use-cases I've reported before. But I already have to apologize for bothering you about this feature because I guess you were right after all when you said in the Github discussion that the real full-screen mode wouldn't change a thing. Well, I went and asked my friend again to send me some Telegram messages to see if the notifications would still intefere in the real full-screen mode, and they do. As for the speed in which the screen blinks, sometimes I notice it is faster now (which is way better to keep playing), and sometimes it is the same as the borderless mode, so it looks like the issue is unresolved unfortunately. I suppose it should be related to the crappy intel Skylake+ OGL drivers. It's a pity they focus so much on D3D in Windows and forget about OGL users... Sadly I still could reproduce the blank screen leaving the full-screen even with this new real full-screen mode. But it is interesting that you couldn't reproduce it with a discrete Nvidia card, because it does happen with my Nvidia card too, and their OGL drivers are pretty good on Windows, so I guess there's still something to investigate here. Perhaps my drivers were out of date? I'll see if I can reach my father's PC again (it is where the card is installed) and try Raine there with updated drivers. If this fix the problem, than that was surprisingly Nvidia's fault in the end. I'll let you know when I do it. 👍 Thank you for your reasoning on this matter. I naively thought it would have the same effect as the "exclusive full-screen mode" from D3D which I showed deals better with those notifications in the Duckstation video, but it looks like things are different for OGL and SDL then? Anyway, thank you so much again for your time and work creating this test version. 👍 PS: are you considering leaving this new full-screen option available in Raine for an official release?

Hey Tux! I saw the discussion on Raine's Github page on the inclusion of a real full-screen mode in Raine and I was wondering if I could think of some use-cases for that. Well, maybe a real full-screen mode could fix the "blank picture" issue which we have in Windows after leaving the current borderless full-screen mode?* Also, there's a nuissance which happens every time a notification pops up in desktop: it blinks the picture for a brief moment, which interferes in our borderless full-screen game-play. I know it could be worked around by simply closing the application which sends the notification, but perhaps this could be another use-case for a real full-screen mode to help? I've asked a friend of mine to send me a Telegram message while I was playing in Raine using borderless full-screen to show you how it goes when it happens. I had to use my webcam as a monitoring source for this particular recording because for some reason OBS cannot capture Raine in borderless full-screen (everything is black). Take a look: https://drive.google.com/file/d/1DhNBa_uQmFKsgwkfK8qcpLjJHNiCJCzW/view?usp=sharing You'll notice from the monitoring camera that when the message pops up on desktop the screen blinks for a moment, and when it vanishes the picture blinks a second time. For fast-action games such as fighting games and shoot'em ups this could somewhat spoil the game-play experience, especially if you receive more than one message. But I'm not sure if this is a side-effect of the cheap intel (Skylake+) OpenGL drivers. But maybe the real full-screen could help reduce this blink time? I also asked my friend to send me a message when I was testing Duckstation with the Direct3D renderer and the blink doesn't happen there. We can hear the notification sound but it doesn't pop up in the screen hopefully. Take a look: https://drive.google.com/file/d/10PVJzh8cPYYqNbxzOYaMpRXNzuh7ErVn/view?usp=sharing If you pay attention, by second 21~22 in the video you hear the Telegram notification sound but it doesn't distract the picture. Anyway, perhaps it could be worth it to enable this mode and check whether or not it would help in these use-cases. Thank you for your time and work. 🙂 * I've noticed doing this testing that when you leave the borderless full-screen mode through the GUI the blank picture isn't produced, so it seems an issue isolated to the game picture rendering, no? 🤔

Great news Tux! I agree with you, I think it's better to switch again to the faster DLL once the bug is now fixed and everything works normally. Thank you again for your work.

Hey Tux! I'm sorry for the late reply. Don't worry about the shaders, it was just a suggestion that came to my mind again when I found this pack from Emu-France. By the way, have your motivation to add the Konami drivers for TMNT Turtles in Time and Sunset Riders increased somehow lately or are these drivers really too complicated to support? Anyway, I was doing some game-play tests with KOF99 in the FBNeo Retroarch core and stumbled upon this very weird Unibios error: https://imgur.com/a/Kv5GxCY I never expected the Unibios to hang the game like that. It has never happened to me in Raine fortunately. Should I report this error to the FBNeo core maintainer or is this expected when using the Unibios? Thank you in advance for your attention.

Hey Tux! Thanks for this super fast fix! I'm glad it wasn't that hard to fix in the end! 🙏 By the way, I've stumbled upon this site which collects shaders for various emulators: https://emulation.gametechwiki.com/index.php/Shaders_and_Filters In the Emu-France shaders pack for Raine/BSnes there are some which aren't bundled with Raine. I was thinking if it would be a good idea to link to this page/pack in Raine's downloads page? Maybe this could help new users know about them and try them. However, there are some shaders in this pack which didn't work here. The 2xSal-convert gave me a black screen and the two NTSC ones returned a syntax error. But except these there are some interesting ones such as XBRZx4, scanlines-3x and 5xBR-v3.7c+CRT.OpenGL(hunterk). But I still dream of Raine supporting the new GLSL shader format one day, which currently have much more shader options than we find in this pack, for example, for CRT/scanlines, see the numerous possibilities here: https://github.com/libretro/glsl-shaders/tree/master/crt/shaders I've already played with some of them in Retroarch and some work really well with these old arcade games. Anyway, just some suggestions to consider for future releases. Thank you so much again for your time and work. 👍

Hey Tux! Just a quick feedback about the sound associations issues which I reported in the other thread: everything is working correctly now. The only issue I noticed is if a track start playing in the game, and then before it finishes you decide to enable the loop effect for it, when you return to the game the loop function will not take effect immediately, that is, the track will end and stop. I don't know if it's a limitation of the function, so I'm just reporting in case you didn't know about it. But I found a work-around for this: if you enable the loop function and click on "play track" in "Manage associations", the loop will work for that very turn of the game. Anyway, it would be just a tiny refinement since I cannot think of many use cases for this. I only stumbled upon it doing some later adjustments in my KOF2001 associations. Thank you so much for this very fast new release!

Hey Tux! I'm really glad you could detect the problem and fix it. It's a pity they haven't fixed that yet in the source but hopefully they will sooner or later and then you could return to new SDL2 decoder again. I guess I hadn't noticed this bug in the latest releases because most of the associated tracks I use come from official releases such as soundtrack albums or NGCD games, and they generally have silence added to the end of each track. But I took the KOF2001 tracks from the PS2 release of the game using a program to extract sound files from the ISO image, so that's why they are unedited once the effects such as fade out or loop are applied on the fly by the game code itself. What a crazy bug indeed! But fortunately you found a way to work it around. Thanks for that! Just out of curiosity I tried the KOF2001 PS2 release in the PCSX2 emulator and I also have some frame drops in this screen there. So maybe this part is really CPU intensive for some reason or it was not correctly programmed by the game creators, which also happened with Metal Slug 2 (plagued with slowdowns) and then fixed in Metal Slug X. But then FBNeo doesn't show this slowdown in this screen, so it seems there is really something going on here... 🤔 Anyway, thank you so much for your work in this great set of fixes and improvements!

Hey Tux! Thanks for your super fast reply! You are correct, this feature is working fine here. I had the impression it was playing both the sound command and external file because I only tested this with KOF2001 and the new tracks for this game were very poorly arranged due to the SNK's bankruptcy in the beginning of the 2000's, to the point I thought I was listening to the original music files, when it was actually playing the PS2 enhanced ones. I'm sorry for that! Ok, thanks for the info! It's probably a graphical glitch in the GUI then, right? Ok, this is not a big deal. It's just that being able to preview the looping effect makes the association settings more user-friendly. Thank you for your clarification. I guess now this option makes more sense there. 👍 Interesting. Here I can play this track normally until the end in all the players I've tested with it, namely foobar2000, Media Player Classic, VLC, Windows Media Player and Chrome. I used foobar2000 to convert the wav tracks to mp3 using the LAME encoder, which is a very popular mp3 encoder. Also, Raine 0.91.18 plays fine this file without cutting the last second. I've tried to convert the file with LAME encoder again using a constant bit rate profile but it still kept skipping the last part of the track. Then I tried a generic mp3 encoder in VLC and the cut not only persisted but got worse in Raine. Finally, I tried this new converted file in Raine 0.91.18 and there was no cut there. So there seems to be some kind of incompatibility with Raine SDL2 in terms of playing (some) mp3 files integrally? Anyway, converting the tracks using the Ogg Vorbis format works around this issue for the moment with the latest Raine versions. Thank you for this fast fix. 👍 I'm happy you were able to reproduce it somehow. I could try to switch to Linux eventually, but I suppose it's also good to have this stability parity between different operational systems. Interesting. I don't remember that exactly now. But anyway, I guess fixing this slowdown could benefit other NG games too perhaps? Thank you so much again for your attention and time spent with all this testing. 🙏