Yeah, but you don't have worry how efficiently you split and load it with CD. You can duplicate things if it's going to make it easier to load in to 2meg chunks later. You only have to worry about the single biggest point where you need the most data at once to have a complete level.
Correct. You don't have to worry about global efficiency side like you do on a cart rom project. But I think that's obvious. What's not so obvious, is just is how limiting 2megabits of ram can be, compared to a rom project. Sure, ADPCM can save space that you would normally store for samples (assuming your game/etc is using SFX samples), or as slow ram (cause it's much slower to access) giving you a total of 2.5megabits is no samples used. It's been a while, but I'm pretty sure you can't read ADPCM while it's playing. You can only write to it while it's playing (huvideo does this to stream ADPCM from main memory to ADPCM memory). IIRC, it's because the play pointer register and the read pointer register are shared, but the write pointer register (that forms the address) isn't. I.e. you can't do 2.25megabit normal (2megabite fast, 0.25 slow) and 0.25megabit for sample playback via ADPCM controller combination at the same time. But I could be wrong, I'd have to look into it. ADPCM 8khz takes up less space than 7khz 5bit pcm, so it's an advantage to use ADPCM to store and play samples over normal interrupt+DDA method of the cpu. And ADPCM play takes almost no cpu resource too in comparison, which means no complex dual interrupt system (VDC and TIMER, both out of sync/phase) ).
Many CD titles are self contained areas/levels with redundant data. So it's faster to load a level/area/whatever, instead of seeking all over the place for different packets/chunks of data (funny, Rondo does exactly this though, making the loading longer than it should be). And lazily, they simple recopy/paste enemies from other levels of the game into these sections, when they could have added something unique to each level sprite or tileset, etc. A strength of the CD format severally missed out on, on most titles IMO.
So with the idea of NEC creating a Demo HuCard of SFII it's really as simple as saying it's would be a limit of fitting 1 Level and just 2 characters into >2meg HuCard as well then? 1 level and 2 characters being the time I can think of there being the single point that most memory would be used/needed in SFII.
Correct. Though, you could make it even more painful but save some memory if you have the winning poses/etc part of the match as a 'load' section as well, but that would mean next rounds would have loads too (where as additional rounds of the same characters and same level would need no reloading if no character loose screens appeared,etc). If NEC upgraded the SCD 3.0 memory to logical additional 256k via cart instead of a funky number like 192k (which means multiple chips), then it's pretty likely that you would have seen a version SF2 on Super CD. And maybe only SCD. Dunno. There's no denying that SF2 port to SuperCD would have suffered some cuts in character frames of animation as it is now, but that it's only speculation as to if that's the
main reason why they didn't do Super CD version. Maybe there were other influencing factors, like making an impressive hucard, making it available to
all PCE systems CD or not, including portables, etc. But one would think, that if the the 2megabit CDRAM limit *wasn't* a huge factor as I and others are pointing out, then why
wasn't there a slightly crippled SCD release of it at the same time or relatively close? But then again, why didn't we see any additional SF2 games for the ACD that had none of either projects limitations - yet saw impressive ports of Neo Geo games?
Also, Bonk 3 SCD game has missing frames of animation for giant bonk that couldn't fit into memory (or specific level design requirements, maybe most levels but not all). Yet the hucard version has the additional frames.