Tux

I am not going to complain at least you are using git, which is very rare around here ! Thanks for finding it too, but it was fixed in the long process sorting all these type2 games yesterday... !

And I can confirm it's already fixed in git, just update your git. The sequence is here : cmd 14 mode 0 cmd 5e mode 2 cmd 1c mode 0 cmd 25 mode 2 Before command 14h was taking 2 bytes as argument, so they were 5eh and 1ch here, leaving 25h alone, so it was taken as a song number. Except now 14h takes only 1 byte in the last version.

Well it's done on an old git, do a git pull to update your git and restart. Your version has a kof94 which takes 2 bytes as argument of the 14h command, it's 1 now. Since your 25h is just after that, it's probably the source of your bug, so you can assume it's already fixed.

It's called "random seed", the random numbers depend on an initial seed, if you restore this seed you have the same sequence of events, here it was missed. You can either try the debug build, or try a demo in 32 bits (I am not 100% sure the 32 bits version would work, but it's more likely than here). And it's hard to tell what was not saved here as the random seed... !!! I have no idea what this code uses as a random seed, but it's very strange that it's not saved... For now, absolutely no idea, it's probably safer to use the debug build in this case, it's likely the same behavior will also be in the 32 bits version, it looks like some external source of data which is not saved, although I have absolutely no idea what it is.

Like a savegame, except you use shift + f4 instead of f4. Thanks, I'll take a look... edit : well sorry but same thing as mer-curious. I switched to the japan aes bios since it seems to be the only way not to get this corrupted graphics, then I associated a song with 2bh which seems to be the background song during what you recorded, and then everything plays normally until the demo ends in pause mode, the song was never interrupted or changed. .. It's with current git version 64 bits, since this demo is for 64 bits, but it probably works the same with latest 0.94.4. So I don't know what you did to have a problem here... ! (and these demos are very convenient in this kind of case I should think about them more often !) The behavior seems to be strangely different with your custom rom, but it still doesn't change anything to the music. And if you want to reload the demo when it goes to pause, release the pause first, there is a nasty bug here if already playing a song. And I never see any 24h command on my side, so there is no switch to this song, something is wrong somewhere... ! I wonder if the 64 bits demos play correctly then, 1st time I see one actually, usually I use this in 32 bits (32 bits is way more convenient for debuging usually because you can compile without optimization but still have the speed of assembler). Assuming the demo has a problem since you can compile your own version we can try the other way around then : start by building a debug build (uncomment the line RAINE_DEBUG = 1 in the makefile), then uncomment the line 408 in source/sound/assoc.c which reads : printf("cmd %x mode %d\n",cmd,mode); to see the sound commands passing. Then run your debug build from a terminal (the mingw32 terminal in windows is ok) and do your testing. When the song changes call the gui to stop the game, you should see something about song in the output of the terminal, send the last screen of what was printed and it should be ok. Good luck, but I can't think of anything easier to reproduce this in these conditions. It might be a good idea to fix the demo anyway but we might loose too much time on it for now.

On 2nd thought, since it's very rare why don't you try to resurrect the demos ? Load your savegame, get ready to reproduce your problem when you are ready to do it, press shift F2 to start to record a demo, it will ask for a name, and place it by default in subdirectory named from the current game name, here it will be savegame/kof94. Choose a name, type return, now it will record in real time all your inputs. When you want to finish, just press esc to call the gui and quit (I think it's enough to just call the gui, but I am not sure, if you quit you are sure the recording is really stopped for good). If everything goes well I'll be able to replay your demo to see your impressive moves and the association problem in the end ! I just tested on bublbobl, and except yet another bug linked to the intro behind the menu and the multi z80 configuration of this game, it worked well. I'll push a fix for this now, but it's specific to games with multiple z80 only, so it's not relevant for you here.

Yeah yeah yeah goes too fast for me. I found pulstar is a type 2 like no other, the only one where in its arrays type 2 are not songs, it's type 4 for this game, and it's the only 1 I have seen so far behaving like this. Except that it accepts all the usual commands like a normal type 2, the difference is just how it classifies its songs, and they start at 80h instead of 20h. It won't be committed for now because I'll test the whole list finally. Ok, committed, a new variant variable to identify these special "type 2", the list of neogeo games which are type2 as comments, a fix for pulstar and ssideki, and I think that's all. (plus of course now the games having 2 bytes for command 14h and those having only 1 byte are clearly identified and separated !). I'll try to see your kof94 thing tomorrow or maybe later, but it seems tricky !

kof95 doesn't seem to have the same 14h command, the signature on which I identify the roms is not always respected, sometimes they made changes and didn't change this signature, it didn't happen a lot though, but this time here it does. AFAIK the other type 2 games take an argument on 2 bytes, kof95 takes only 1 byte here. It's fixed in git, I leave you testing that... Sadly I don't have a precise list of which neogeo games are type 2, to check if some other take this argument on only 1 byte... ! More than 100 games to test, some volunteers ? (plus it requires a debug build to find out which type of association it is...). edit : took the time to test quite a lot of them, in fact the vast majority of type 2 take this argument on 1 byte ! I stopped at pulstar for now because it's detected as a type 2 although its songs can't be tested in the gui for some reason ! I'll continue later. So far the roms which take this argument on 3 bytes are at least : aof3, magdrop3, neocup98, nitd, preisle2, wakuwaku7 what a mess... !

Already told you : if you pass a zip on the command line, it assumes it contains the files extracted from an iso for a neocd game (and so if it doesn't find an ipl.txt in the zip it will output an error). If you want to run an arcade game and not a neocd game, you must pass a name instead, not the zip file, but if you do that on the command line avoid -nogui for now (the fix is committed to git).

Anyway just tested in windows 10 to be sure it works, it does, here is a screenshot to prove it : (tested also with the iso contents extracted to a zip without a cue file).

exact command line ?

well it works for neocd games ! It's not windows specific this time. And it works if you don't put the -nogui. For now, just don't put the -nogui thing, I'll fix it later... !

- An amazing bug was fixed which made it impossible to run a game from the command line in windows... and it's been here for very long. Does it mean that nobody use frontends with raine anymore in windows ? - Big acceleration in the console for mouse tracking (which displays some underlying text in reverse video), and scrolling speed once the window has reached its maximum size (actually you don't even see it scrolling anymore, but the result seems good). Also added some colors and sorted the commands for the help command. - Improvements for the sound associations for real bout fatal fury and samurai shodown, hoping it didn't break any other game... !!! Get it from there : http://raine.1emulation.com/download/latest.html edit : I forgot to commit the sound association fixes to git, so they were not included in the linux binaries. I just rebuilt them because of that, 0.94.4a, linux only, windows had them.

Ok it becomes problematic, rbff1 seems to be a "type 2 extended", it recognizes more sounds and so they added a new prefix for it, 1d, which is not recognized by the others. Well lately I added 1c, which is not recognized by at least 3countb, so I hope it won't break anything, it shouldn't normally. For samsho, it's a weirdness on which values the sound prefix commands can take, there was a comment to say only commands >= 0x20 can be taken here, well clearly here its >= 0x11. So well I put >= 0x11 for all the type 2, and hope for the best... !!! Too bad the comment didn't say for which games I observed >= 0x20... ! I'll make a new version for at least the bug of yesterday related to the command line in windows...

Yeah I guessed it was older than that after posting, it would be here since opengl became the default display method then, which would make it a very, very old bug ! Well since most people in windows probably don't even know there is a command line, the only ones who could use that would be the ones using frontends to run raine. It's quite surprising none tried and failed to use one then... !