| |
Oswald
Registered: Apr 2002 Posts: 5007 |
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 ?:) |
|
... 44 posts hidden. Click here to view all posts.... |
| |
Mace
Registered: May 2002 Posts: 1799 |
I don't have time either, so let's set the date for Xmas 2007 :-)
Also, just exo'd data isn't interesting.
For optimizing sake you might be right, but this doesn't leave room for exotic ways of storing a picture in the memory.
If this is the plan, I'm out, as it's no fun ;-)
I might just give it a go... some time.
First some other 'projects'. |
| |
algorithm
Registered: May 2002 Posts: 702 |
pre processing the file and then using custom compression would give optimum sults, but the lz based compresion isgood enough for most purposes |
| |
tlr
Registered: Sep 2003 Posts: 1701 |
I probably won't have time either, but why restrict it to exomizer?
Any runnable program that shows each of those 3 pictures should be allowed.
Some of those will be _slow_! ;)
Also I think it should be just one picture per binary.
|
| |
Mace
Registered: May 2002 Posts: 1799 |
@ TLR: be my guest ;-) |
| |
MagerValp
Registered: Dec 2001 Posts: 1055 |
Maybe it's time someone did arithmetic (de)coding on the 6502?
|
| |
Mace
Registered: May 2002 Posts: 1799 |
I always liked data (en)(de)coding, although it's not quite my field of expertice.
One of my experiments was plain Huffman encoding, but I quite when I had to find a way to store the binary 'tree' in such a way that the crunching actually produced a smaller file :)
Also, my knowledge of existing mathemetic algorithms is fairly non-existant. That's not handy, when doing stuff like this.
Just a brain fart: what experiments could you do with rotating data?
If you have data like:
.byte $00,$ff,$00,$ff,$00,$ff,$00,$ff, Rotating that 90 degrees would result in 8 bytes with the same value.
Easier to pack than a pattern... sometimes :) |
| |
WVL
Registered: Mar 2002 Posts: 885 |
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. ;-) |
Previous - 1 | 2 | 3 | 4 | 5 | 6 - Next |