| |
Oswald
Registered: Apr 2002
Posts: 5027 |
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 ?:) |
|
... 68 posts hidden. Click here to view all posts....
|
| |
WVL
Registered: Mar 2002
Posts: 886 |
another brainfart :
interleaving the bytes of the bitmap.
Instead of storing
byte 0,byte 1, byte 2, byte 3
you store
byte 0, byte 2, byte 1, byte 3, to try and undo the effect of pixelgrids.
Maybe shifting every odd byte 2 pixels would be even better. |
| |
Mace
Registered: May 2002
Posts: 1799 |
Since we're having a farting party anyway, some other thought:
When looking at the colour bytes, you have 'only' 15*14*13 = 2730 (which happens to be $AAA) combinations. The 16th colour is the background and each colour will only occur once in the colour triplet (= 3 colour nybbles).
Unused colours can be optimized to match a triplet that is already in use.
The bitmap can be optimized to create the largest amount of equal triplets.
The triplets can be sorted to see how many combinations are really used. These can then be represented by the shortest combination of bits.
[edit, afterfart]
Ooh, another one!
You can know how many nybbles of the triplets are used, if you have the bitmap. So when the bitmap says 'only one nybble in use', you can use the other bits of the triplet to store info for the next position. |
| |
algorithm
Registered: May 2002
Posts: 702 |
dynamic compression algorithms can be applied to specific areas of the bitmap. etc |
| |
Mace
Registered: May 2002
Posts: 1799 |
Hey, this is not fair!
If Algorithm is in, I'm out!
He can't be beaten by us mortals when it comes to graphics encoding. ;-) |
| |
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: 1724 |
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: 1381 |
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: 1724 |
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: 1381 |
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! |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
