rainwarrior wrote:
I don't know what codemasters is
Video game developer. During the NES era, it developed unlicensed NES games such as
Bee 52, which used a fairly space-efficient image codec that
tokumaru reverse engineered. (Not to be confused with
something else 52.)
Quote:
but a simple scheme that sometimes works well is converting the image byte stream into differences first, so that new[n] = original[n] - original[n-1]. Then to decode it you just need the last value decoded, and you add the new difference byte.
Difference as a would probably work well for grayscale or truecolor images, which are typically stored with one byte per component. But on planar images such as NES tiles, it's probably better to implement the additions and subtractions bitwise (that is, EOR). Otherwise, differences in more significant (leftmost) bits tend to mask correlations on the less significant (rightmost) bits. PNG gets this wrong.
Quote:
There needs to be control messages in the stream telling you when to switch bit sizes, or reset the accumulated value, or you could probably combine it with RLE
Huffman coding on the byte-to-byte differences would produce a short code for a difference of zero, which in turn would end up incorporating some of the desirable aspects of RLE automatically.
Dwedit wrote:
So for pixel values, you can make 0 by itself encode a zero value, 10 encode 1, 110 encode 2, and 111 encode 3.
What you describe is very similar to what the Codemasters codec does, except it uses the 1-bit code for zero instead of triggered RLE. It's just that anything that handles a pixel at a time instead of a byte at a time is bound to be slow.
Making a multicart of NROM games, on the other hand, requires special consideration. A lot of NROM games use a repeated tile (such as a little X) to mark unused space in CHR ROM, so a "repeat last tile" command helps save space. And a lot of tiles use only two colors (0 and 1, 0 and 2, 0 and 3, 1 and 2, 1 and 3, or 2 and 3), so it's useful to have short codes for a plane that's solid $00 or $FF or for a second plane that's a copy or inverted copy of the first. Finally, Shiru's games tend to have a lot of tiles repeated between the two 4 KiB banks of the pattern table ($0000-$0FFF and $1000-$1FFF) for use in tile animation, so it ends up very useful to have a code for repeating 16 bytes starting 4096 bytes back. There are about four ways to decode such 4096-byte repeats, depending on how much free RAM you have and whether you can leave the screen off.