Common In Games?

[justin3009]

Is it common for games to have multiple types of compression for various things?

If I'm seeing this correctly, Tales of Phantasia may have 2 or 3 different types of compression used for graphics in it's routine.

80: Decompressed graphics?
81: Possible 2bpp graphics (Menu Font comes to mind)
82: ??? (Possible Tileset?)
83: Sprites (Not fully sure.  Rheaiards come to mind on this but not sure what else uses it)

I haven't fully explored all the routine types in it so it may just be a subtle difference in each.

[Scio]

Yes, usually title screens or full-screen graphics (like Tokimeki Memorial) use a different type of compression than fonts and sprites.

[FAST6191]

It is something I would note in a general assessment of a game, however it is not going to be the subject of a post titled "Guys, guys, guys, check this out!" unless the compression method itself was otherwise novel.

On newer systems there is something of a tendency to just say "whatever LZ we have'll do", many more support such compressions at a reasonably low level. On older systems you may have had to adapt it to the type of data being compressed to get those few extra bytes of compression or speed in decompression.

[Nightcrawler]

It's very common for SNES era games to use multiple compression variations. I've worked on one before that had 15 different methods! Now, most were simply variations of each other and many were pretty simple, but they were distinctly different and all had their own code segments and control activations. I really have no idea how it came to be that way. It seems a bit wasteful and unnecessary. My compression ratio was better simply utilizing a single method (of which they already had) for insertion.

I've also seen the opposite where a single compression routine is used for all compressed data for the entire game. Back in that era, nothing was standard so anything goes! 

[lytron]

I really have no idea how it came to be that way. It seems a bit wasteful and unnecessary.

Not necessarily, maybe the ways of compression are tailored to each data type's internal structure?

[Scio]

Maybe 15 people worked on the same game (on different shifts) and ended up making a chimera that works by a miracle.

[Nightcrawler]

Not necessarily, maybe the ways of compression are tailored to each data type's internal structure?

I thought about this, but one of the methods for example existed solely to do a mirrored back buffer copy for a few letters of the font that would have shared the same 8x8 tile if that tile were mirrored. The amount of bytes they added to the ROM for the routine exceeded the few bytes they saved. And when the whole font was treated as a stream using a single method, it still came out with a better ratio. 

I think they tried to offer optimal solutions for as many types of data as they could up front before using it. Maybe it would have worked out if there were more data using certain methods, but there wasn't. So, most methods ended up being unjustified as they just weren't being used by enough data for the savings to eclipse the cost.

[lytron]

Yeah, when I read the first stanza of your post, I had that notion, too, that they were like: "Okay, *whenever* we have another bit of data like that, we can compress it with that."

Seems like their programs weren't outlined to the last bit before they started programming... makes me wonder what kind of ideas for all these games got lost over the way.

[justin3009]

I'll have to read up on some forms of Compression then.

I took a test whack with Lunar Compress on Tales of Phantasia's menu font and it actually somewhat worked using Chrono Trigger's value to decompress.  So makes me wonder if  they have the same routine but with a variant of it in some form. (2bpp Menu Font anyway)

I can't get any kind of sprite to decompress even a bit with Lunar Compress so it's probably it's own routine.  Never checked tilesets as I'm not sure where it's loading those graphics quite yet.