| |
Oswald
Registered: Apr 2002
Posts: 5017 |
koala otpimizing
Hi Everyone,
I know there's a c64 tool out there that helps with optimizing koala pictures for packing, but no idea what it is called. Anyone knows?:) Timanthes would do the job for me aswell with its nibble swapper tool, but is there a way to load/save a native c64 koala format picture with it ? *.prg doesnt works, what format does it expect to be .prg anyway ?:) |
|
... 64 posts hidden. Click here to view all posts....
|
| |
Mace
Registered: May 2002
Posts: 1799 |
However, before we forget: the original question was how to optimize the content of a Koala picture for crunching.
This is still an interesting question. |
| |
tlr
Registered: Sep 2003
Posts: 1703 |
Quote: However, before we forget: the original question was how to optimize the content of a Koala picture for crunching.
This is still an interesting question.
I completely missed that. :) I just read the later posts. |
| |
algorithm
Registered: May 2002
Posts: 702 |
Its a whole new ball game if you wish to keep the file format intact. As mentioned before somewhere in this subject, swapping over color data between nybbles, etc or/and changing bit sequence order of twobit pixels so that there will be more identical sections - which in turn would allow a compressor such as exomizer to compress the data more tighter..
I still prefer the entire encoding of data and then custom compression - which would give tighter pack rates.. and its all about size.. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1370 |
I thought this 'otpimizing' sounded like an entertaining challenge, so I've given it a go.
No rules seem to have been particularly agreed upon, but the one I considered most entertaining was attempting to get all three images in the smallest executable file possible, vis my 19141 byte entry here:
http://jaruth.com/c64/0704/3pics.prg
It deinterleaves the colour data before using a simple run length compression scheme (the nybbles have been chosen to maximise the run lengths), then applies LZ77 with a fixed huffman code for the bitmap. The third image in the corpus is pixel shuffled to improve the packing. (saves over 200 bytes on the compressed data, but then spends 91 on the deshuffle code). I'm not familiar with Exomiser, but this does beat pucrunch for this particular data set.
FWIW, I got Song of the Sunset down to 5436 bytes - I could shave off another six or seven bytes if I hard coded some decompression parameters, but that would be in breach of ninjadrm's anti-finetuning rule. I didn't consider the optional pixel shuffle to be an issue, as whether or not to use it is specified in the compressed data, not the decoder (kind of like PNG's alternate pixel interleaves).
http://jaruth.com/c64/0704/song.prg
|
| |
tlr
Registered: Sep 2003
Posts: 1703 |
Fine tuning is tricky to restrict. You compressor could just try a set of heuristics and choose the best one. Is that fine tuning?
Anyway, this got me interested! :)
Could you post the three source pictures you used so we don't work with different ripps?
|
| |
ChristopherJam
Registered: Aug 2004
Posts: 1370 |
Good point about the tuning - it's a fairly arbitrary restriction, and difficult to quantify. TBH I was also thinking it was time I downed tools and uploaded something, as I have other work I should be doing :)
Perhaps 'smallest executable that displays the three images in sequence, with space to advance from first to second and from second to third' should be the only rule.
Glad to see the interest, anyway! I've uploaded three PNGs and the common palette used as http://jaruth.com/c64/0704/srcs.tar.gz
but it may be simpler for you to just rip the data from the 3pics.prg. Bitmap is always displayed at $6000, with the video matrix at $5c00.
I just noticed that I failed to acquire the original shortcircuit loading screen - I vote we continue with the intro version at this point.
Where did WVL's contribution come from?
Happy coding! |
| |
tlr
Registered: Sep 2003
Posts: 1703 |
It's here: Foris - Untitled
The others: Short Circuit & Song of the Sunset
I ripped the short circuit picture from the original game and the others from the releases. Available as prg's: test_corpus-20070401.zip
Bitmap: $2000-$3f3f
Screen: $3f40-$4327
Color: $4327-$470f
$d021: $4710
|
| |
WVL
Registered: Mar 2002
Posts: 885 |
Christopher : is your pixelshuffler the same kind like the brainfart i had to shift every 2nd byte by pixels to deinterleave? |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1370 |
@tlr - Thanks for the pointers, and the c64 friendly corpus :)
@WVL - similar.
There are two levels of interleaving; the first takes each pair of bytes in the source and swaps the low nibble of the first with the high nibble of the second, so each byte then represents a 2x2 pixel block. The second shuffle places every second byte into a group of four, that hence represent a 2x8 pixel group (half char)
*rereads your comment*
"byte 0, byte 2, byte 1, byte 3, to try and undo the effect of pixelgrids."
Yup, that's pretty much my step two (though I take bytes 0,2,4,6,1,3,5,7), so a somewhat different effect given that I'm operating on already rearranged data. I was mostly attempting to increase the locality of the pixels, and experimented with a couple of different shuffles to see what combination made the most compressible image. Sadly, the first two pics both get slightly larger (around 30-40 bytes) if they are shuffled. |
| |
wil
Registered: Jan 2019
Posts: 42 |
Inspired by this thread, I made a tool that tries out different variants of rearranging the pixels in a Koala pic. In addition, it removes color information where less than 3 forground colors are used in a 8x8 area (or 8x4 if we count fat pixels) and sorts the colors accroding to a palette. All these features together help in compressing the Koala pic without changing the appearance.
The rearrranging requires a different display routine, since the bytes need to be unshuffled before displaying.
For packing I used exomizer.
All in all I got a filesize of 19045 byte including load address, decompression routine, unshuffling routine and display routine. I'm quite sure there is still plenty of room to optimze it.
The tool (it can be also used to optimize Koala pics without changing the format) and the packed example of the 3 file are here:
Pixelshuffler V0.4 |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
