*** UPDATED 08-02-2007 ***http://www.java-gaming.org/forums/index.php?topic=15776.msg126194#msg126194
I have been experimenting with a new system to stucture images and embedd them directly into a class file by means of a custom 'attribute'.http://javaunlimited.net/hosted/moogie/test.jnlp
(use keyboard to move around... reloading with start you in another ship)
Please let me know if it
a) does not work for you
b) has bizarre behaviour (i.e. choppy then smooth)
It has been an interesting challenge but i have been successful, there are a couple more ideas for optimisations I want to try however it is at a point where it is giving significant dividends.
The main idea for my image storage is that there are likely to me gradients in an image and so by ordering the colour index of an image so that like colours are 'near' eachother then the indecies of the actual image to be stored will likewise be 'near' to eachother. So instead of recording the actual corresponding index for each pixel of the image, i instead record a delta. This delta will is always positive. Delta's which bring the index over the number of colours will cause the resultant index to be wrapped. This mechanism was chosen over the more intuitive negative and posive deltas as it was found that the implementation code need to read the image back was less expensive when using the wrapped positive delta mechanism.
This also means that multiple images with different colour counts and indecies will have a similar looking output allowing for better compression using the a deflate compressor.
There are some other tricks used in this test game to get it under the 4k limit ( I do not record the dimensions of the graphics or some other control flags in the image data as the image dimension data is read seperatly and the image is assumed to have a transparent colour. The more general version of the image format contains this information in the header.)
So for this test the following image:
is optimally compressed by pngout to 2580 bytes (plus the extra overhead of creating a "whole" image by flipping and drawing multiple times)
my current scheme brings it down to : 2020 bytes after compression using kzip. (also due to the nature of reading of the format, the whole image can be created in a single pass reducing the expense to recreate the images)
The shooter 'SubPar' will probably either remove sprites or I will need to reduce the colour count in order to fit in some game logic. I have a couple of ideas which may reduce the number of bytes needed with out loss of quality however I do not think that it will be sufficent. The first is make the image format more readily compressable by placing all the individual image 'headers' at the front to make a super header and thus having all the compressable data in one complete block. (this is do-able due to the fact that I know the sizes of the images before hand. The second idea is to attempt permuations of the ordering of the constant pool and other components of the classfile. This will probably not gain me much but every byte counts