Hey, I am working on two entries right now for the contest, but am having trouble bringing the size of one my PNG’s down. Any advice?
I was thinking about trying out SuperPackME but can’t find it anywhere, the original site seems down and has been for about a week or two now.
Any ideas/suggestions would be most appreciated. Thanks.
The best way to store images very much depends on what they look like.
Obviously the most efficient solution is to not need them at all.
So, could they be replaced with primitives?
Or, could you generate them programmatically?
If not, how many images are there?
For one/few image(s) the overhead of a custom packing implementation can be prohibitively expensive.
If however you have many images that have common palettes and/or few colours, SuperPackME or the like can give big savings.
As you should never have more than 1 file inside the jar, are you already combining these 2 png’s into a single combined image?
(and then embedding this combined image inside the class file as a UTF8 encoded String or custom class attribute)
My current PNG is 256x32 pixels, saved as 8bit that contains 8 32x32 sprites.
[quote]As you should never have more than 1 file inside the jar, are you already combining these 2 png’s into a single combined image?
(and then embedding this combined image inside the class file as a UTF8 encoded String or custom class attribute)
[/quote]
I currently have a single PNG, my class file and the manifest. How do I embed this image inside the class file? Do you mean breaking it down into a hex array of bytes and building this image off of that?
you may try “pngquant”
command line software
I will give that a shot. I like that is command line since I can automate it easier than a gui program.
That’s 32kb of raw data!
Yeah, I know. But there must be a way, because Kevin Glasses 4k Hack game used just about as many images and he was loading from a file based on his source code. I must be doing something wrong during the compression phase.
On a side note I am using 7zip to compress the original files, than running the jar through ProGuard and have been using JoGA on the result from that. JoGA has been having problems with my jar’s for some reason lately saying that it has detected the use of the reflection API, which I am not using…
I had developed an image compression technique similar to SuperPackMe for my 2007 4k entry.
I have found a version of superpackME on my computer… it is not original so i am not sure whether it is in a working state:
moogie: Thanks for the links. I will try these out very soon!
Here’s what I did:
This usually takes my sprite sheet down to about 500 bytes.
Been a while but try these:
recommended software:
pngcrush (do brute force all methods, strip out unneeded headers)
pngtrans (but watch out, can break the pngs)
Other optimisations:
Drawback is that you would have to recompose the image or render each tile individually (so don’t choose a too small tile size)
group up textures that contain the same palette:
better compression
pak zem up together
Even if you are stuck with multiple single files, it might be better to simply dump them all into one file that is then used in the jar.
This is kinda what tar.gz does because the compression of one single larger file is often better then the sum of multiple smaller ones.
Actually smaller files can result in larger packed archives. (nicely visible by zip UI progs such as the one by 7zip)
If you are sticking with a seperate image in the jar, then you should take a look at pngout.
You should also try changing to Gif, as inside a jar file 8bpp gifs tend to compress better than the equivalent optimised png.
This is mostly due to both zip(jar) & png using the same zlib compression algorithm (deflate).
Gif on the other hand uses lzw compression, allowing for a degree of synergy when it is recompressed by the jar files zlib.
Don’t get me started on the ‘brilliance’ of making Java’s standard image format & container format the same compression algorithm…