That's a bit of an ignorant mentality to have and very close minded when approaching a general ROMhacker's 'Bible'. Depending on the system and the game, it's not always possible to allocate additional ROM space to load uncompressed data. Not to mention in ALL cases, if you did use the compression, you could make better and more efficient use of the space you do have.

My point is, ignoring the subject altogether is a poor idea for something called a 'Bible'. Compression information of sort is an absolute must.

Look at all the people on this board alone who run into the compression stumbling block and have no clue what to do.

How do you figure? I'd like to hear this one.

Well if compression schemes are used then it's something one should learn about.

It's not a matter weather it's obsolete.

For example FF7 uses 2 different compression schemes GZIP for some files (SCENE.BIN) and LZS for all the battle models and battle scene information.  GZIP gives higher compression however it's very slow. LZS is fast to decompress.

Currently new ROM images use compression as well.  If you have data that uses vast qauntities of space and you can save money by using smaller amounts of space. You compress the data. That's as simple as it gets.  Maybe Noah used compression on the T-rexs

Cyb

I'd think the romhacking bible would show how to deal with compression in games, and would refer the reader to documentation to read if they want more details. It doesn't need an entire book to cover it, unless you want to briefly cover the more common compression formats. [like DTE, for example]

That is exactly what I was hoping for. And maybe an example of how to recompress it and still fit it in. Or how to add compression, such as DTE or Huffman, to a game to save space. I for one, prefer adding compression to expanding a ROM. Why increase the file size? Anyways, of course you don't have to go over every example. Just one or two examples would be enough to give someone at that level enough knowledge to figure out another one their self.

The goal in my opinion would be to bridge the gap so someone CAN get to a compression capable level. Right now, people left and right hit that block and have NO IDEA how to get over it. You don't need to make a data compression bible. However, something on the topic should be there to help bridge that cap so people can utilize the information that is out there.

Lets revisit FF7 again? FF7 uses LZS compression (with all of the little tricks) however, the animations in the battle models for example are compressed also. (This drove everyone nuts including me as I was SO dang close I could taste it to having models that looked right.)  They delta compression with it that changes the delta size ocassionally with a special code size.  Simple things like this to RECOGNIZE for some poor Soul.

My Suggestion is to give a nice method for determining if compression was used.  Then maybe tips on guessing types. GZIP is easy to find because it uses magic bytes (can't miss those).  LZS is a bit different.  Delta compression ussually starts with a full set of data then has a weird byte indicating the delta bit width and then gives the delta data.  Things like these are priceless to give someone a decent perspective on getting a clue.

Giving every known compression scheme is exchausting and really not for a hackers bible. Instead it should defer to compression descriptions.  It should also give an idea of different compression schemes and where they are likely to be implemented.  Huffman is for example popular with JPEG and compression of the DCT data and YUV data.  Shanno Fano is used in ZIP.  Although there are a myriad of schemes only certain ones are good for particular applications.  RLE sucks for natural images, but is excelent for bit map fonts and things with large numbers of repeating pixels.  JPEG is bad for this type of data. Etc.    Simple clues like that give someone a starting place.

LZS is a fairly good general purpose compression technique.  It appears good for both graphics (all the MIM files are compressed using it) text and other data (scripts conversation XYZ camera information, walkmap etc. are all compressed this way).  I'm surprised it's not in FF8 or FF9 (they are not compressed at all turns out), though would have fit on fewer disks if they had used compression <like 3 or less like FF7>).

I suppose I could give you the C code for LZS decompression if you would like it.  Not terribly exciting I'm afraid.

Anyhow I think ignoring compression would be a bit of a sin. Really one could at least say MANY games use compression common ones for SNES blah blah blah.  Actually descriptions could be left to already available documentation maybe?

Cyb