Raine 0.95.5 : big cps2 update !

[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 !

[Tux]

... and some last words about this bug :

actually the reason why I couldn't reproduce it is simply because in my saved settings the profiler display is almost always enabled (the 3rd one, the one with % numbers), that's the f11 key, and this key would have fixed the green screen bug too if you had used it because by default it uses opengl text, and so it calls glColor to set the color of the text to white, this time it's normal behavior since the text is monochrome, the non standard behavior is for color pixels of the game bitmap. It works also for the f1 key (reset) because you get some texts at the bottom of the screen to tell about the cpu(s) being reseted, and so it calls glColor too...

So if you had had a simple profile display enabled in your settings you would probably never have seen this bug, but yeah most of the time you install to a new dir so it's back to default settings all the time...

Everything is solved !

[mer-curious]

Hello Tux! I'm so glad you could finally fix this crazy bug! Considering the time we had lived with it, I think you were really fast in fixing it this time!

Anyway, it was then worth it installing the new Windows version in my friend's laptop and bumping this thread again with an update in my testings.

Thanks again for your motivation in this work and also for the patience in providing the details about it.

 

5 hours ago, Tux said:

which means just 1 more function called when the "play game" option is selected, almost nothing.

Just to be sure, it will also work correctly if we simply use the ESC key to return to the game, and not just the "Play game" menu option, right?

 

1 hour ago, Tux said:

It works also for the f1 key (reset) because you get some texts at the bottom of the screen to tell about the cpu(s) being reseted, and so it calls glColor too...

Interestingly, if you trigger the green screen bug and reload the game by using the Recents or Most Played lists, it will also fix the bug even if there are no white messages displayed at the screen (at least I can't see them... 🤔).

 

Now I have two requests for a new upcoming Raine release:

1) I'd like to ask you to add support for the Samurai Showdown 2 Perfect Edition romset. It's a hack of the original Samurai Showdown 2 with some (perhaps many) improvements. It's currently in version 1.8 as you see in this commit:

https://github.com/finalburnneo/FBNeo/commit/3a422761de5f5ceb85d51d7cd0a14a462e292655

Perhaps the authors will make more adjustments to the game, but then we could simply provide the new roms, right?

You can find the romset already updated here:

https://archive.org/details/fbnarcade-fullnonmerged

 

2) Finally, I've noticed that we can't reload the game by clicking on it in the Game Selection list. This is only possible if we use the Recents or the Most Played lists. Would it be possible to enable the reload function to the normal list too?

I felt the need for that when I was testing the green screen bug in Art of Fighting 3 and tried to reload the game by clicking on it in the Game selection list. I'm not sure why, but maybe this was the most intuitive path I found to reload the game, and then I found that only the Recents and Most played lists would work for that, which I found curious...

Anyway, it's not really something necessary but just an alternative for the "hard reset" function I guess, and perhaps a more intuitive way to use for this function. But if it's too complicated, just let it for another time.

 

That's it for this very long post. Thank you again for your time! 😃

Edited January 4 by mer-curious

[Tux]

3 hours ago, mer-curious said:

Hello Tux! I'm so glad you could finally fix this crazy bug! Considering the time we had lived with it, I think you were really fast in fixing it this time!

Anyway, it was then worth it installing the new Windows version in my friend's laptop and bumping this thread again with an update in my testings.

Thanks again for your motivation in this work and also for the patience in providing the details about it.

Err I disagree here, I think the previous workaround was enough. The reason why it was fast this time was simply because I was finally able to reproduce it, previously I had to make a fix blindly.

And also I found that you deserved to know all about it considering the time you spent on it !

3 hours ago, mer-curious said:

Just to be sure, it will also work correctly if we simply use the ESC key to return to the game, and not just the "Play game" menu option, right?

Of course

3 hours ago, mer-curious said:

Interestingly, if you trigger the green screen bug and reload the game by using the Recents or Most Played lists, it will also fix the bug even if there are no white messages displayed at the screen (at least I can't see them... 🤔).

Any use of a colored line in the gui would make it to go away, as any key using the overlay gui (f2, f3, f4 and the layer keys if they are used by the current driver).

3 hours ago, mer-curious said:

Now I have two requests for a new upcoming Raine release:

1) I'd like to ask you to add support for the Samurai Showdown 2 Perfect Edition romset. It's a hack of the original Samurai Showdown 2 with some (perhaps many) improvements. It's currently in version 1.8 as you see in this commit:

https://github.com/finalburnneo/FBNeo/commit/3a422761de5f5ceb85d51d7cd0a14a462e292655

Perhaps the authors will make more adjustments to the game, but then we could simply provide the new roms, right?

You can find the romset already updated here:

https://archive.org/details/fbnarcade-fullnonmerged

Remember ? I am retired !

Plus you are dreaming here, the last commit you show in fbneo is from december 2023, but internet archive is notoriously slow to update its romsets, the dates of the files you are linking to are from april 2023 (click "show all").

If you find where this romset is coming from and how we can get reliable updates, I will consider it.

3 hours ago, mer-curious said:

2) Finally, I've noticed that we can't reload the game by clicking on it in the Game Selection list. This is only possible if we use the Recents or the Most Played lists. Would it be possible to enable the reload function to the normal list too?

I felt the need for that when I was testing the green screen bug in Art of Fighting 3 and tried to reload the game by clicking on it in the Game selection list. I'm not sure why, but maybe this was the most intuitive path I found to reload the game, and then I found that only the Recents and Most played lists would work for that, which I found curious...

Anyway, it's not really something necessary but just an alternative for the "hard reset" function I guess, and perhaps a more intuitive way to use for this function. But if it's too complicated, just let it for another time.

 

That's it for this very long post. Thank you again for your time! 😃

It's actually the other way around, I just forgot to add a test to check that we don't try to load the same game when accessing these lists of games, and this test is already present for the main list of games. I should add it yeah... !

And so you'll just have to either press f1 or load another game 1st, or quit and reload.

[mer-curious]

20 hours ago, Tux said:

Err I disagree here, I think the previous workaround was enough. The reason why it was fast this time was simply because I was finally able to reproduce it, previously I had to make a fix blindly.

And also I found that you deserved to know all about it considering the time you spent on it !

Ah, OK. Sorry for the misunderstanding. I thought you had already reproduced it before.

Anyway, thanks for taking the time to fix it definitely now!

 

20 hours ago, Tux said:

Any use of a colored line in the gui would make it to go away, as any key using the overlay gui (f2, f3, f4 and the layer keys if they are used by the current driver).

Ok, I understand now. 👍

 

20 hours ago, Tux said:

Remember ? I am retired !

😅

 

20 hours ago, Tux said:

Plus you are dreaming here, the last commit you show in fbneo is from december 2023, but internet archive is notoriously slow to update its romsets, the dates of the files you are linking to are from april 2023 (click "show all").

If you find where this romset is coming from and how we can get reliable updates, I will consider it.

Good news: the romset in archive.org is indeed updated, as you see in the CRC comparison below:

You have to click on "ZIP" in archive.org and look for the individual romset to download it.

According to the uploader, it is maintained updated, as you read here:

 

I also found in Google a site called Retroroms with a series of "FBNeo sooner" threads in which one of the authors of this mod shares the new rom files, as you see here:

source: https://www.retroroms.info/forum/topic/FBNeo-sooner-1-0-0-3.46001.htm

This site also has a downloads section with lists of roms based on emulators, and there is also a list for Raine.

Finally, I messaged the authors in GitHub to see whether there is an "official" site for the game. But at least we know now that all these popular places have updated files.

 

20 hours ago, Tux said:

It's actually the other way around, I just forgot to add a test to check that we don't try to load the same game when accessing these lists of games, and this test is already present for the main list of games. I should add it yeah... !

And so you'll just have to either press f1 or load another game 1st, or quit and reload.

Ok. I just found it more intuitive to just go there in the game list and try reloading the game by clicking on it. I think some other emulators like FBNeo allow the user to do this too.

Perhaps you could add a message such as "Game already running. Reload? Yes / No" when clicking on a game already running and let the user decide to reset it?

Anyway, just an idea I had when using this function through the Recents list recently.

Thank you so much again for your time.

Edited January 5 by mer-curious

[Tux]

Ok, you convinced me, but it's not one of these basic clones we had lately, this one adds a new mapping for the rom, it's not mapped as the others, so I'll need to look into it in more detail...

Congratulations for the motivation though !

Ok, it was not so complex finally, the neogeo system is full of hacks, the mapping of the code rom is :

from 0 to 0xfffff normal basic mapping for 0x100000 bytes

then if the size is > 0x100000 you get something more

0x200000 to 0x2fffff rom bank and then if there is a write in the 16 last bytes of this region (which is rom so the writes are supposed to be ignored), then it's supposed to be a bankswitch based on the byte written to be able to access any address > 0x200000

This one uses the mapping at 0x200000 but not the bankswitch and its size is > 0x200000

it adds a new area which was unused so far :

0x900000 - 0x9fffff code rom starting at 0x200000 !

I tested it, it seems to work, assuming the code doesn't try to access any address beyond the end of its rom it should be ok, it seems good for the small test I did. I'll post a binary later, you won it. You should take a look at the git log for adding this rom, it's not so hard to do, except here I added the mapping for 0x900000 plus a new define rom ROM_END instead of copying lines all the time... So that you'll be able to add your own clones later !

 

[mer-curious]

17 hours ago, Tux said:

Ok, you convinced me, but it's not one of these basic clones we had lately, this one adds a new mapping for the rom, it's not mapped as the others, so I'll need to look into it in more detail...

Thank you Tux for your work in adding this rom. I didn't expect it would need any especial programming rather than allowing Raine to see the new driver. Hopefully it didn't give you so much work. 🙏

I tried it here one turn until the final boss and it's working pretty normally. The sound associations also work for this clone, I just had to add a new entry in games.cfg with the same associations from the original samsho2.

Thank you again for this.

 

17 hours ago, Tux said:

You should take a look at the git log for adding this rom, it's not so hard to do, except here I added the mapping for 0x900000 plus a new define rom ROM_END instead of copying lines all the time... So that you'll be able to add your own clones later !

Yes, I took a look at the code added and I guess I understood most of what you did, but perhaps I would still need a hand of yours if possibly adding a new "version 1.9" of this hack in the future...

By the way, in line 1265 there is a typo:

We have "samsho5pe" after the /, when it was supposed to be "samsho2pe", no?

Anyway, this probably won't affect the game emulation, right?

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