SpritesMind.Net

Bool doesn't exist in older C standards, and in newer it's just an alias for u8 usually.

I see the images fine.

That is not code, it's data. You can't change it to code.

Consider Krikzz Flashkits if you don't need SRAM. They use modern flash and have good availability, and no soldering.

Db-electronics considers them bad since they use resistors though.

If you're going as far as hacked emulators to use a resolution it wasn't designed for, is that really worth playing vs just running the PC version?

Genesis demo available:
https://megacatstudios.com/collections/ ... nesis-demo

Little Medusa, Mega Cat's puzzle game originally released for NES earlier this year, is now available for Genesis and SNES. https://www.youtube.com/watch?v=O4l5W8yCrMw https://megacatstudios.com/collections/free-demo-downloads/products/little-medusa-snes-demo https://megacatstudios.com/collections/s...

Yes, the SSF2 mapper lets you go over the 4mb limit, and you could design a custom mapper too. Everdrives and emulators support SSF2, so you can test your game easily.

If you have a PNG, you can try my tools as well:
github.com/clbr/tileoptflip
github.com/clbr/nes (tools/tilecoords outputs a map based on an optimized and a normal image)

Coffee Crisis and my Bottled demo.

NTSC stands for "never the same color". TVs vary enough that it doesn't matter, use whatever is convenient.

DDA rendering is faster than fixed point. The details to one can be found in the Game Developer Magazine archives, starting from 1995 AprMay - all available online for free.

Data from some other spritesheets. Worst of these was 91% and average 79%. Packed with IDX, original size = 40512 compressed to 35904 (88.6256 %) Packed with IDX, original size = 56608 compressed to 48912 (86.4047 %) Packed with IDX, original size = 57728 compressed to 43492 (75.3395 %) Packed with ...

Yeah, the sprites are big and have a lot of frames, but still it was surprising how well they packed with this. One sheet got to 58% (includes both the index and the stream), while zlib got it to 30% and lz4w 51% (numbers from memory).

For an upcoming game, I tried some different compression approaches for sprite tiles, since lz4w was too slow. The amount of data being great enough that even plain memcpy is close to limits, I wondered what approaches would then be fast, even if not as good in compression. About 160 tiles per frame...