Sounds a bit like The Hobbit's original screens! Could be efficient but not sure about the detail...
You'd maybe end up programming it as a list of numbers that are passed to the ROM routines for drawing lines, and then a fast fill. Almost like writing it in BASIC with PLOT and DRAW.
Or you could define some simple UDGs; e.g. horizontal, vertical and diagonal lines, corner triangles, 1x1 and 2x2 quarter curves, then draw the screen with just characters and attributes. That'd be 1.5K a screen. Then run a compressor on that stream of bytes.
Actually a 3x3 quarter circle is quite efficient to do with characters if you hit the corner of the 2x2 inner square with the curve. Then you only need 4 UDGs to describe it. The rest of the characters are all solid or empty. Good for wheels on a bus of lies!
MiniDict3 Screen Compressor for Spectrum
- Lethargeek
- Manic Miner
- Posts: 742
- Joined: Wed Dec 11, 2019 6:47 am
Re: MiniDict3 Screen Compressor for Spectrum
Interesting. I did something similar (but more advanced) 2-3 years ago:Joefish wrote: ↑Thu Oct 17, 2019 5:34 pmMy 'MiniDict' technique is to XOR each attribute with the one before, which turns repetitions into zeros.
I then XOR each pixel line with the one above, which again reduces blocks of pixels to just lines and dots around the edges. (What it's not good at is stipples).
Then I do a frequency analysis of what's left, and pick out the 16 most commonly used bytes (other than 0). Again, this takes advantage of the dots that are left by the XOR process.
https://www.worldofspectrum.org/forums/ ... compressor
Xor preprocessing is a good idea, but compressing bytes (instead of squares) afterwards - not so much.
Unless you value the speed much more than the compression ratio.