PC Engine graphics sizes and compression

[Bonknuts]

Heh, I figured it might have been too much a 'wall of text' post. But I love the PCE and tend to get a bit carried away when it comes to topics that I love.

 Anyway, I've made HuC versions of Pucrunch and could easily do the same for Aplib and Packfire, as well other simpler compression schemes. If anyone is working on a series project and would such support, I'd love to help out by providing that kind of support

[Nando]

This is one my area of specialties.
(. . .)
 So, that's my 2 cents

Wonderful post, incredibly informative. Thanks for taking the time to write all that out

Indeed, a lot to take in, in one bite, but DAMN! thank you!

[kamiboy]

I would never have guessed any form of compression scheme was viable on game hardware from the 80's. I thought that fast access to cart memory would be negated many fold if you had to custom process all read data by way of the slow CPU.

Those programmers were regular wizards to pull off stuff like that, and do it all in assembly. I shudder to think. We sure have it easy today.

[spenoza]

I would never have guessed any form of compression scheme was viable on game hardware from the 80's. I thought that fast access to cart memory would be negated many fold if you had to custom process all read data by way of the slow CPU.

Those programmers were regular wizards to pull off stuff like that, and do it all in assembly. I shudder to think. We sure have it easy today.

On the one hand, yes, those developers were keen folks, in part via being used to operating in assembly. On the other hand, graphics data for PCE and MD games is fairly simple and should be easy to compress. We're talking about graphics data with set resolutions and only 16 colors, and it doesn't really matter which 16, because that's handled by palettes. Given this, it only takes so much CPU power to decompress files which should see measurable compression value. I would imagine a 50% size reduction over uncompressed would be pretty reasonable.