I had an idea just now, and I have no idea if it's been attempted before or if it already exists and I'm just not in the know.

Basically, think of a tile viewer, except that you can provide an arbitrary segment of code to decompress it.  The tool would come with several presets for common compression types, letting you choose between any loaded compression type and specify an offset in the ROM to begin decompressing, and show you the result graphically as a way to diagnose what type of compression it uses.  Of course it would need support for palettes, changing tile size if it's graphical, width/height of the viewport, etc.  And it would only work for complete data segments, obviously, since any coded thing is relative to the ROM and unable to (realistically) parse out.

Has this idea come up before?  I think it would be monumentally useful for people who know a location of compressed data, but don't want to trace through code to figure it out, or for people who think they might have a particular type of compression and would like a simple way to verify.

Edit: If this is correct, my question has been answered:


If so, would this tool be useful?  I don't see it being too hard to make, except for the barrier of having to make some kind of scripting language or using some kind of markup language like XML so people could insert their own compression algorithms.

Laying out the compression format in an XML type file is enough to get a utility to be able to decompress it -- but recompression is another issue (and a much bigger task -- the compression scheme alone may not be enough to effectively compress data).  I guess if you're only looking to decompress this could work... but that's only half the job, isn't it?  What good is decompressing and editing the graphics if you can't put them back in the ROM?

I'm of the opinion that it'd be as hard or harder to write a plugin for such a utility than it would be to just write a simple standalone commandline program that compresses/recompresses graphical data.

I don't doubt you -- but I find that very suprising.

I guess I seldom deal with compressed graphics.  Most of the compressed data I'm used to dealing with is level data -- and unless you want to write a small handful of new routines to load uncompressed levels, you pretty much have to recompress.

*shrug*  chalk it up to my lack of real world experience in ROM hacking   

I'm not sure how useful that is going to be.  I've dealt with many games that use that same basic format RLE or LZxx (I'd say those two are the most common in cartridge based consoles), but none of them share the exact same details as far as how they derive length and lookup position for LZ. There's just so many different possible combinations. Even when it comes to RLE, there's always some custom variation thrown in.

Unfortunately, it's just not as easy as looking at data through some RLE or LZxx algorithm to determine what yours is.

Where it WOULD come in handy is when multiple games do share the exact same compression. Often times, developers will reuse their compression routines such as Nintendo on multiple games. Or for the GBA where many games use the standard BIOS compression.

Tmod2 gives the user the ability to right plugins that can decompress. I just could never get DM to compile my source (missing some linker) :/

 ROM translators have it easy. For PCE CD games, 9 times out 10 you need to add a compression scheme, or rewrite a better one, or add a second stage compression scheme (after decompress LZSS, then decode DTE). Sega CD is probably a similar situation.

 Btw, has anyone come across delta encoding for text in a game or have written their encoder/compressor for one?