finalburnneo / FBNeo

FinalBurn Neo - We are Team FBNeo.
http://neo-source.com
Other
920 stars 362 forks source link

kof95 and kof95h won't load #914

Closed crtJoe closed 2 years ago

crtJoe commented 2 years ago

When loading the game in Retroarch with the latest FBNeo core (1.0.0.03 c90420a), nothing happens and Retroarch closes itself. Mame 0.239 loads the game fine. The earlier core 1.0.0.03 326cd92 loads the game fine. FBNeo didn't complained about missing or incorrect rom files, but I was wondering if the rom has been updated very recently. If that's the case please just ignore the issue. Thanks!

barbudreadmon commented 2 years ago

Are you maybe using the autoload/autosave savestates feature in retroarch ? i recently learnt retroarch won't launch games if the savestate can't be autoloaded. FBNeo will tell you if your romset is wrong, if you get no error message then you can be sure the issue is about retroarch.

crtJoe commented 2 years ago

No, I just checked again to make sure that I didn't turn on those features by accident. The earlier core and the standalone Mame 0.239 (still the latest official release I suppose?) both load the game properly though.

mobasuite commented 2 years ago

Yeah having the same problem with kof95 on retroarch.

barbudreadmon commented 2 years ago

They are loading fine here, but one of them has gfx glitches (kof95), i believe it might be related to https://github.com/finalburnneo/FBNeo/commit/a6143aab959b1f234d76d3536216d3a1e96df6bb I'll investigate

mobasuite commented 2 years ago

The JAN 8 build is working properly, something got messed up down the line.

barbudreadmon commented 2 years ago

@dinkc64 ok, i've a general understanding of what's going on here https://github.com/finalburnneo/FBNeo/blob/26833859d9529f71ee8a0f10698f944284ecc242/src/burn/drv/neogeo/neogeo.cpp#L358-L371

is loading the 3 sound roms at 0x000000, 0x400000 and 0x800000, with the 3rd rom having a size of 0x100000 so we need at least a size of 0x900000 to store everything without overflowing, but the new code set the size to 0x700000 by adding 0x400000+0x200000+0x100000, so we are overflowing.

To avoid overflow, size must be at least (<size of 1st rom> * (<number of roms> - 1)) + <size of last rom>, something like this :

            // Add up the ADPCM-A & ADPCM-B roms
            for (INT32 i = 0; i < pInfo->nADPCMANum; i++) {
                BurnDrvGetRomInfo(&ri, pInfo->nADPCMOffset + i);
                if (i == 0) nYM2610ADPCMASize[nNeoActiveSlot] += ri.nLen * (pInfo->nADPCMANum - 1);
                if (i == (pInfo->nADPCMANum - 1)) nYM2610ADPCMASize[nNeoActiveSlot] += ri.nLen;
            }

note : nYM2610ADPCMBSize doesn't have that problem, roms are always equally sized.

dinkc64 commented 2 years ago

thanks for the bug report, problem should be solved :)

mobasuite commented 2 years ago

working, close issue ?

barbudreadmon commented 2 years ago

i just synced the libretro port, should be available shortly from their buildbot

mobasuite commented 2 years ago

again, thank you.

crtJoe commented 2 years ago

I confirm that the issue has been fixed. Thanks!