Raine 0.95.5 : big cps2 update !

[Tux]

Actually this version number was displayed for neocd in the title bar until may 29th 2021, commit 90761c9f7afc679394d550c4eb4f5e6ef3b42358. The commit was not specifically about that but to fix an incompatibility between 2 games, I guess I probably took it off because I found it made too long titles which is probably true for a lot of games there.

Oh well since you are the most efficient bug finder around here I can put it back... !

[mer-curious]

On 6/4/2023 at 8:47 AM, Tux said:

Oh well since you are the most efficient bug finder around here I can put it back... !

Hello Tux! Thank you so much for considering my suggestion and bringing back the version number for NGCD games! I really hope it helps someone besides me with the testings.

By the way, I have been playing a little more with some NGCD games and I think I've found two issues to discuss:

1-

The first loading animation for Samurai Shodown 3 is not adapted to the Japanese region the first time you load the game, as you see here:

But if you hard reset the game, it is finally adapted:

Surprisingly I have found a video of someone playing Samurais Spirits 3 in the real hardware and the first loading animation is indeed adapted to the Japanese language, as you see in the following video:

Please notice that he is using a CD drive emulator and loading the game from an SD card, but we can see that the first loading screen is in Japanese as well.

Perhaps there's something not detecting correctly the region we set when loading the game?

Anyway, I'll wait your comments on that.

2-

The picture in some NGCD games is not being drawn correctly the first time you load the game. To correct the picture you have to display the GUI and then return to the game. I've noticed this happening with two games so far, Samurai Shodown 3 and The Last Blade 2. Please take a look at the pictures below. The first is taken before the GUI is shown, and the second, after visiting the GUI:

Samurai Spirits 3:

The Last Blade 2:

I'm not sure if you could do anything to improve this as soon as the game is loaded, but I'm reporting it anyway.

Thank you so much in advance for your time and work. 👍

PS: I've created a pull to suggest a new default setting to the NGCD loading speed + some minor text revisions.

[Tux]

For your 1 you could have guessed the reason : when you load a neocd game the emulator doesn't know which game it is before it loads at least the 1st part, and so it does not know which region to apply 1st, so you have the default region 1st, that's all. Then once the game is identified, it gets the last region used for that game or its default region.

For your 2 I can't reproduce it for now, launched smasho3 with the us region in windowed mode (in linux), started the game, the picture is not cut on its right side, and displaying the gui doesn't change anything to it. If the bug is just because you are using a 640x480 window, just forget it ! I am not sure for now.

edit : and after testing in wine, I still can't reproduce this. No idea how you did that.

edit2 : and even in win10, and even with a 640x480 window, no cut on the right. Oh well... !

Edited June 8, 2023 by Tux

[mer-curious]

Hello Tux! Thank you so much for taking the time to test those issues.

So, for the adapted loading animation, I already have the game region set to Japan, so much so that if I hard reset the game it correctly shows the first loading animation in Japanese. But if I open the program and load the game it will show the "Samurai Shodown 3" animation instead of the "Samurai Spirits" one, even if I had already set the game to the "Japan" region before. Perhaps if you added an option to "NG/NGCD options" to set the default NGCD region even before the game was loaded would fix this? I'm not sure if this is doable though, but you see in the video that the real console does load the first loading animation correctly as far as I can tell.

As for the wrong picture width, I always set a new raine32_sdl.cfg file for every version I try, so everything is set to default here, except for the NGCDZ BIOS for NGCD and the Unibios 4.0 for NG games. Then I load The Last Blade 2 CUE file and have the issue with the picture width. It's a very weird bug indeed, but I can reproduce it very consistently. I have recorded a video clip showing that, here:
https://drive.google.com/file/d/1_wY1hJ-z5eguoJ7OBNr4jPqH_-6MyMXs/view?usp=sharing

You see in the video that even if I maximize the window the width won't be corrected, only if I ever show the GUI.

Hopefully you'll be able to reproduce this eventually and tell what could be happening. But these are minor issues nevertheless.

Thank you so much again for your time. 👍

Edited June 8, 2023 by mer-curious

[Tux]

For the 1, no having a setting for default region would be overkill, the default region is set to Europe for neocd games because raine is made in Europe. I guess I could detect the current locale and use japan instead if the locale is japenese, but even that would be quite overkill. It's not a problem of correct or not, it's just the game is not recognized before the 1st part is loaded. Once it's loaded if you reset the name doesn't change, so it knows how to take the right settings. So if you really want to see this animation, there's just a rest for you.

It's not an emulation bug neither, the neocd console has a fixed region so it always plays all games using the same region. Here we choose to allow the player to set the region independently for each game. So that produces a difference, but my goal is once again not to emulate precisely the console itself, but just to support neocd games as well as we can, that's all. The games are good, but the console itself is not interesting.

For the 2, I'll try later without any configuration file although I doubt it will make any difference, but it's annoying, it's always longer to retrieve the files needed in this case.

I reproduce it very easily with last blade 2, but not samsho3, go figure... ! Anyway, it was probably here since the beginning of the sdl2 version, so quite some time ago already, but it's right we played less neocd games with that version, and it was the kind of thing which could happen. Anyway the fix is just 1 line, very easy to fix. It affects the games with a width of 320 (although for some reason it's not so obvious for me in samsho3, there might be some other parameters there).

Anyway it's fixed... thanks for the report !

Edited June 8, 2023 by Tux

[mer-curious]

On 6/8/2023 at 7:37 AM, Tux said:

For the 1, no having a setting for default region would be overkill, the default region is set to Europe for neocd games because raine is made in Europe. I guess I could detect the current locale and use japan instead if the locale is japenese, but even that would be quite overkill. It's not a problem of correct or not, it's just the game is not recognized before the 1st part is loaded. Once it's loaded if you reset the name doesn't change, so it knows how to take the right settings. So if you really want to see this animation, there's just a rest for you.

Hello Tux! Thank you for this explanation. I'm not sure if I understood it correctly, but I still think Raine could let us decide which default region to use for NGCD games. However, I only felt the need for such a setting when playing Samurai Shodown 3 with the region set to Japan and found it strange that the emulator showed the English loading screen at the game start. So I'm not sure if such a setting would be really useful for any other game in the NGCD library or for anyone else playing NGCD games in Raine. So if you think it's really unnecessary and/or not doable for now, just leave it for another time maybe. Thank you again.

 

On 6/8/2023 at 7:37 AM, Tux said:

I reproduce it very easily with last blade 2, but not samsho3, go figure... !

Very weird indeed!

Anyway, I'm glad you could reproduce it at last.

Thank you so much again for your time and work. 👍

[mer-curious]

On 6/8/2023 at 7:37 AM, Tux said:

I reproduce it very easily with last blade 2, but not samsho3, go figure... !

Hello Tux! Revisiting this thread now I figure why: the issue with the game width was with Samurai Shodown 4, not 3! 😅 I was confused with playing both games and reporting two different issues about them in the same post. That's why you would never notice it with that game. Hopefully you also tested The Last Blade 2 too...

But you see in my previous post that the screenshot is indeed from Samurai Shodown 4. I just made a confusion with typing the wrong game title.

Anyway, this mistery is solved! 😁

Thank you!

[mer-curious]

On 6/3/2023 at 4:52 AM, Tux said:

I haven't got the latest one, but still more recent than that, I had to allow an update specifically to be able to update the nvidia driver, I couldn't install the latest version without that, so I guess you don't have the latest nvidia version neither ? It must be the 22h2 if I remember correctly, I disabled windows update after that and I hope to keep it at this level for long.

Well you are lucky it's minor, just a white cross instead of a green one, because supporting such a specific windows version would seem quite crazy. Anyway... !

edit : confirmed after verification, 22h2, installed late in march 23 because I blocked windows update before, and I still blocked an update on this version (I can now update the nvidia driver so it's enough for me).

Hello Tux! Happy New Year! ☺️

I finally had the opportunity to test Raine in my friend's laptop, which has the latest version of Windows installed, the same as yours, 22H2, and with the latest updates too.

To my surprise I could still reproduce the "green screen" bug in his machine. It seems the bug lies elsewhere then and is not specific to a Windows version, as you suspected.

You and ffman1985 mentioned that you both have AMD CPUs in your computers, right? So maybe the issue is related to Windows with Intel platforms? Or perhaps SDL and Intel platforms?

I'm posting a video clip of how I reproduce the problem in my friend's laptop so you can make sure you cannot reproduce it in your AMD computer. I'm using the latest unpatched Raine version, which is 0.95.5d. Here is the video:

https://drive.google.com/file/d/1A-Qd4-CsPOiRQAJx7yDzJbHVtNaWreaC/

If you do the steps above and cannot see the green screen bug, then it's definitely something with Windows and Intel platforms.

Unfortunately I don't know anyone with an AMD computer, so I would have to reach a store with a thumb drive and try Raine there in one of the available computers with AMD CPUs.

If you have access to an Intel computer you could also try that and possibly detect the cause?

Anyway, I think we are closer to resolving this mysterious bug in Raine. It's not an issue with Windows versions after all but probably something related to Intel and SDL and Windows or all of them together.

Thank you so much for your attention!

PS: sorry for bumping this old thread again, but the discussion started here, so I thought it could continue here.

[Tux]

Oh well since your video is so short I took the trouble to reproduce this here. Well in the meantime I updated my windose to win11, I was starting to get frustrated with mine, plus it was filling its partition because windows has a stupid way of handling its boot disk, so I bought a new ssd and installed a new windows on it, this was better. It's still a windows though so I still use it as little as possible, but it's better this way. Anyway I didn't have raine in the windows disk anymore because of this, so fresh install, I just grabbed the games.cfg containing your associations from the linux disk before rebooting in windows, I installed the latest version from the site, in 64 bits and latest version, didn't touch any setting, and no green screen here (I even downloaded the aof3 rom from raine, using internet archive, I noticed I wrote intrnet archive in the french translations, oh well...).

Sorry ! But I don't think it's related to the cpu anyway, but I don't know what it's related to then.

[mer-curious]

7 hours ago, Tux said:

Oh well since your video is so short I took the trouble to reproduce this here. Well in the meantime I updated my windose to win11

Hello Tux! Thank you so much for your time testing this bug again.

Yes, you updated the system but you are still using the same AMD CPU from before, right?

You and ffman1985 both use AMD processors, and the three systems I tried here use Intel, one from the 3rd, one from 5th and another from 10th Core generation. It's either the processor or the Intel/Nvidia graphics drivers, because I don't have AMD GPUs either...

But you also use an Nvidia GPU, right? That's why I think the issue is with the CPU...

Anyway, I'm sharing with you my Raine folder, which has virtually all the default configurations, but maybe there is something interesting to analyze there:

https://drive.google.com/file/d/11uGTMzCpUEC3NhgqXN6CfNMDFZVAAcGQ/

I even tried to update the SDL to the latest version in the root directory, but it didn't fix the bug unfortunately.

Interestingly while I was trying to reproduce this bug in this clean Raine setup the screen became green but reverted back to normal, which had never happened before (when the screen becomes green, it remains green until you hard reset the game or change it).

I'll try to get to a store with an AMD computer and test Raine there in a thumb drive.

Hopefully you'll find someone with an Intel platform too.

Thank you so much again for your time. 👍

PS:

7 hours ago, Tux said:

I installed the latest version from the site, in 64 bits and latest version, didn't touch any setting, and no green screen here

You should try version 0.95.5d because after that the green screen patch is present again in the code.

Edited January 3, 2024 by mer-curious

[Tux]

1 hour ago, mer-curious said:

PS:

You should try version 0.95.5d because after that the green screen patch is present again in the code.

Yeah with 0.95.5d I can reproduce it, but there is no point, that's the reason why I took back this workaround. From memory it happens only in windows...

[mer-curious]

1 hour ago, Tux said:

Yeah with 0.95.5d I can reproduce it, but there is no point, that's the reason why I took back this workaround. From memory it happens only in windows...

Hello Tux! Thanks for the fast reply.

I'm glad you could finally reproduce this bug again!

Actually this whole discussion started in this thread because you said the bug had already been fixed in SDL and that you couldn't reproduce it anymore in your Windows 10 installation, as you see here:

On 5/31/2023 at 7:59 AM, Tux said:

It's an old windows bug, but it was fixed in some sdl version, make sure you are using a recent sdl (latest SDL2.dll date is april 2023, version 2.26.4 in the about dialog). If you still have the bug with the latest sdl, then maybe the bug is fixed only for some graphic drivers and in this case I'll have to take my workaround back. For now I can't reproduce this at all, with wine in linux or directly in win10.

 

Then came ffman1985 and said he couldn't reproduce it either in Windows 11:

On 6/2/2023 at 12:44 AM, ffman1985 said:

Hello, Tux and mer-curious. I cannot trigger the green screen bug in 0.95.4d when opening the association list with green mark for loop. My PC is windows 11 64bit, and my laptop have an AMD igpu and the intel gtx 1660 ti max q (with a driver in May 2023), I think the AMD igpu is used when raine is operated. Also, I didn't make any change regarding the video except for the full screen.

That's why I started thinking it was an issue with my Windows 10 version, or my graphics card driver. But that seems to have been a very wrong guess...

To be honest when I visited my friend recently I asked his permission to format his drive and install the latest version of Windows 10 in his laptop just to test this issue with Raine. I took sometime to backup and restore his files, but it would be worth it trying. Hopefully I didn't do the same with my desktop, because it would have been all in vain...

 

Anyway, it looks like you both weren't triggering the bug correctly. If only I had recorded a video before...

At least the mystery is partially solved now.

Thank you so much again for your time.

 

PS: if ffman1985 really triggered the bug correctly as he described in his comment, maybe the bug is only affecting Nvidia and Intel GPUs?

 

[Tux]

You could just have left this all bug to rest, you know ?

Anyway to take a last look at it : the line is actually drawn by SDL2_gfx which was merged into raine, but they never fixed this part of the code anyway. Their line code uses this to set the color :

       result |= SDL_SetRenderDrawBlendMode(renderer, (a == 255) ? SDL_BLENDMODE_NONE : SDL_BLENDMODE_BLEND);

       result |= SDL_SetRenderDrawColor(renderer, r, g, b, a);

the doc from sdl says that this function affects only lines/rects (and FillRects) and points. Well it also clearly affects the opengl function to blit some pixels to the screen which is used by raine. The reason why it's only in windows is probably because in windows we are forced to use the opengl driver for video where in linux I leave the generic one.

Anyway a proper fix would simply be to get the current BlendMode and the current draw color before drawing the line, and restoring it when it's done, it should be done at the SDL2_gfx level normally, but I just checked and this function was never updated ! (it would take only 2 lines to do that !). On the other hand it would probably make programs using lots of lines slower, so it might be better do do otherwise like us here.

Oh well at least the current workaround works well... No idea why I wasn't able to do it in my previous install, might have gone too fast, actually I think you need to have the current selection of the dialog over something containing one of these green boxes when you close the dialog so that the BlendMode stays.

[Tux]

I got curious and did some more inquiry about this : finally the draw color & blend mode don't seem to matter, because they are not directly used. These functions are queued and executed directly by the video driver, so there is really some difference between what windows does and what linux does here, but not sure what. Linux also uses the opengl driver by default. So it's just a mystery, probably related to some low level driver stuff here. The good news though is that the behavior is correctly emulated by wine, I get the green screen when running the windows binary in linux through wine, it makes things easier to test at least !

So the only workaround which seems to work is the one which I used so far : finish the drawing with a white line so that the color is reseted and does not affect opengl blit operations. This was a really crazy bug for something which shouldn't have created any problem (it's just a basic drawing primitive, nothing should go wrong with that !).

Anyway I stop here.

[Tux]

And finally went to the bottom of it, there is a weird difference between the opengl implementation in windows and in linux, I don't know why, this thing is supposed to be standard, not made by microsoft normally... anyway what happens is that the draw color, set by a super standard function, glColor affects the pixel operations in windows, but not in linux !

When you know it, it's very easy to work around it, just set the drawing color to white when the opengl drawing starts, which means just 1 more function called when the "play game" option is selected, almost nothing. With this I can finally remove the 2 workarounds there were for this very stupid bug. It's committed, but it isn't worth a new binary just for that !