Tux

No didn't know it. It looks less innovative than sfz3mix though, a lot like the zillions of clones of sf2... but yeah maybe it could be an idea to try to add it... Ok, added out of curiosity, much easier to add than sfz3mix ! Added the custom dsw as indicated on the web site...

And from Luca (Zzap!raine editor for now) : sfz3mix ceases to be a clone since it completely replaces all the roms, it's an independent rom now. And from some other user on github : the sound driver saved in the config file never appears in the sound dialog when you launch raine, except if it's the 1st sound driver. It's a bug, the dialog is not properly initialized. I also added an error message when you change the driver in the gui, the change doesn't return an error, but the driver remains the same anyway, in this case you must do the change before starting any game.

For the green ball : I checked your save, yous see this ball only in the 1 few frames during the stage introduction, if you want to spend hours debugging a video bug for something which happens only during a few seconds, be my guest ! 1) focus lost : nice finding, it was during the transition to sdl2, many things to fix at the same time, I started this one but never finished it ! Luckily finishing it was very easy, it's fixed. It's still surprising this was never reported earlier, this change is from November 2021, so this must be used by nobody... ! 2) it's the default in the sdl test programs which use the joystick/controller, I copied without trying to understand. Cases where you use 2 programs at the same time which use the same controller are rather rare normally. But so it's not a problem, I just changed the setting from 1 to 0, 1 line change. 3) after a break and some testing in windows : actually the maximized status of the window was not tracked at all, I didn't even think about it, because you see normal people use fullscreen for what you did, not a window with decorations, but yeah I know, you are different ! (yeah I am sure it's because you love to switch from one emulator to another even on a tv !). Ok, so I added the tracking of maximized/restore status which obliges to change quite a few things, and while I was at it the position of the window is now tracked in real time, previously it was just asked when the program exited. I removed a hack about window position for linux in the process, normally it shouldn't be necessary anymore... let's hope for the best ! A particularity : it tries to save the status of the window before it was maximized, which means that if you maximize your window, quit to save the configuration, then run the program on another screen, you should be able to leave maximized state and find your previous saved position ! 4) Ah, I didn't notice that either, it's a function which is almost never used, and probably not used at all by most users. Actually even if it looks like a separate program, it's just another window, you can open multiple windows with an sdl2 program, but this particular one didn't allow the window to close, yeah. I don't know why they did that in the 1st place, but anyway ok I added the ability to close to exit earlier ! And I don't plan a release before this week-end !

I don't really see what these 2 things have in common ! Plus here this was a bug from the patch author, not the rom authors, so it would be highly unlikely to be found elsewhere ! I didn't remember the bug but I remembered the video and remembered my reply at the time, it didn't change !

kof94te is at version 1.3.0, out of beta, including the patch for this problem. By the way he could confirm the problem happens only on raine, not on the original hardware, so maybe 1 day I'll have to change the way sprites are drawn. But for now it allows me to do things faster for sure, so everything is good. I can keep the patch in the source since it checks the contents of the rom before patching it, so it doesn't try to patch 1.3.0, just tested with the a95 patch. This is the end of this problem then !

congratulations for the time you spent doing all these screenshots and saves, you should really learn to compile so that you could try these alignment issues yourself, because you never see the end of it ! Clearly all this comes from the resolution change in this game. Now the screens to be able to check relative alignment of layers are very rare, even more so when you talk about vertical alignment ! Yeah I missed scroll1, maybe I didn't want to see it at the time, the text layer for the 1st screens, the horizontal alignment is easy, but there might be some vertical alignment too about this and in this case it might affect other layers too... The sodom stage is the worst, this stage is done by pieces of layers stuck together everywhere ! Anyway not sure at all we'll see the end of it before long... You fix 1 screen and then you notice that it breaks another one ! Too bad there's no screen to check these alignment in the test mode, there is one but it's done only to align the crt monitor screen image, I guess it didn't make much sense to align layers on the original hardware back then... !

And I got my testing from ffman1985 here, so this function is actually called to display the player name on the player selection screen, so if you disable it this way, you don't see the player name. So the correct fix becomes : - dpoke $2be018 $303c for patch a4 - dpoke $2be018-$20 $303c for patch a5 At least I was right not to hurry this fix yesterday, it really needed more time ! And the guy from the kof94te project just replied to say he is out of town for now but will merge the fix as soon as possible, cool so maybe the fix won't even be necessary here for the next version then!

Actually if you want to test that on 0.96.9, it's easy to do and it would be useful : after loading kof94 with one of the ips patches loaded open the console and type : - for a94 : dpoke $2bd8ea $4e75 - for a95 : dpoke $2bd8ca $4e75 I know it fixes this bug but I can't be sure it doesn't affect anything else... Yeah you can't copy and paste to the console yet, you'll need to copy this manually. edit : fixed the offsets in the console, it's $2xxxxx and not $1xxxxx... !

For info the crazy idea of ffman1985 worked, so I made a patch for the ips patch. The problem started to appear in their 1.1.9 version actually so it's not exactly recent. It looks like a bug and not something wanted, it's a function which is supposed to erase some characters and actually enables a column of sprites which should stay disabled. The patch is committed to git, it's actually very short, it works with the latest 1.3.0b0 version.

Mainly because I broke the top of the main menu in the previous version ! 1 line fix, but an important one... !!! Anyway except this one I manage to fix some alignment issues in sfz3mix (16 pixels on the right for scrll2, scroll3 and the sprites, I can't say I had a lot of time to test it, but it looks better). And a fix for a mer-curious crash, see his thread for the details, it was probably specific to ssrpg, but it obliged to change the way samples were handled ! I hope there won't be another critical bug in this one because I plan to cool down for a few days after this ! http://raine.1emulation.com/download/latest.html

And it was again a bug which looked like nothing and was after all critical, this time a race condition on the sdl_sound sample when using this game this way. For some reason it didn't happen with the bin files, maybe because operations on these files are quicker. Anyway I had to move all the operations on this sample outside the callback, which is the opposite of what we did with sdl1... ! Normally it's safer this way, and your crash is finally gone. I started by updating sdl_sound, but it was not the cause, I'll keep the sdl_sound update anyway (for flac, ogg and mp3). Hoping that it didn't break anything else, I tested an sound association in kof97 and everything seems fine (uses the same method, an sdl_sound sample).

Well you found again something very very specific here ! I can't explain this quickly but I'll try to be clear : mame and raine code to draw sprites are very different, because here I based the source on another emu, not mame. In the end we use some very different method, mame updates the screen for every scanline, and depending if the scanline is odd or even it accesses 2 lists of sprites then it checks if they are on the scanline it tries to update and draws them in this case. On the other hand in raine I try to update the screen in 1 go, exception when there are raster interrupts, some games having 1 for each scanline, in this case I am obliged too to update for every scanline, but since most of the time it's everything in 1 go, I don't care at all about these 2 lists, and so far everything worked fine, I just browse the main list of sprites without even looking at these. But apparently this hack is the 1st thing I see using these 2 lists to blacklist some sprites from what is to be drawn on screen, never seen that happening anywhere else ! If you load your state without applying the ips hack, you'll see that actually the affected screen doesn't exist in the original rom, it's skipped completely ! So... it would mean changing the whole way sprites are drawn with the potential to affect all neocd and neogeo games just for something which lasts a few seconds only, because after that we are back to the screen which is in the original rom and the problem is gone. So for now I would say that I prefer to ignore the problem. ffman1985 says we could maybe find where the hack modifies the list of sprites to update it so that the whole list is cleared in this new screen. Well I might wait a bit to see if we can come to something using this method, but otherwise I'll just ignore that for now.

ok apparently scroll2, scroll3 and the sprites should all move 16 pixels to the right, it happens in all the screens. Scroll1 seems unaffected but it's an 8x8 layer so this might be why, all the others are at least 16x16, scroll3 32x32.

2) really maximum annoy system here, it's indeed because of the move of the ips function, I had thought I had taken care of this part but I have been too fast, it's a tricky part where you must be super careful or you do this kind of mistake. Super annoying, really ! It's a 1 line fix, but without this one you loose "play game" and "game options" in most games, I guess I'll have to release a quick fix binary because of this stupid line. 3) still can't do, I even tested with the win version. I don't know which version I have, it's the original untouched with the bin files for audio tracks, I guess I decided to keep it this way because it's a rare format. Anyway : loading your state from the main menu of the game, pressing turbo until reaching the continue menu, pressing quit to title, pressing 1 so fast that you don't even see the white title appearing (tried also after the title has appeared), reaching the main menu, everything is normal and sound is working. 4) very unlikely, it's related to the timers usually and when it happens it's baked into the save, I guess this save was done at a bad moment, but I can't guess which one. Raine has gone a long way to improve this kind of reliability when restoring sound, but there are obviously still cases where it's broken. I have taken the time to check the restoration of timers here, everything seems fine, so no idea what's going on. From the sound of it it sounds like something bad is looping, maybe a bad bank ? But the banks are supposed to be saved and restored here, so no idea. Anyway you seem to think it's an easy problem, it's not, it's a very complex one.

The quote system of the forum is broken again, no way to insert a reply properly here ! so I move the reply to your 1 here. Anyway, it's been done because as it was the "apply ips to rom code" there was in the main menu appeared as the main way to use ips files when it was actually the 1st one and is now almost completely useless except in some very rare and specific cases. Even ffman1985 did the mistake when looking for a way to apply the patches for kof94lt, the recent clone. So the old apply ips to rom code is disabled for now, and this one becomes the main option and comes to the main menu to be more noticeable. Yeah well I thought I had fixed all the alignment issues but I still missed a few apparently, for the portrait on the left I was not sure it was one, there is probably a fixed offset to apply to the layer here, it looks like everything is moved slightly too much to the left, annoying. I'll try to find how to reach this rolente stage to see this black area then !

Ok, zero800 just released the new binary with the sfz3mix support. You can try the sound associations for yourself with this version, I have verified that it's working with sfz3mix. It's in Sound options / sound associations. Mer-curious is the local expert at creating playlists to go with the kof games, he is from Brazil too, there must be something about kof games in Brazil !

Yeah well I finally was convinced to release an update to have sfz3mix, and it was quite a lot of work for what was supposed to be just a hack... ! It's actually the biggest cps2 game so far, using a resolution higher than the original hardware and with such huge rom regions that it had to use quite a few modifications in the emulation to work. You have the links in the forum to the site's project, thanks to zero800 for that. It also obliged me to fix some bugs in the cps2 emulation, so there should be some improvement especially related to line scroll in the background layer which sfz3mix uses a lot. Except that ffman1985 did it again, he added a lot of console scripts, as a reminder the neogeo ones are for aes only, non arcade mode. His new scripts are for at least fatal fury special, fatal fury 2, kof94, kof95, and samsho3. And then quite a lot of small fixes, most of them coming from the gcc sanitizer, really efficient at his work, a lot of minor stuff and some buffer overflow in the line scroll in cps1 and zoom code in the psikyosh driver (sh2). The translations were updated too, mostly the brazilian one. Thanks to mer-curious for the bug reports and the help for the translation. http://raine.1emulation.com/download/latest.html

Yeah well I don't feel like investigating this for now sorry, I'll release what I have so far and we'll see later...

Finally I took a little time to look into these : 1) that's where you see that neocd games which actually pause the cd instead of really stopping it are very rare, in fact I know only this one, and that's why it was unnoticed for so long ! Anyway, there should be a fix in place for all the cases now... 2) ncd_ prefix ok. 3) Can't reproduce, if you mean you can't select the entries in the main menu after dying if you go there before the cd track of the intro has time to play, it seems to work fine for me. Notice that I still have the old translation when it was in beta and the new one, and they are incompatible if you use save states ! I didn't think there were such severe modifications between them... ! And your save state was useful because all my save states were from 2015 or before and so were using only the asm core, but with current debug build you get a lot of early exits from the sanitizer because it doesn't recognize the stack structure because of all this asm in neocd. Only way around it is to use the C core instead of the asm core, but it requires a new save. 4) don't know, probably not worth investigating. I guess you should try to avoid save states if you want to play the way the game was designed, their save system is not that bad (if you forget the **** random events !).

Ok, then I'll wait for your version then ! Yes you can tell a track is looping but from memory it's the whole track in this case, so you should make sure start and end are ok for that.

Ok, finally found the cause of the bad sound, as I suspected, it's because of the unusual size of the pcm rom. The default driver initializes the bank by taking a byte & 0x7f and << 16. Well you just need the whole high byte with sfz3mix, that is & 0xff instead of & 0x7f. The & is still required because it's a 16 bit value and we want only the lowest byte. Well that's the end, I think the support is complete, just have to wait for a few details about these custom samples, and ffman1985 seems very busy with some new scripts now... Also fixed last night some long lasting bugs about alignment of the background layer when it uses some line scroll, I had to fix it here because this game uses that all the time, even in the 1st attract mode screen ! So this probably fixes quite a few other things related to cps2 at the same time...

If you are still around, I had a look at the custom samples, and they seem to be 8 bit wav files... Well qsound is also 8 bits so that doesn't make a big difference, but the songs seem different though, so what are they ? I can recreate some ogg files from these using audacity, but it's the 1st time I use some 8 bit samples to create some mp3 or equivalent...

Well the most impressive rom hack I have seen so fa anyway ! I took a quick look at the qsound rom (sz3mx.11m) and indeed it looks like there are 2 $800000 bytes regions inside, but I have no way with the current qsound driver to declare 2 regions for a single chip. The problem is the qsound driver is a quite outdated, but mame now emulates the dsp from the original qsound hardware which seems quite overkill for me, so I'd love to find a workaround for this problem, but it doesn't look easy.

Cool, thanks ! Well the increase of resolution was the easiest part, the sprites the hardest so far. I'll try to see about this 2nd bank for the qsound, thanks for that. And I have some other bugs to keep me busy, not directly related to sfz3mix... ! Yeah the work on this hack is impressive, biggest cps2 rom ever this info alone is impressive ! For the samples, usually we do that with "sound associations" in raine, cps2 is already supported, it allows to replace a chosen song by an mp3/ogg/flac, etc, so it's probably the easiest way to do that here, except usually it's configured by the user, here it would be by the driver, I'll see that later.