0.96.5 : a super tiny update !

[Tux]

All the motivation of mer-curious brought this, it's mainly for samsho2pe, "samurai shodwon II perfect hack v1.8", thanks to the info found in final burn neo. This is a special hack this time since it adds a new memory rom mapping to the neogeo driver, never seen before in raine.

Except that I got rid of index_roms.html finally, this file was here as a quick way to get the roms sizes, but actually using the head http command is more efficient (!), and got a proper fix for this weird green screen bug that mer-curious had in windows for way too long... !

That's all folks !!!

http://raine.1emulation.com/download/latest.html

[mer-curious]

Hello Tux!

Here's a quick report for this new small update:

- the green screen bug after visiting a menu with green marks is indeed gone in Windows! I tested it in two Windows systems.

- the new Samurai Shodown 2 Perfect Edition is working normally as reported in the other thread. However, I found a graphics corruption in a certain part of the game which also happens in FBNeo, take a look:

It may be an issue with the hack itself because it doesn't happen in the original game. Here's a save state in case you'd like to check it:

https://drive.google.com/file/d/1Zo404KDruAwZZWGwEGTJ7K7PTAkKzaDw/

- finally, playing with this clone I've found a GUI glitch. The save states for a cloned game will show in the GUI for its parent rom, but they won't work/load. As an example, here are the saves for samsho2pe:

The GUI shows them correctly.

Now, if you open the parent rom, samsho2, this is what you get:

The last save slot was created in the parent rom and is the only one working. The others are taken from the cloned samsho2pe and when you try load them they all load the same save for samsho2.

This glitch does not occur the other way round, that is, if you have states saved for the parent they won't incorrectly show for the cloned rom.

It becomes confusing to manage the save slots in GUI when this issue happens. I'm posting my save files so you can reproduce it there:

https://drive.google.com/file/d/1Yx9iwGSmV7wKe1nk4CHzWO_jq5dnMYI-/

It should be an old GUI glitch because I don't play with cloned roms normally. Otherwise I would have noticed it before.

Anyway, that's my quick feedback for now.

Thanks a lot for this new release! 👍

EDIT: I have just found that the neogeo.saveram information is also shared between these two games. Take a look:

This was made in the original rom, samsho2.

Now if we load the perfect edition, this is what we have:

I'm not sure if this happens for all parent-clone roms in Raine. But I suppose they should have separate save score information, no?

Maybe this is linked with the save states issue above? I'll wait your comments on that...

Edited January 6 by mer-curious

[Tux]

The glitch : most probably a hack problem, I agree, too bad you don't have the url for the original author, you could post there to be sure.

The savegames in the gui : probably the most underused function of raine, never used it myself, but you are right and I just fixed it in git, it just shows this thing is never used.

The neogeo saveram : To be totally sure there are 2 kinds of data here, the memory card, which is game specific, in neocd and AES systems if I am not wrong (the non arcade one), and the neogeo saveram. The saveram is shared by multiple games, that's how the neogeo system is made. Remember it's a cartridge system, even at the arcade level. Here it's a hack, so it's totally normal that it tries to access the data from samsho2. There are functions in the bios, particularly in the uni bios to explore what was saved in the saveram.

For raine internally, the memory card is saved under <game name>-neogeo.bin in savedata, so it's really game specific, and the saveram is saved in neogeo.saveram only, in savedata too.

Here it looks like the hiscore screen, some games are saving to a .hi file in raine, but most neogeo games save their scores to the saveram, and that's the case for these 2. Notice that the capacity of the saveram is far from infinite so if you play a lot of neogeo games, the oldest ones disappear from the saveram... !

[Tux]

And bam ! The curl system is a little broken again ! I was too fast to think the file sizes were correctly reported by internet archive, they are correctly reported only for the fbneo archive probably because it's the only one which is not inside a zip file ! It would be nice to take this one as the main archive except the neogeo games inside this one contain all the neogeo bioses, which makes them quite bigger !

So, ultimate solution in git : re-create the index html I had before, but this time on the fly, saved in the raine directory, 2 indexes now, one for the raine archive, the other for the finalburn archive, no need for fbneo since it reports correctly its sizes. Then use the html files to extract the sizes when they are needed.

It works, there won't be an update just for that because the current version seems usable anyway even with this. The progress dialog looks bad because the size returned for everything which is not in the fbneo archive is -1, but it works anyway. So it will stay like that for now, update next time for finally a solid curl solution for all this mess !

Notice there are obviously multiple servers serving internet archive requests, some are very fast, but some are very slow, the download speed can change hugely depending on the server you get... !

[mer-curious]

4 hours ago, Tux said:

The glitch : most probably a hack problem, I agree, too bad you don't have the url for the original author, you could post there to be sure.

Hello Tux! Thanks for the fast reply!

I'll see if I can create an issue report in FBNeo GitHub and see if the authors of the samsho2 hack show there.

 

4 hours ago, Tux said:

The savegames in the gui : probably the most underused function of raine, never used it myself, but you are right and I just fixed it in git, it just shows this thing is never used.

Yes, I've been using it a lot when playing Raine in a TV and from a distance, especially with difficult games such as Samurai Shodown that makes me create some save states in order to win.

 

4 hours ago, Tux said:

and the saveram is saved in neogeo.saveram only, in savedata too.

Yes, when I deleted this file the high score for both of these games disappeared, so they were really using this file for that.

Isn't it possible to have a "saveram" file for each NeoGeo game we load? I believe FBNeo does something like that.

I found this explanation from a FBNeo developer:

source: https://retropie.org.uk/forum/topic/25014/fbneo-high-score-saving-trouble/5

I checked my FBNeo folder and these *.fs and *.nv are very small files, 1kb. *.fs seems to be created for NG games and *.nv for other systems such as CPS1 and 2. This is a screenshot from my folder:

This would be a good solution for not losing scores for precious NG games. For instance, sometimes I open a NG game just to test a bug in Raine or see if the game is fun but by doing that I risk losing my precious scores for the other games which were first in the neogeo.saveram file.

Anyway, I'm not sure if this would be complicated, so I'll wait your comments on that.

Thank you so much again for your time and work!

Edited January 6 by mer-curious

[Tux]

It doesn't say anything like that ! The eeprom is saved by raine too but there is no eeprom in the neogeo. Its nv files are probably the contents of the memory card. The neogeo saveram is bigger, 64k, nowdays 64k is nothing, but at the time non volatile ram was very expensive, it was the same thing for the ps1 "card" where it stored its saves, it was a few kb also at the time.

Well I never understood why the games don't save their hiscores in their memory card, would seem more reasonable to avoid any overwrite. Plus it seems it has a memory card for both modes, aes/mvs here (for samsho2pe). Well I am not a super big fan of 64k files / neogeo game where only a tiny portion of the file would be used. Eventually an option by user, default being share everything.

[Tux]

8 hours ago, mer-curious said:

Yes, I've been using it a lot when playing Raine in a TV and from a distance, especially with difficult games such as Samurai Shodown that makes me create some save states in order to win.

I would advise a cable-less keyboard for this kind of case ! I hate this kind of keyboard for normal use, but for this use specifically it turns the keyboard into a remote control ! If you also install some dvr program which can run without any mouse, it can become quite awesome !

[mer-curious]

9 hours ago, Tux said:

It doesn't say anything like that ! The eeprom is saved by raine too but there is no eeprom in the neogeo. Its nv files are probably the contents of the memory card. The neogeo saveram is bigger, 64k, nowdays 64k is nothing, but at the time non volatile ram was very expensive, it was the same thing for the ps1 "card" where it stored its saves, it was a few kb also at the time.

Hello Tux! I'm sorry for having misunderstood this issue. I'm not really acquainted with all the technical knowledge of arcade games emulation. But I have never experienced the high scores loss in NeoGeo games in FBNeo. Maybe this 1kb file is really the save RAM information then? And so it will never be erased when loading other NG games...

 

9 hours ago, Tux said:

Well I never understood why the games don't save their hiscores in their memory card, would seem more reasonable to avoid any overwrite. Plus it seems it has a memory card for both modes, aes/mvs here (for samsho2pe).

Yes, it would be much wiser to use the memory card for that. But the card seems to be used only for the stage save, so you could continue your progress in the arcade or in the AES console later. I guess other systems like the Dreamcast had this feature too with the memory card, which you could take to the arcades to use in the Sega Naomi games, and vice-versa.

 

9 hours ago, Tux said:

Well I am not a super big fan of 64k files / neogeo game where only a tiny portion of the file would be used. Eventually an option by user, default being share everything.

Thanks a lot for considering this change. I hadn't thought about an option to choose between the current and a new per-game save RAM system, but that seems very interesting indeed! How would you call it? Maybe "Per-game save RAM file"? Would it go into the NG/NGCD options, I guess?

Anyway, any methods you approach for this feature would be welcome, be it a 1 or a 64kb file per game. I think an important feature of emulation is improving the limitations of the real hardware, in this case, the NeoGeo save RAM limitation, which occasionally erases old game information to save new one.

 

4 hours ago, Tux said:

I would advise a cable-less keyboard for this kind of case ! I hate this kind of keyboard for normal use, but for this use specifically it turns the keyboard into a remote control ! If you also install some dvr program which can run without any mouse, it can become quite awesome !

That's a very good suggestion! My dad has one in his setup and it works pretty well for that. These wireless keyboards are cheap nowadays (some of them, at least) and some also come with a wireless mouse, so I'll be looking for one eventually.

Thanks a lot again for your time and work. 👍

[Tux]

2 hours ago, mer-curious said:

Thanks a lot for considering this change. I hadn't thought about an option to choose between the current and a new per-game save RAM system, but that seems very interesting indeed! How would you call it? Maybe "Per-game save RAM file"? Would it go into the NG/NGCD options, I guess?

Anyway, any methods you approach for this feature would be welcome, be it a 1 or a 64kb file per game. I think an important feature of emulation is improving the limitations of the real hardware, in this case, the NeoGeo save RAM limitation, which occasionally erases old game information to save new one.

I had a quick look at what mame does, and they save this "nvram" (that's how they call the saveram) separately for each game, no option there, and since fbneo is based on mame, they do the same. Oh well, might do the same too, I'll think about it.

2 hours ago, mer-curious said:

That's a very good suggestion! My dad has one in his setup and it works pretty well for that. These wireless keyboards are cheap nowadays (some of them, at least) and some also come with a wireless mouse, so I'll be looking for one eventually.

Thanks a lot again for your time and work. 👍

Well if you can use a mouse reliably in your living room you are more lucky than me, on my side keyboard only !

[Tux]

Well it's done, you can choose to have the Neo-Geo saveram shared or per game in the neogeo options now. The default remains shared because the original hardware works like that, and I never missed any neogeo hiscore so far, but I agree it's a design mistake, these scores should go to the memory card and not to the shared ram.

Too bad we don't get our hands on the source code of one of these games, but it's probably horrible to read, they probably had crazy delays to release stuff as fast as possible, but it's too bad to have lost all that anyway.

the design mistake is probably because at the time even if the games are on some big cartridges, they didn't change that often and when the owner changed a game usually it didn't go back to the previous one, it was just to make some money with a new game. But they missed the point that the saveram should get exploitation info only (how many games for how much time), the hiscores are more player related and should go to the memory card.

Oh yeah, for the transition if the file <game name>.saveram doesn't exist yet, the saveram is read from neogeo.saveram, it's just saved in the end into <game name>.saveram. The .nv files you found are probably compatible if their size is exactly 65536 bytes.

[mer-curious]

1 hour ago, Tux said:

Well it's done, you can choose to have the Neo-Geo saveram shared or per game in the neogeo options now. The default remains shared because the original hardware works like that, and I never missed any neogeo hiscore so far, but I agree it's a design mistake, these scores should go to the memory card and not to the shared ram.

Hello Tux! I'm glad you could add this feature to Raine!

 

1 hour ago, Tux said:

Too bad we don't get our hands on the source code of one of these games, but it's probably horrible to read, they probably had crazy delays to release stuff as fast as possible, but it's too bad to have lost all that anyway.

Yes, I agree with you. Perhaps some hackers know how these games work through reverse engineering?

 

1 hour ago, Tux said:

the design mistake is probably because at the time even if the games are on some big cartridges, they didn't change that often and when the owner changed a game usually it didn't go back to the previous one, it was just to make some money with a new game. But they missed the point that the saveram should get exploitation info only (how many games for how much time), the hiscores are more player related and should go to the memory card.

Yes, this makes sense.

By the way, it's not just the high score which is saved to the internal console memory. Some late Neo-Geo titles such as KOF'98, '99 and 2000 also save other information such as the game language and the difficulty level you set in the game options. This is how I noticed my personal data was lost for these games, I went to the options and saw the settings had been reset to default, then I let the game demo run to see that all my hardly achieved scores had been gone too. 😩 Hopefully this will never happen in Raine again. 🙏

It's a pity only a few games use the console memory to save the game settings. Most of them only save the high score information, as you noticed.

2 hours ago, Tux said:

Oh yeah, for the transition if the file <game name>.saveram doesn't exist yet, the saveram is read from neogeo.saveram, it's just saved in the end into <game name>.saveram. The .nv files you found are probably compatible if their size is exactly 65536 bytes.

Ok, I'll see how this works when you release a new version.

Ah, I looked at the code and noticed you forgot to capitalize "shared" for this setting. I think this should be done to match the other naming standard used for the options in this menu.

Anyway, just a tiny detail I saw since I reviewed most of the GUI text recently.

Thank you so much again for your time and work.