| |
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....
|
| |
Mirage
Registered: Jan 2003
Posts: 113 |
Timanthes can't load .prg, it's one of the many flaws :)
I suggest you use WVL's little tool (or wait for ninja's, as he seems to have something aswell... it will probably use lots of illegal opcodes, though ;) |
| |
WVL
Registered: Mar 2002
Posts: 885 |
Quote: Timanthes can't load .prg, it's one of the many flaws :)
I suggest you use WVL's little tool (or wait for ninja's, as he seems to have something aswell... it will probably use lots of illegal opcodes, though ;)
but my little tool only works for hires, since I made it especially for Trans*Form.
I think it's a must for Timanthes to load .prg's, or at least be able to convert VICE-screenshots to restricted mode, without having to recolor all the colors. (just a new c64-colorramp option, to convert pixels to the nearest c64 color will be enough, me thinks)
I think I'm getting RSI just from doing all that recoloring.
Now that I think of it.. I also have a tool to optimize multicolor bitmaps :D It's part of the PDtool, to optimize the backgrounds of Pinball dreams :) |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
@Mirage:
If you need something to load/save Koala pictures (and Amica Paint while you're at it) take a look at my gfxpack functions: gfxpack-20070308.tar.bz2
There's a function `read_file()` which will load a file and (re)allocate memory dynamically while loading. It also has the option to skip the load-address of a .prg file.
Not finished at all, many more file formats should be added. I'm actually writing this so hopefully Tao's cbmplugs can load/save Amica Paint and other packed files ;)
Ofcourse it's all written in ANSI-C, not C#, but I think it should be easy enough to write a wrapper for it.
|
| |
algorithm
Registered: May 2002
Posts: 702 |
to make the data more compressible but keeping the data structure intact, some type of routine can be used to swap col nybbles, 2bit mcol pixel pairs, etc until thedata compresses to a smaller size than usual
|
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
Try this one:
GFX Transformer 1.0
Just load & save a koala. Every image will be cleaned after loading. |
| |
Conrad
Registered: Nov 2006
Posts: 833 |
Hey neat! Never knew there was koala packer avaiable. I'll start using this too. :-) |
| |
Ninja
Registered: Jan 2002
Posts: 404 |
algorithm: What I mostly did is, rearrange the colors sorted by brightness. This is useful for fading, and often helps with compression. Still, if one is aiming for max. compression, a lot more analysis of the data is needed. A bitmap with lots of repeatings patterns should be created then, I guess. One of those interesting problems, which can easily grow pretty complex :D |
| |
Mace
Registered: May 2002
Posts: 1799 |
The thing with the way files are archived in CSDb is that it's virtually impossible to find a tool of your desire, without knowing the name.
@NinjaDRM: just sorting won't work, imho. You should also put equal nybbles of concurrent positions in the same place. Like, when you have colour 1,2,3 and 3,4,5 in neighbouring positions, you might want to have colour 3 in $d8xx, alhough this might not result in cascading brightness. (If you catch my drift) |
| |
WVL
Registered: Mar 2002
Posts: 885 |
My tool does exactly this.
first it checks what colors are _really used_ in the current char, and then checks if the same colors are used in the previous one, and rearranges to colors so the nybbles match
(if there's an unused color, it tries to fill the value up so it matches with the previous color! coolness! ie, char 0 color is $12, char 1 color is $x1 (x can be anything but isnt used), it rearranges char 1 to $12 too!)
However, this does not always result in a better packing.. since you're only looking at the colors, and not at the compressibility of the bitmap itself. Actually, i think you should combine the optimizer with the packer, and try out all color combinations for a char and see how well it packs.
so :
1)start with char 0
2)try all color permutations, and send this into the packer, select char with lowest # of bytes
3)go to the next char, and repeat.
However, even when this will be a lot better, it will still not give you optimal packing.. you'd have to consided all color-permutations of all chars at the same time. Horrifying.
I guess the best would be some kind of heuristic algorithm, deciding what is the best way to permutate the colors in a char.
|
| |
Ninja
Registered: Jan 2002
Posts: 404 |
Mace: As I wrote, the sorting was intended for fading mainly, and it just turns out that it often helps with compression, too. I think for real hardcore compression, it would be useful to rearrange the bitmap to have lots of repeating patterns and not just concentrate on RLE in the color data (cause of 8K vs. 1.5K). Or maybe to skip this bitmap+colordata-idea and use something abstract. Lots of possibilities here! |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
