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

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

Well I don't know any "Bear", it's probably the group name author of the hack, if you want to create a new company entry for Bear when you add a new one, go on. For now Hack will do...

Don't worry, that makes it interesting ! Yeah it's a comment, it's harmless, but it just shows I had a quick look at samsho5pf just before adding this clone ! I fixed it here. At least it shows you had a look at the code, good, and thanks for that ! Except that, the main part is : LOAD_SW16 is the way to load the rom, it's often the case for a 68000 code rom, the bytes are swapped compared to an intel cpu, and you have to use LOAD_SW16 instead of LOAD, it shows in the console when using the dump command, but anyway. Then CPU1, it's the 68000. The name of the rom, then its offset, apparently fbneo doesn't have any offset, which must make some romsets a little awkward to write because there are all kinds of oddities in the arcade roms and everything is not always in 1 block. That's probably the hard part for you here, you have to count manually the offset, 0 for the 1st one, then add the sizes of what has been loaded so far : 0x100000, then 0x200000. Then the size, and finally the crc. Then the CLNEI line which says it's a clone of samsho2 and gives the long name, the company (I left SNK here, but actually it's a hack, so I just replaced it with HACK instead), year and type of game. Then you need the DRV( smasho2pe ) line in drivers.h to declare the driver, and that's all, your driver can be accessed and played, assuming it doesn't do anything funny like this one which used a new rom mapping.

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

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 !

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 ! Of course 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). 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. 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.

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

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 !

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.

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.

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...

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.

Yeah but the hw of the ps1 & neocd were actually comparable, both had a cd drive, and the ps1 didn't have any real 3d hardware since it had no z-buffer, it was more of a hack than anything, 3d games on the ps1 really had to be motivated to get some good result, and also they were at the same time on the market, so like it or not, they were in competition... You liked ssrpg a lot because you are a die hard fan, but really it's too simplistic compared to what sony had to offer at the time. Good news for retroarch, I don't have any of these fancy android devices so I am not interested in this stuff on my side.

Just a notice about the talk of the other day about android : raine would work almost out of the box on the steam deck, it's an amd cpu, running linux arch, and this is what is supported here by default ! Ok, it's not like using a phone which is already useful for some other uses, but for those interested, it just works. I don't own one so I can't give some step by step instructions on how to install, but it's probably quite easy. It's probably worth mentioning this !

Yeah well the pure C version of raine would probably work on android now, but android is not exactly a standard platform, you need to use custom tools to build for it, I tried once long ago and gave up, but it was before the sdl2 version, and it should be easier with sdl2 since it supports android officially. But I'd prefer that someone who knows android building applications better than me does it, I can't say I liked very much my previous attempt... You were a really big fan on this to play it in japenese without understanding a word ! That translation had been released 10 years ago unofficially though and it made a terrible scandal which made the original author to stop his work for a while, that's why it required 10 more years to be finished. So I did it 10 years ago, but gave up before the end, it's supposed to compare to ff7 / ff8, err no unless you really love the game franchise. Glad you loved the whole thing though ! No advice for a neocd emulator sorry, I never had the need to try to play on android, even for arcade, playing by taping on screen, I can't say I love the idea...

Eh, feedback after all ! Ok well I won't discuss this, if somebody finds it useful it stays, just be careful at your settings, and if you have a doubt erase the config file to return to default settings.

Maybe you have set the option in sound options "always stop neocd music while loading" to No ? Actually I should have removed this option long ago, I added it out of curiosity to see if it could be useful sometimes, but for the original hardware it's totally impossible not to stop the music while loading because both require reading from the cd. This option is always to "yes" by default, just make sure yours is. After checking this option is from before 2009, which means before the start of the git log, I expected to get some feedback from it but since the feedback never came, I just forgot it. You are the 1st one who might have used it by mistake !

It does not happen for me neither in raine... ! For info the voice is one of the cd tracks, it stops playing when you press 1 which sends you to the game's menu. It's always been like that, no idea how you got this.

You'll notice a problem only if your soundcard doesn't use 44.1 KHz by default, if it does then there is no problem. The crash happens very fast in the intro sequence, as soon as the 1st leave appears. (errr, it's actually a petal !) Released a new binary for that, 0.96.4, just 1 line added but it fixes this crash : http://raine.1emulation.com/download/latest.html It's related to the changes done for sdl2, previously the soundcard was just opened in 44.1 KHz for neocd, no matter the configuration.

Thanks for posting, at least it proves that romhacking still accepts new entries, and this one is massive indeed. I'll take a look later, but it requires to find the same version he mentions with the given sha32, so it might take some time. Thanks for the info anyway ! Yeah found the original bin without too much trouble, some sites have the patched bin already. The xdelta patch applies without any trouble and is very fast, the surprise is that the resulting bin file is actually smaller ! But yeah it's still a 2352 bin file. I found a crash in raine if using all bin files for audio like here and the audio requires some conversion because the soundcard is configured for something like 48000 Hz, and these files are for 44100 Hz, it's a stupid bug, just 1 forgotten line, but it's still a crash, it's fixed in git, if somebody else has the problem I'll make another binary. Except that yeah, high quality patch, it took forever to make, and the guy had to be incredibly motivated to spend so much time on it, respect for the work done. Like most people I had played enough with the version released 10 years ago (already !) to understand that the game was very basic and a disappointment, which was probably the reason why there was never any official translation... But still, it's an impressive work he has done here. I remembered I needed some cheats to disable the automatic fights just not to become crazy with ultra easy repetitive fights all the time, since he changed some things for the eu/us version, you might have more chance, I didn't try that. And indeed you have some soft dipswitches now, you can access them in "neocd options", there was nothing usable there before, I doubt the choice of ps1 / saturn elements was in the original japense iso. Great work for sure !

Gunbarich is a new psikyosh game, so 32 bits only, it's a crazy breakout, but with the standard joystick as input. Except that the fixes : - fixed loading roms from internet archive when there are multiple rom names known and the 1st is not the one in internet archive, I noticed this one while doing a new raine install at a friend's... ! This bug was added in 0.96.2 because I wanted to have a visible error when the rom size wasn't found, well it wasn't found for all these games with multiple names ! - fixed a crash in the 32 bits version when trying to use any game using the 6502 cpu, there was a conflict between the 6502 and the sh2 because of an endif and a misplaced break... ! Also I started to add daraku, but this one uses a new type of layer, with line/row scroll too, so it's too much for me for now, the game is loadable, but doesn't work. http://raine.1emulation.com/download/latest.html

Yeah they were lost in the long list of little changes, the cue index was quite specific, and the version on the title bar is very minor. Long time no see, good to see you around here again !

Earlier than what I thought because of some rather big bug found, but I took the opportunity to fix a few more things : - fixed the hiscore saving for tgm2 / tgm2p (a new @delay command in the hiscore.dat for these 2) - fix a crash when starting acrobatm or any game in the nmk driver actually, and fixed an older bug which prevented these games from starting - Finally added the roms info so that the new sh2 games can be downloaded from internet archive http://raine.1emulation.com/download/latest.html

Good one, 2 bugs in 1 easy test : the crash is because of some test I did for this version which seemed harmless (0.96), it's reverted. But even after that it was impossible to start acrobatm and all the games from the nmk driver actually, it's quite an old bug which dates from between 0.92.6 and 0.93, around January 2022, when the timers became "generic", it forces to be more explicit when initializing this, and these games were forgotten. It's fixed in git, new binary tonight or tomorrow.