Tux

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 !

Yeah you could do it on git, but since you don't compile of course it wouldn't be super convenient... Ok, it reminded me that the finalburn roms are on internet archive too, so I got my update from there, crcs updated and tested, finally... !

For the kof94 hack, it's a very well done one with ips patches, so you can add it by using the ips patches... yeah I know, you need to create the .dat files not to become crazy, but they are not that hard to do, it's pretty straightforward... Now there is still a question : there are 2 directories in the ipsPatches directory : a94, and a95, and both seem to contain very similar file names, so what's the difference between them ? I guess a95 is not just more recent than a94, it would be too easy... ! Well for the a94, you can create a94.dat by copy and pasting this in the a94.dat (and put it in the ips/kof94 directory, with the contents for the a94 directory from the ipsPatch folder in their github site) : 055-c1.bin kof94_a94.055-c1.c1.ips CRC(b96ef460) 055-c2.bin kof94_a94.055-c2.c2.ips CRC(15e096a7) 055-c7.bin kof94_a94.055-c7.c7.ips CRC(62f66888) 055-c8.bin kof94_a94.055-c8.c8.ips CRC(fe0a235d) 055-p1.bin kof94_a94.055-p1.p1.ips CRC(f10a2042) 055-s1.bin kof94_a94.055-s1.s1.ips CRC(825976c1) [en_US] a94 from https://github.com/city41/kof94te I tested with this one alone and you can already make your custom team, so I really wonder what a95 is about... Someone courageous to go to their discord server to ask what it's for ?

Well I had a look at sfz3mix, a hack from Brazil ! You should try to organize a tournament there... ! Yeah I know, Brazil is very big, but you never know... ! Anyway, never seen such a cps2 game, the regions are huge, and that's the only cps2 game using some dipswitches ! So for now the support is very preliminary, the rom loads, but half of the sprites are broken, and there is no sound ! I guess I'll have to spend more time on it if I want to understand how all this works... A really crazy hack indeed, it wins the prize of the craziest hack I have seen so far for an arcade rom ! Because it took me more time than anticipated I didn't look at your kof94 hack, but it should be easier normally, at least this one should be a lot like its parent rom, which is not the case at all for sfz3mix, it's supposed to be based of the phoenix version of sfa3 (sfa3ud), but in fact everything is totally different for all the regions !

Yeah well I don't know where the 2.0 rom is, and I don't even want to look for it anyway for now, it's very late after the party here. About the author's name it would probably have been better to have strings but we have int constants here, I guess antiriad chose this to optimize space thinking that since raine started mainly as a taito emulator there wouldn't be much change in the company name... it made sense at the time, raine grew a lot since then !

Er, no sorry, this is called backporting, there is absolutely no reason for me to do that. But so far the changes have been only to try to compile with sdl 2.0.10, you can try to start over with 0.92.1 to see how it works, it should at least get rid of these sdl compilation errors, but don't come crying because of all the other bugs which are inside... ! 0.92.1 is there in git : https://github.com/zelurker/raine/releases/tag/0.92.1 The part about fixing the asm bits can probably be put to a patch which you should be able to apply to this source too, hopefully !

Well I'll make this reply the shortest : it's obviously yet another problem because of sdl 2.0.10 which is clearly outdated here. So decide where you want to go from here. By the way you can view the changes in sdl since 2.0.10 there : https://github.com/libsdl-org/SDL/releases?page=4, 2.0.10 is towards the bottom of this page 4, at the top of page 1 you have the latest release.

Well, you should think about it twice before deciding, arch is not about dev only it has a huge package repository, I publish the arch packages here too but for x86 and x86_64 only so far. Just go to https://archlinux.org/packages/ and search the package you want, I doubt you wouldn't find it. Maybe take a look first to the site about the arm version in case it hasn't got 100% of the packages from the normal arch distrib. And you should take a look at the changes in raine since 0.92.1, it's *HUGE*, there were lots of fixes for the sdl2 port too and you would loose most of them by going back to 0.92.1. For the changes to git I talked about, it's because the NO_ASM version actually still uses some inline asm code, and it shouldn't, so it would be useful to all versions to clean this up, but no I don't plan to buy a pi, at least not for now... Notice that everyone seems crazy about arm these days though, after apple, microsoft just released their surface laptop based on an arm too, so maybe I'll have some arm computer in the future but it's not planned for now... ! (but I don't plan to ever try to port raine to osx again, the way apple develops osx is crazy from my point of view, willingly making old versions incompatible to force people to update, but it's crazy for the binary package with a maintainer who doesn't want to make new versions all the time just to please apple... !).

Wow, that's a long one this time ! 1) SDL2 is backward compatible, so you won't have any problem overwriting an old version with a more recent one, assuming it's still version 2.0.x. 2) For the distribution, there are lots of distributions on the pi, see there : https://linuxconfig.org/list-of-linux-distributions-available-for-raspberry-pi Personally, I prefer arch so I would advice the very last one in the page : linux arch on arm, but if you are still a beginner with linux you might have some hard time with it, if it's like the pc version, there is no install program, you must do most of the stuff manually, which is not a bad idea because it forces you to know your system well and it's not that hard if you follow carefully their guide. The advantage is that after that you get a rolling distribution which is always updated and the updates go very very fast on arch. For info sdl2 is at version 2.30.3 currently on pc, absolutely not comparable with your outdated thing... ! 3) the main problem here : it's even harder than the previous one obviously. This controllermap.c file is taken directly from the sdl source, with some light modifications, that's what you learn if you look at the git log about this file, and it explains why it crashes so hard when you try to compile it with an sdl version older that itself. The only sane way to fix that is just to remove the ability to edit the mappings of a controller ! For that : sdl/controls.cpp: delete line 1100 and then the whole do_mapping function from line 1102 to 1191. Then finally delete the gui call to do_mapping in line 1207, you should probably do this one 1st to keep the line numbers while going up, it's this line which should be removed : { _("Controller mapping"), &do_mapping }, makefile: delete line 1263. That's the safest option here. controllermap.c is taken directly from the sdl2 source, so you might also be able to take the one there was in sdl2 2.0.10, but then you must add the modifications I added to it, even if there is not a lot of things, it's a risky operation if you are not familiar with diffs so it's really much more reasonable to remove all this. I strongly advice that you loose more time but try to install another linux distribution on your pi, it will be a lot more beneficial in the long run. Also there are tutorials for doing cross compilations from a pc running arch, and it's quite easy to do actually now, preparing your pi programs on your pc would be much faster, although if it's a pi4 it goes at a reasonable speed I heard... If you continue along this path of changing the source for sdl2-2.0.10, you still have to clean up the bits of x86 asm here and there, which would be the hardest part for me, for that I'll probably have to make some git commits, but we'll see if you eventually reach this point. For info if you want to go back to a raine which was compatible with such an old sdl2, it would be version 0.92.1, which means almost the 1st raine version using sdl2, you can still get the source from git if you are curious.