Video: Lesson Aku21+22 - RLE bitmaps with AKUSprite

Posts about Z80 programming that do not relate to a particular computer
Post Reply
User avatar
akuyou
Posts: 463
Joined: Mon Apr 22, 2019 3:19 am
Contact:

Video: Lesson Aku21+22 - RLE bitmaps with AKUSprite

Post by akuyou » Wed Apr 24, 2019 9:59 pm



http://www.chibiakumas.com/z80/akuma2.php#Akuma21

When developing ChibiAkumas Episode 2, I wanted to be able to store MORE graphics in less space - I decided I needed RLE compression, and as I like to try to do everything myself, I decided to write my own RLE Compressor/Decompresser and file format!

Check out what I came up with!

--------------------



http://www.chibiakumas.com/z80/akuma2.php#Akuma21

While the Compressor is written in C#, The ChibiAkumas RLE decompresser is Z80 based...

In this lesson we're going to look at the CPC version of the decompresser and see how it works!
(the Speccy/SAM and MSX ones are fairly similar)
Chibi Akuma(s) Comedy-Horror 8-bit Bullet Hell shooter! // 「チビ悪魔」可笑しいゴシックSTG ! // Work in Progress: ChibiAliens

Interested in CPU's :Z80,6502,68000,6809,ARM,8086,RISC-V
Learning: 65816,ARM,8086,6809

John
Posts: 32
Joined: Tue Mar 24, 2020 1:18 am

Re: Video: Lesson Aku21+22 - RLE bitmaps with AKUSprite

Post by John » Fri Feb 19, 2021 8:10 pm

The compression algorithm here

https://www.youtube.com/watch?v=gpsvgWsTX1I

also used in this impressive zx81 hi-res demo

https://www.youtube.com/watch?v=gpsvgWsTX1I

gives on average (for an arbitrary image) better compression than RLE. It also easy to implement. It basically summarised as follows. Suppose the image is made up of custom characters of 8 by 8 pixels and is monochrome so it needs a byte to store 1 line of the character.

1) For each tile of the character search through the ROM of the machine to find a sequence of bytes that is an exact match or a near match for those 8 bytes. Note that usually on an 8 bit machine a ROM address is stored as 2 bytes (thus it already saving 6 bytes per character). Store this ROM address.
2) Do this for every character that makes up that image
3) Store this list of ROM addresses.

Color information is compressed in a similar way. To decompress is basically the reverse of above.

However the image may look slightly "damaged" (but obviously recognisable) though this may be acceptable depending on the situation. Or the image may compress perfectly using above method. But image damage is to be expected using a lossy image compression algorithm-for example JPEG compression may visibly damages with artifacts (the reason there is because JPEG a compression algorithm acts like a filter with the cosine Fourier series). The above saves about 75 percent memory (because 2 bytes are stored instead of 8 at step 1) for an arbitrary image. The compression becomes better the bigger the system ROM is.There are obvious variations of above to try. For example representing 4 consecutive bytes in the 8 by 8 character with 2 address bytes which means four bytes will be used to represent 8 bytes. Which is still a good saving of 50% memory.
We could use a smaller ROM area which can save bytes. RLE on average would be significantly lower than 75 percent memory saving. 2-RLE is an improved variant of the RLE compression algorithm and a google search shows 2-RLE has a compression ratio of 56% (which is significantly less than 75%).

Post Reply

Return to “General Z80 Programming”