Tux

He added a page for the famous issue 12 which is italian only, and paper only, well at least you get a page now... ! Except that fixed some links mainly, a few typos, this kind of thing...

... and way too small pictures to read anything !

I guess you don't even read the story in these games now so you don't care about the translation, but except some sprites modifications there is also some translation for the story mode in the perfect edition... ! It seems to me something like a final++ version, not equivalent to the perfect one on other platforms, but still a little better than the basic final version.

Thanks for all the info, and your english is improving ! I guess if pf has some translations included it can be better than nothing then, even if it's not as good as the pc version. It also means these 2 games can probably accept most of the cheats coming from the special edition, but that's a lot of cheats to test... Maybe later...!

Oh finally for perfect the roms look mostly different so it's probably a worthy clone after all : most sprites are in common (except the 2 last roms), the sound is identical to what's used by fe (for the samples but not for the z80 code !), except that the 68k & z80 have totally different roms, plus the text layer has a different rom too. So it really doesn't look like a tiny clone, now you'll tell me if it's worth playing it ! Neogeo id : $273, not used until now, that's why it isn't recognized by unibios for the cheats. Added to git too (samsh5pf).

Well thanks for the info. I am afraid I won't be able to tell much about the interesting points of this rom, but I can at least tell after looking that for fe (final edition) it's an entirely new game, no rom is in common with any other neogeo game contrary to most clones usually. And it's not encrypted, logical if it was made by the community. For the cheats, unibios recognizes the game because it has exactly the same rom id as samsh5sp (special edition), that is $272. The ram usage might be the same, but the rom is very probably different, anyway there are probably only ram cheats in unibios because it deals with real roms most of the time so they are really read only for it. And by the way fbneo has some source on github too, and it's quite different from mame source actually, which is a surprise because originally it was made for afterburner before it was integrated to mame, and it was something like a showcase, just to demonstrate the game worked well. So I assumed it was based on mame source, I was wrong apparently ! But it's very readable, and this part is easy to understand since there is no crazy encryption like what the special edition has. It seems to be Japan only, it ignores the region. I'll check this perfect thing later, it sounds less interesting, this one seems to be just a hack on top of this final edition. But if it has no cheats in unibios it means they changed the id of the rom, so maybe there are some heavy changes there too... Anyway samsh5fe is added in git.

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 !

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

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

Ok it's fixed, ironic find, it's a specific cue file which creates the crash, and from internet archive, I hadn't even noticed they had neocd files. I won't put auto-download from there though because such a format is really a waste of space ! Anyway the indexes are taken into account that's why there was a crash here, that's indeed the index which crashed simply because it tried to seek in the file before loading it... !!! At least the fix was short. I don't plan to release a binary just now for that, this bug has been here for years ! For info to reproduce it, I had an iso + wav files dump and I hadn't even converted the wav to mp3 (lazy... !). So I just adapted my cue file to look like yours. Then I made a savegame during the demo just before the highscore screen appears. For me it crashed just after the hiscore screen. This way it was very fast to get to the crash, these neocd saves are super efficient ! And finally converting my cue file was not even necessary it would have crashed even with the one I had originally, it's just that nobody left the demo running until now, and for some reason this kind of crash doesn't seem to happen during normal play... !!! Quite crazy ! But at least it was easy to fix. It's a super old bug here again, from neoraine time, you are super efficient to find bugs currently !

Well I'll look into this eventually when the temperature will go down a little, not for now. Yes you can simplify a lot this cue file, I am not sure but I think the index lines are simply ignored for the mp3 files I'll have to double check that, and the flags lines are ignored for sure. Version is not really important in the window title, there is the nice about dialog for that with its superb color cycling despite what sdl-image did lately ! Yeah I am not sure either it's really the windows version, it's you who proposed the idea and until now I just thought it had been fixed in sdl, not even in the graphics driver. Whatever the issue, it's on your side though. You can forget it for now if you want since we can live with a white cross in windows, but it's definitely a problem on your setup.

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

Ok 0.95.5e posted, no dll inside, you'll have to download the dlls32-0.95 or dlls64-0.95 package again if you install in an empty dir, sdl2 got updated to 2.26.5. The changes are : a lot of neogeo games which had an horizontal resolution of 304 pixels are back to the normal 320 value, that's the biggest fix in this one. sfz3j which had been removed in 0.95.5d is back since sfa3 doesn't contain the text from japan ! Also removed the japan region for all the sfa3 games and clones. And re-enabled the workaround for some green colors in windows when displaying the green cross in the gui, I can't reproduce anymore this one here, mer-curious is the only one who can for now, more feedback welcome. I really hope it's the last 0.95.5 version, all this is starting to be annoying !

It's not such an old bug after verification, it was fixed on feb 2022, you can see the commit here : (I thought it was older) https://github.com/zelurker/raine/commit/e5ed04b19393f70144d9cf19f7280eb25072a9a8 Then when I noticed I couldn't reproduce it anymore on my win10 here, I assumed it had been fixed on sdl. It seems there was something else, but I can't guess what. The workaround was disabled 1 year later, in feb 2023, here : https://github.com/zelurker/raine/commit/d3ae87763 I assure you I absolutely can't reproduce this anymore at all here, the nvidia driver is 531.61 from april 13th. Well I would have liked to be able to reproduce this, I would have tried to find something better, but I can always re-enable the old workaround, you'll get white crosses instead of green ones in the gui in windows from now on... !

It's all in italian, but there are nice pictures, you can see the page of the kof98 test, which also talks about ips patches. And you can translate the text if you want, by using google lens on a cell phone for example ! Here is the link : https://zzapmagazine.blogspot.com/2023/05/zzapraine-numero-12-in-arrivo.html?m=1

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.

Not for me, I tried the same game, samsho2, I don't have any sound association for it but opened "manage associations" anyway, which was empty, absolutely no effect on the game (except of course it stops the currently playing track if there is one).

sfz3a is using english text so for this one it's sure sfa3 is totally equivalent is setting the region switch to asia. For sfz3j, it's Japanese text which is obviously not in the rom, so I'll take just this one back for now, but I'll have to check those I removed earlier... progearj seems ok when using progear with japan region at least, so it's probably something specific to sfa... ! 1944 with japan region has almost no text from japan, it even writes USA in its 1st screen but not the copyright screen. So I'll assume the only problem was with sfz3j, if anyone finds another problem, let me know !

I was mistaken, I thought there was a new decryption code finally allowing to totally decrypt the rom, but no !!! In 2023 we are still stuck with opcodes / operands, and by the way raine was already using the same algorithm as xcopy when saving a cps2 rom in debug mode, but what you get are the decrypted opcodes. Some areas of the rom are totally readable directly, like the 8 1st bytes : $ff8000 this is the initial value of the stack pointer at offset 0, but if you go only to offset $60, same file, it should be the vector for irq0, and this vector is obviously unreadable, it's $14e for sfa3/sfz3j but it must be read from the encrypted area. What this means is the roms can't be compared directly, there's still no reliable way to do this ! Ton of crap... ! When you think that the rom encryption keys were in some volatile ram using a battery and so when the battery died you got a useless machine, it would probably have been declared illegal in this time, that's obvious planned obsolescence... ! And so no surprise that you are still unable to get a fully decrypted rom from that. Well, maybe I should just take back all the removed sets, or at least sfz3j then, I'll see... !

Yeah I was surprised too ! At least it was something easy. I tried xcopy but it's no good here, I need to decrypt the whole rom, not just 1 area. In debug mode raine saves automatically the whole rom when you quit, but with cps2 it's encrypted, that's what I need decrypted. I plan to optionally load the keys and if they are available decrypt the thing and run the game decrypted, but only if the keys are available. Anyway for now the weather is quite warm, Roland Garros has started even if it should be a lot less interesting this year than previously, and so it's not an ideal time to code, but I'll try to do something soon.

Yeah I am almost sure that's the reason too, and from yesterday. But it means I need some cps2 decryption code to be able to compare the roms to see if their only difference is really this region byte, and if there is more than that then keep the region clones, it's very possible I'll be obliged to re-insert a few of them and not just one. The code in mame doesn't look too hard to port, but I have other things in my mind, so it might take a little time. Anyway good news for the 1st report : it's actually some very old bug, it dates from the time when I started to add neogeo games on top of neoraine using the code for neocd ! There is a part I totally forgot for the initialization of the game because the width of neocd/neogeo games can be either 304 or 320, until now all neogeo games had a width of 304, which is the default, and which is obviously wrong for some of them, like here for samsho2 ! It's just a stupid bug, the big surprise is that it took us so long to notice it ! Here is a screenshot with it fixed

Well for the 1st, yes it's odd but no idea for now. For the 2nd it was already in 0.95.5c, so I am not the only one who didn't notice. For now no idea neither. edit : not 100% sure but it's probably related to cps2 encryption, sorry but I don't intend to take back sfz3j without further investigation here so it will take some time. I suggest either reverting to 0.95.5c for that or use sfz3jr1 which is still here (and if you can find a difference between sfz3jr1 & sfz3j, you can post it here !). For the 1st it might be related to the crazy way mame (yeah because fbneo just uses mame code) renders the sprites. Sorry but I don't intend to ever render the sprites using the same way, too time consuming for the cpu. Here again not 100% sure, would require more investigation, but not sure I'll want to investigate this further for now.

And I just posted the binary for 0.95.5d, the very last update for this 0.95.5 version. Just what we discussed in the past week, some improvements for the ips support (mainly load_continue support, but also the way the .dat files text is displayed), and the option to mute the sfa3 announcer in sound options.

And you can find the .dat files I built for the ips patches from romhacking there : http://raine.1emulation.com/download/extras.html Notice that the long text of some of the dat files (especially strider) will be displayed correctly only for versions more recent than 0.95.5c !

Yeah ok, I'll try to post that there soon, or in the extras section of the download page. For qsound sorry, that's the only area where we share a lot of code with mame. A long time ago the sound drivers were developed in common for mame and raine, now I just kept a thin compatibility layer to be able to use their code with as few changes as possible (but since they keep on changing their interface all the time we have an old version of their sound drivers now, but they are good enough for me for now). So the gurus who decide how to make a sound chip to sound are not here, even in the mame source there is no email, just a name, and the maintainers changed over the years. But no mention of any low pass filter here. So you can forget about this low pass filter for now.