Tux

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.

Ok, finally fixed almost all of sfz3mix : - the aspect ratio dipswitch is a fake one. In Raine it's useless since the setting is already in video options. Ok in raine it's just about trying to keep the 4:3 aspect ratio or not, I could instead force to 4:3 or 16:9 like here (there is even an option for these ultra wide screens, I didn't know these could be useful for gaming !). Spent quite some time searching how it was read, didn't find anything... ! - there are quite some hacks for the sprites drawing explaining my bad sprites. It's a huge sprites bank, $4000000 bytes, never seen that in a cps2 game so far. Luckily there was also a modified mame source where it's easier to track the modifications and find everything needed. There was also a change in the output handling which helps a lot to center the screen ! - for the sound it was a blank area in the middle of the rom. At least the intro sound of the game seems broken which is strange since it's the only broken sound apparently. It's among the new sounds added to this... I checked their custom samples, they are about music only, so it's not the cause, so for now I don't know why it's not playing correctly... It's possible the driver uses some fancy recent feature of the qsound driver, the one in raine is actually very old now. The amazing thing about qsound is that their samples are 8 bits and they sound like 16 bits samples... ! - The inputs seem ok, tested only in service mode, can't be sure about the game, I am not an expert in this game but it should work normally. It's in git for now. ffman1985 has been adding quite a few of his hacks/cheats lately too to git...

And ffman1985 understood these folders : That is the portrait in the character screen. https://github.com/city41/kof94te/blob/main/resources/avatars_a94_256.png https://github.com/city41/kof94te/blob/main/resources/avatars_a95.png So, the a94 is the one nearer to the original. So you must either apply a94, or a95, not both. Here is then the a95.dat file, on the same model, it's just a copy and paste of a94.dat with a94 replaced by a95 : 055-c1.bin kof94_a95.055-c1.c1.ips CRC(b96ef460) 055-c2.bin kof94_a95.055-c2.c2.ips CRC(15e096a7) 055-c7.bin kof94_a95.055-c7.c7.ips CRC(62f66888) 055-c8.bin kof94_a95.055-c8.c8.ips CRC(fe0a235d) 055-p1.bin kof94_a95.055-p1.p1.ips CRC(f10a2042) 055-s1.bin kof94_a95.055-s1.s1.ips CRC(825976c1) [en_US] a95 from https://github.com/city41/kof94te Notice that this method has only advantages, you can choose which version of the patch you use : at the top of their git tree is the 1.30 beta, but you can revert to any version to get the one you want, the .dat files will remain the same since the crcs are the crcs of the rom files, not the patches. In linux you can use symlinks for the a94 and a95 files to make them to point to their git directory, and then choose the version you want in this directory... !

I have most of the sounds, it was because this romset was made for mame compatibility and so it includes the gap that mame has for its z80 memory map in the middle of the rom ! 0x8000 bytes wasted, and so I needed to make a memmove to compensate for this... Still a few sounds seem strange, I'll have to make more tests on that, and anyway for now no idea for the broken sprites and there are quite a few !