I suspect you're not being very efficient compared to 'real' games. I'd love to be proven wrong, but I seriously doubt you're even close to rivaling the variety of sprites and background art found in any existing 8mb huey, let alone the 84mb (or whatever it was) limit of SF2's mapper.
Yeah, we're not at all nearly efficient compared to 'real' games, certainly not the later games. One browse through the various HUC threads here show that the code alone is incredibly bloated due to the result of the compiled code from huc to asm (please correct me if I am wrong!)
Also, I thought our ROM limit was less than 3mb, not 8mb?
Gredler -- something has to be unnecessarily bloated. Is the art the main culprit? You two should consider a compression scheme -- even simple RLE gives decent results. I'm dicking around the NES again and nametable (aka tilemap) data gets compressed by 65% minimum (of course this depends on how you are building your backgrounds), from 960 bytes to something like 250 bytes. If there's some linear repetition on the background it might be worth to look into it.
RAW art data in the ROM takes too much room, imo.
I'd like DK to chime in, but I am fairly certain we are not compressing any of the art. We are using tilemaps for all the "backgrounds".
The first background was a single screen, so I was fairly liberal with the construction and number of tiles, but it is still less than a single 256x128 image for all of the tiles.
We are fairly early still, obviously, so these are estimates. The one level we have nearing 90% done, the shower level everyone's seen, as a measuring stick against what we want to do makes us need to plan something to reduce the side of the ROM and be careful.
I only mention it as size of ROM is not really a consideration in the CD development within reason, where as on a hucard you have to plan and be much more careful than with CD.
Topic: Revival Chase - HuCard conversion? (Read 636 times)
