gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Game Design > SNES/NES/GBA compression formats?

#25972 - LOst? - Thu Sep 02, 2004 4:36 am

Can you people reply with compression formats used by SNES/NES/GBA? And if you know compression formats used by other consoles with tile based graphics please reply with those too!

I need to search for a compression format that can compress almost any data with over 55% ratio. LZ77 is not powerful enough on the data I'm compressing. So what compression format is giving a higher compression ratio that LZ77 and still uses the same technique?

#25973 - sajiimori - Thu Sep 02, 2004 4:51 am

pucrunch is supposed to be good.

#25982 - tepples - Thu Sep 02, 2004 2:59 pm

Most NES games stored tiles without compression in a planar form because the console read the tiles and sprite cels directly out of a second ROM chip.

Some NES games, on the other hand, contained 8 KB of VRAM for tiles and sprite cels; many games used forms of RLE. The Super NES contained VRAM inside the console as well. Quite a few Super NES games used a compression library that appears to have originated at Nintendo.

Your best bet for documentation of these compression formats is at ROM hacking sites. Find them with Google.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#53560 - LunarCrisis - Fri Sep 09, 2005 5:16 am

LOst? wrote:
I need to search for a compression format that can compress almost any data with over 55% ratio. LZ77 is not powerful enough on the data I'm compressing. So what compression format is giving a higher compression ratio that LZ77 and still uses the same technique?
The compression technique you should use really depends on what sort of data you are compressing. For tiles, and if you don't mind the slight delay when decoding them,I would recommend to try and get libpng running and pack your tiles into square PNG files, which have quite good compression ratios.
_________________
If a tree falls in the forest and no one is there to hear it, why the heck do you care?

#53607 - phantom-inker - Fri Sep 09, 2005 6:39 pm

LOst? wrote:
I need to search for a compression format that can compress almost any data with over 55% ratio. LZ77 is not powerful enough on the data I'm compressing. So what compression format is giving a higher compression ratio that LZ77 and still uses the same technique?

This is probably not a very good question, since different compression techniques are used on different kinds of data. It's a very different task to compress photographs than to compress audio, or to compress text or to compress code: It all depends on what kinds of data you're compressing, and what kinds of tradeoffs you're willing to make.

For example, is your data such that it must be reproduced exactly when decompressed? If it doesn't have to be exact (as is the case with photos and audio), you can use lossy compression to discard bits that would otherwise require a lot of space. There are a variety of lossy compression techniques targeted at various different spaces: The discrete cosine transform (DCT) works well on photographs and artwork and forms the basis of JPEG; and Fourier transforms work well on audio and form the basis of MP3s; and wavelets work well on both types of data and form the basis of JPEG2000.

Even if your data must be reproduced exactly, it makes a big difference to know what it is: Some lossless compression algorithms work much better on one kind of data or another, and some are targeted at a specific kind of data. If you know your data is plain text, for example, you can usually generate a more efficient compression algorithm than if your data is just arbitrary numbers; and if you know your data is pixel art, you can usually apply a filter before a general-compression algorithm that will generate far better compression.

In short, answering this question well depends on your ability to describe your data. If you'd care to provide a more accurate description of what you're trying to compress, we can probably point you in a better direction.

And --- it is impossible for an algorithm to exist that can always compress any given input data by at least 50%. By simple recursion, this would necessarily imply that any data could eventually be compressed down to less than a single bit, which is obviously wrong. Not all data can be compressed, and some kinds can be compressed better than others. Knowing what kind of data you're working with can make a major difference.
_________________
Do you suppose if I put a signature here, anyone would read it? No? I didn't think so either.