- darkstalkers felisha.png (3.06 KiB) Viewed 5104 times
- darkstalkers VRAM.png (4.12 KiB) Viewed 5092 times
Moderator: Moderators
I got it to 1674 bytes, but that includes a 42 byte header (2 bytes give the tile size (8x8 in this case), and then there are two and a half bytes for each of 16 colours, giving the information about the five most common adjacent colours (storing additional adjacency data is worthless due to the Huffman tree used)). My calculation of storing uncompressed is 3040 bytes (1 byte for 2 pixels). These are the results with PNG format to compare:psycopathicteen wrote:How many bytes is that? The sprite would take up 3kB VRAM.
Code: Select all
$ pngff < felisha.png | ff-strip 8 8 1 | ff-uniq 8 | ff-strip 8 8 19 | ffpng w32768 n258 | pnglist
IHDR 13
PLTE 48
IDAT 1701
IEND 0
Because big ROMs are serial, and serial ROMs are slow to access unless you run them on the 21.5 MHz master clock and have some circuit on the cart act as a shift register. Bit-banging an SPI flash would feel like "loading" on a CD system.TOUKO wrote:why using compression today when big roms are cheap ??
There's the big one. Remaking S-DD1 or MSU1 for a production single-game cartridge might be cost prohibitive.93143 wrote:I can only think of a few reasons why one would try to do heavy-duty manual decompression on the S-CPU in the current year:
[...]
- to avoid having to source a rare, poorly understood (?) chip
The teams who's developing for the MD, don't care about this assumption .to avoid accusations of "cheating"
this is a good and valid argument .to prove it's possible
It's the only reason I'm in SNESdev in the first place. Mind you, it did turn out to be a really fun hobby...TOUKO wrote:this is a good and valid argument .to prove it's possible