Here is the sprite compression tool I created for my 2007 entry I have made it a little more user friendly and thought I would give it to the community.

The tool is useful for entrants who are using (or going to use) pre generated sprites in their game.

Features:

-Single or Multiple images can be stored in one output file-When used with DataInjector can be embedded in the class file.-Generates java source code for loading the images tailored for input images. This is to reduce overhead.-1 bit transparancy-Images are stored in a highly compressable format. For most sprites the file size is significantly less than crushed pngs.-By using command line options you are able to reduce the file size even further by removing known properties from the images' header portions. E.g. constant sprite dimensions, No transparancy, etc-Able to store pixel colours in HSB format to cheaply generate different coloured versions of sprites by adding an offset to the HSB colour.

The main Idea to convert the image into a highly compressable format is to store an index of the different colours used in the image by order of similarity, thus pink is stored closer to red, different shades of yellow are next to each other and so forth. As it is likely that pixels with similar shades of colour are located near eachother due to shading and gradients in the sprites we can now record the difference between the previous pixel's colour index and the current pixel's colour index instead of recording the index of the colour used by each pixel.

This process can make long strings of similar bytes which Deflate can then compress extreamly well.

Comparision Results:

Each image format had been compressed into a ZIP file using KZIP to simulate embedding into a class file in a JAR

The BMP as been created using the 4 bit RLE optionThe PNG has been passed though pngcrush using the brute and reduce optionsThe GIF has no extra options The Ordered Index Differences version used the -auto and -noTrans options

The BMP as been created using the 4 bit RLE optionThe PNG has been passed though pngcrush using the brute and reduce optionsThe GIF has no extra options The Ordered Index Differences version used the -auto and -noTrans options

I used InfoZip with the -9 option, so you can probably get better compression using 7Zip or KZip. (For comparison, I got 681 bytes for OID using InfoZip.)

Not to steal your thunder. This looks like a pretty cool tool! Do you know if the decompresser compiles any smaller than SuperPackME? That was where I was always losing some of my space. I did optimize the decompresser over the officially released version, but I always felt that it should be possible to get just a smidge more out of it.

no gif can have several options: version 87/version 89interlaced/not interlacedtype of palette:system,custom,etc...number of color: 1-256transparency: on/off

looking at your gif, I see they was not a lot of color so I simply reduce the number of color to 10 with PSP8, can be done by most picture editor, also using it in raw format you can remove some bytes for multiple gif by removing identical header "GIF89a...." that will always contain same info width/height/nb color etc...

NB: in most case zipping a gif/png/jpg should not reduce it as gif is viewing by zipper as random number, without pattern. zipping an already compressed file is ususally not necessary.

NB2: I would recommend using animated gif for multiple sprites with low color, so palette will be only encoded once and use jpg with low chrominance channel sampling 4:4:1 for complexe sprite as photo or such.

good point, however not all sprites are the same size so will not work in an animated gif unless you increase the the size of all sprites to match the largest which may introduce more overhead by reducing the sprite sizes when decompressed.

while embedding the gif inside the class will cause it to be "zipped" again and probably add a few bytes, the size of the embedded class when JARed sould still be quite a bit smaller than a JAR with the class and the gif in seperate files

from my testing it seems that my decompression algorithm is cheaper than SuperPackME decompression algorithm so for small number of sprites the ordered index differences compresses better, however the story changes with larger number of sprites as the SuperPackME compresses better and over comes the cost of the decompression algorithm.

I wonder if i can merge the two algorithms and get even better compression

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org