Hello

After some discussion with Colin and TMR at the Geekend, I thought I'd give pucrunch a try for packing some of my game data. I'm happy to report that it works fine on the trusty BBC, and has been very useful!

Code assembled with relatively few changes. If anyone is interested, I can let them have the source and instructions!

Aye aye, I was going to implement simple RLE for none active levels, but this sounds like it might give me more compression. Wht sort of ratios did you get with yout level data ?

I've only tried it on my tile graphics data, but from memory, went from 2048 bytes to 816 bytes. Not too shoddy.

I'll also crunch the level data itself but I'd imagine the ratio to be less since there is already a rather crude method of packing the level data.

Interesting stuff Dave - I've been thinking myself about how I might compress a lot of graphics / maps, and had totally ruled out the likes of LZW on the Beeb.

I always planned on having a compressed sprite bank, and then, on each level, decompressing the whole lot to blanked screen memory, and extracting the sprites I need for that particular level... it seemed to be a reasonably good way to go, and the more data you have in your compressed block, the more benefit you get from the compression. Likewise, the maps would work in much the same way.

Well, if you have any examples to shove on the wiki, that'd be much appreciated

Sure, if I can figure out how to create a new wiki page - how do you do it?

Just add the name of your page to the main url

http://www.retrosoftware.co.uk/wiki/ind ... MyWikiPage

and it'll say the page isn't there yet and give you the option to edit it as a new page

Here ya go:

http://www.retrosoftware.co.uk/wiki/ind ... _Pu_Crunch

Sorry it's a bit rushed, me and Wikis don't seem to get on, but it should get the point across and prove how simple it is to get packing!

Interesting. I'll need to have a look and see how pucrunch compares with my own graphics specific compressor.

Kind regards,

Francis

I had a go with this using the screen data for Treasure Island and got some promising results.

The combined data for sprites, tiles and screens takes up just over 15K. After compression this was reduced to under 7K. Not bad at all.

Then, out of curiosity I tried to compress a mock-up of the title screen. It went from 20K to, get this, 2.5K

This got me thinking that the cruncher could be used to load in and display title screens quicker, especially on real hardware. I'd be prepared to knock up a quick demo if anyone's interested.

I've just tried the pucrunch against my own screen compressor, and it beats mine hands down!

The Mode 2 test screen that I used compressed from 20k to 9.5k using my compressor and down to 4.4k using pucrunch.

Kind regards,

Francis.

Out of interest, how big is the actual decompressor?

This sounds potentially very handy for Retro Software loading screens.

Maybe any compression algorithm experts can help me here, but one thing I don't understand about pucrunch is that it appears to implement two different methods of compression: run-length encoding and LZ77. But I was under the impression that RLE could be implemented by LZ77 anyway, so this seems wasteful.

As I understand it, the basis of LZ77 is that it's possible to insert a token at any point in the bitstream which contains two elements: a number of characters back in the bitstream, and a length. So if you have the string:

...this could be represented in LZ77 like this:


But if you only step back one character, and put a longer length, this effectively does RLE for free:

becomes


So have I missed something here? Is the RLE compression of pucrunch doing something different, or is it wasting code and compression ratio? It seems to me that you could probably write a better compression/decompression routine if you weren't wasting bits to specify whether a token was RLE or LZ77, not to mention having to implement different code to decompress each type.

...and further more, LZ77 can even implement a more flexible type of RLE, with multibyte repeated sequences e.g.

becomes

Perhaps the author wasn't aware of how to create this kind of data in his compression tool, or perhaps I've misunderstood his explanation?

Maybe his implementation of a separate RLE decoder is faster than the LZ77 one, but I'm just guessing.

Kind regards,

Francis