|
|
Pages: [1] 2 3 ... 12
|
 |
|
Author
|
Give me all your tricks for minimizing jar file size (Read 67442 times)
|
Dan Kelly
Guest
|
Moderater Note: This topic has been stickied because it contains the best collection of ideas for reducing image size I have seen. When time allows I will try to compile this info into a more consise form.
Hi, I'm coming close to releasing my J2ME game... I am kicking up against the 64k size barrier which I have imposed as a maximum size for my game. I would like to add more levels to the game but the only way I can do that Is to make the jar smaller... Oh yeah I have made the decision to NOT have it download any data (maps, etc...) over the internet as well.
I have heard about using preprocessors to get rid of statics and that would make it smaller... Any thoughts, suggestions? Sun one studio 5 ME doesn't seem to support preprocessing... is there any free or cheap IDE that does?
Do any obfuscators do a significantly better job at reducing size than the retroguard one does?
I've tried to eliminate any common code amongst classes and put it in static functions that get called from many places...
I'm wondering about using shorts internally instead of ints... at first I was going with shorts thinking it would be a size savings, but now I'm thinking that all the conversions to ints and back are probably a size loss... anyone know the empirical answer?
If you have any tips to reduce jar size, please respond :)
Dan K
|
|
|
|
« Last Edit: May 26, 2005, 11:47:07 pm by shendley »
|
Logged
|
|
|
|
|
|
markr
New user
Posts: 32
Use markxr at gmail dot com if you want to email.
|
The normal ones
- Make fewer class files by combining possibly unrelated functionality into the same class (i.e. make an object a listener also)
- Make fewer data files by combining data. Obviously with PNGs this means film-strip type thing, but can be done with other data too.
Ones I've discovered
- Use an alternative zip program rather than JAR (test it for file size obviously). I use info-zip command-line zip program and invoke it from an ant task.
- Don't put directories inside the .zip - they aren't necessary if you're not going to expand the .zip. This saves some catalogue space.
- Ensure that any extended options (like unix, DOS extended attributes) are turned off in your .zip as they just waste space (ignored by J2ME)
- Use shorter filenames in the .jar - saves catalogue space (obfuscator already does this for classes, you must do it manually for data)
For Data:
Pack data into the smallest number of bits possible and use bitshifting to extract it
Mark
|
|
|
|
|
Logged
|
|
|
|
Jamie
Guest
|
I was recently interested in this... found an article on it. Ceck out "The Big Squeeze" on http://www.j2megamer.com
|
|
|
|
|
Logged
|
|
|
|
calvin-c
Member
Posts: 61
I'm not a llama! I am Ghostinator!
|
The best way to reduce size on your JAR file in terms of data is to place all your data into one binary file and read it out from there, including your graphics. JAR/ZIP packs generally better one big file than many small. I save around 25%-40% space on this by doing saw.
Of course, the back side of it is that on some phones the loading might go a bit slower, like on many of the Nokia Series 40 phones.
Also, if you are running low on heap memory, the backside is also that you take up some extra memory during the loading images from the binary file under the loading itself.
For everybody interessted, drop me an email (I hope you can see my email in my profile) and I will provide you with my source code and Windows application for generating this big file and also the J2ME code for reading out of the file.... Basicily the windows app work that it reads all files in the directory you select and place them all in one big file instead. Then you just use the J2ME code to read back the file you want by giving a filename...
|
|
|
|
|
Logged
|
|
|
|
shareme
J2me god
Posts: 1051
Java is the only drug
|
Image Files:
Load al into one png file adjust your code to acccess by frames..technique is known as filmstrip..size reduction occurs because you have gotten rid of al the png headers in not using muliple png files
Level Code:
If possible rewrtie using the Map Script File technique..
Map file maps out stuf of yoru levels with yoru rms code jsuut reading that data in thus reducing the szie of lvel logic code ia RMS..
Make effective use of global variables avoid recreating variable sin logic loops..
|
|
|
|
|
Logged
|
|
|
|
calvin-c
Member
Posts: 61
I'm not a llama! I am Ghostinator!
|
One thing you should be aware of by placing all your pictures into one PNG file as ppl suggest here, is that there are phones that have limits on how big the PNG files can be and other type of limits. Siemens has a 16 kb limits for objects (so you cannot load an image that will expand and take up more memory than 16 kb and you are already over that limit with an image that is for exampe 150x60 in size) and also have 255 px width limit togehter with other phones as the newer versions of T610 and some Motorola phones. Older T610 has a limit of that an image cannot be netiher wider nor taller than the screen itself.
Also, I see everybody points out that why you save much space by putting all images into one file is because you remove all PNG header etc. Thats right that it gets removed so you save SOEM space, but you do not save a lot of space on this. So this is NOT the reason why you save space. The header itself is only ca 40 bytes (++) so thats not much to save. Why you save more is because, like I stated above (doesnt anyone read the other posts here when they answer??), ZIP/JAR compress one BIG files to a smaller size than the if that file was splittet up in many files.
So the way to go to save space in your JAR file is the way I suggest to you. This will save you a lot of space. As I said earlier, drop be a line in ICQ, MSN or mail and I will provide you with code for handling this stuff.
|
|
|
|
|
Logged
|
|
|
|
|
|
calvin-c
Member
Posts: 61
I'm not a llama! I am Ghostinator!
|
This is only true if the PNG file is a 16 color or less image, a 256 color image has 3*256 = 768 bytes in the pallette chunk (a part of the header) alone. This is the biggest hint I can give, try to get as many images as you can into the least number of filmstrips but only if you can keep the colors to 16 or less.
Well, thats not entirley true. Color data are certainly never part of a header. The matter of fact, the PNG format does not even contain a header, so saying that the colors are part of the header is wrong. PNG (at least of version 1.1) consist of a signature of 8 bytes, then followed by a series of chunks, very similar to how 3DS and other similar formats are defined.
My statement about header roughly was 40 bytes +/- was ment to show that it is actually very little information that is stored in the file describing the file itself, unless you use specific features of the PNG format. The truth is that it is only 8 bytes (the signature) that really is the "header", the rest is more or less chuncks describing the image data (again if you remove specific features). Each chunck of course have some desc fields, thats it. Very little overhead, at least way to little to save any significant space.
But of course, for images that can all use the same palette of 32, 64, 128, 256 or whatever saves space by rather storing 1 palette than many, that for sure.
But as I stated above, the main reason WHY you save space by making a filmstrip is NOT because you have one palette, but the fact that the JAR compression (which is really just ZIP format) compress 1 big file better than many small.
But of course, film strips is one way to do it, but because of some of the problems I mentioned in earlier post (like Siemens phones does not take images wider than 255 px), a much muhc better solution is to create a PAK file containing all the images.
And to you guys that has asked me for the code but not got it yet, sorry for my delay, I have been really busy but will send it during this days.
|
|
|
|
|
Logged
|
|
|
|
shendley
Moderator
Senior. Member
Posts: 346
J2ME drains the soul
|
The matter of fact, the PNG format does not even contain a header, so saying that the colors are part of the header is wrong When I said header I was talking about all the chunks that are not the actual image themselves. Throw a png file into a hexviewer and you will see what I mean. There are these chunks atleast:
Color data are certainly never part of a header The color data has to be in the header, how else can the render know what color each pixel is meant to be. With non-truecolor graphics the only realistic way to do this is to have the pixels index into a pallete that contains the actual color data. The PLTE chunk describes the colors used in the image. The colors are encoded as 3 byte RGB values so a 2 color PNG has only a six byte pallete, 16 color has 16*3 = 48 bytes, 256 has 256*3 = 768 bytes.
But as I stated above, the main reason WHY you save space by making a filmstrip is NOT because you have one palette, but the fact that the JAR compression (which is really just ZIP format) compress 1 big file better than many small. I think we are both correct here. For example taking five 256 color graphics and making them a filmstrip will save more than 768*4= 3072 bytes. I didnt believe what you were saying so I spent a few minutes and set up an experiment. I made 5 256 color files of 50*50 bytes and then tried a regualr zip, made it a filmstrip and zipped that and then concantinated them together using copy /b and zipped that: here is what I found ( i used winzip 7.0):
- All 5 images just zipped: 8,724 bytes (or about 17% compression per file of about 1950 bytes)
- The zipped filmstrip: 5,411 bytes (a measly 5% compression on the 5,568 original file)
- The concantated list: 6,219 bytes (a healthy 38% on the 9,865 original file)
I did the same test after reducing the images to 16 color and found:
- The 5 just zipped was: 6,919 bytes (and none of the images compressed at all)
- The film strip was 4,663 bytes (also 0% compression)
- The concatinated files: 5,424 bytes (with a 10% compression)
The zero percent compression is not suprising as these files do not have the 700 byte zero fillled pallette buffer which is easy to compress, this also accounts for why the concatinated file did not do as well on the lower color test.
I was amazed to see how much better it compressed the concatinated files than the five seperate ones though it still wasnt as good as the filmstrip. I tested differnt set of graphics I had used a concatinated file format for against the raw images, and found the single file (about 30k) compressed to 24k whereas the regular images compressed to 29k, a nearly five kbytes saving.
From all this I would say that to get the absolute smallest zip, I would use filmstrips where I could, 16 color images allways and then concatinate them together aswell.
|
|
|
|
|
Logged
|
JFGI just isnt getting my point across; how about TGF - Try-Google-First.
|
|
|
calvin-c
Member
Posts: 61
I'm not a llama! I am Ghostinator!
|
When I said header I was talking about all the chunks that are not the actual image themselves. Throw a png file into a hexviewer and you will see what I mean. There are these chunks atleast:
Eeeeeeh, do you read what I write??!
First, when you quote me you better take with you the whole part, not cut it and just put things out of a context! I said that there are NO HEADERS in PNG, coz there are not. PNG consits of chucnks of data! Read my post one more time and you see exactly what I wrote! No need to twist that around...
Second, if you ment chunks when you said header, just as I did in the first place which you picked on, then you just ment the same thing as I have already said and could again just quote what I just said instead. You are just repeating over exactly what I said before.
No need to open it in a hex editor for me, I know the PNG format very well in my head.
The color data has to be in the header, how else can the render know what color each pixel is meant to be. With non-truecolor graphics the only realistic way to do this is to have the pixels index into a pallete that contains the actual color data. The PLTE chunk describes the colors used in the image. The colors are encoded as 3 byte RGB values so a 2 color PNG has only a six byte pallete, 16 color has 16*3 = 48 bytes, 256 has 256*3 = 768 bytes.
He he, you are talking towards yourself, first you say, as I have stated several times now, that PNG does not have any headers. Then you say that plaette has to be part of the header..
And why does the palette that need to be part of the header for the "renderer" (what that ever is in your speech) to read the palette data? HALLO..... Of course palette usally are NEVER part of the header!! A header is ment to descibe a file! While a palette is ment to describe the image data! Very different things! How do you get the pixel data which is neither part of the header?? You better take a look at 2 of the simplest graphics format around, BMP and PCX and you can learn how to get the palette data which is NOT part of the header.
Tellling that palette data needs to be part of a header to get the color data out to display the image is just bull.....
You read chunck by chunck in a chuncked format like PNG and 3DS, decoding what you read... No headers to care about nor does it matter in most cases which chuncks comes in whcih orders, unless, like in 3DS where some chunks are describing other chucks....
From all this I would say that to get the absolute smallest zip, I would use filmstrips where I could, 16 color images allways and then concatinate them together aswell.
I must admierly admit that I start to wonder which part of what I am saying is hard for you to understand...
If you know how huffman compression and similar works, you understand why you get better compression on 1 big file than 5 small....
But, filmstrips decrease the JAR size, however, THE VERY BEST way to get the smallest JAR file is the solution I say, to place ALL IMAGES into ONE SINGLE BINARY FILE which you then read the images out from, then you get the very best compression in ALL cases. Regardless if you use filmstrip or not.
1) Create a windows app that reads all the images and write them back to disk into ONE SINGLE BINARY FILE OF YOUR OWN FORMAT..
2) Create J2ME code to read back files from that file. Here is example code take from my games:
(I fixed the code a bit to make it a bit more readable)
/**************************************************************************************
* Reads an Image from PAK file and return data as an Image
**************************************************************************************/
public Image readImage(String file) throws Exception {
if (!initialized)
return null;
try {
buffer = null;
InputStream inputstream = pakfile.getClass().getResourceAsStream("/" + pakfile);
System.gc();
inputstream.skip(30);
filename = new byte[30];
found = false;
skipped = 30;
for (int i = 0; (i < dwNumFTEntries) && (!found); i++, skipped += 42) {
for (int l = 0; l < filename.length; l++) {
b = inputstream.read() & 0xFF;
b = (bCypherAddition == 1 ? ((b - iCypherValue) & (0xFF)) : ((b + iCypherValue) & 0xFF));
filename[l] = (byte) b;
}
String sFileName = new String(filename);
b = inputstream.read() & 0xFF;
b = (bCypherAddition == 1 ? ((b - iCypherValue) & (0xFF)) : ((b + iCypherValue) & 0xFF));
filesize = (b & 0xFF);
b = inputstream.read() & 0xFF;
b = (bCypherAddition == 1 ? ((b - iCypherValue) & (0xFF)) : ((b + iCypherValue) & 0xFF));
filesize += (b & 0xFF) << 8;
b = inputstream.read() & 0xFF;
b = (bCypherAddition == 1 ? ((b - iCypherValue) & (0xFF)) : ((b + iCypherValue) & 0xFF));
filesize += (b & 0xFF) << 16;
b = inputstream.read() & 0xFF;
b = (bCypherAddition == 1 ? ((b - iCypherValue) & (0xFF)) : ((b + iCypherValue) & 0xFF));
filesize += (b & 0xFF) << 24;
b = inputstream.read() & 0xFF;
b = (bCypherAddition == 1 ? ((b - iCypherValue) & (0xFF)) : ((b + iCypherValue) & 0xFF));
offset = (b & 0xFF);
b = inputstream.read() & 0xFF;
b = (bCypherAddition == 1 ? ((b - iCypherValue) & (0xFF)) : ((b + iCypherValue) & 0xFF));
offset += (b & 0xFF) << 8;
b = inputstream.read() & 0xFF;
b = (bCypherAddition == 1 ? ((b - iCypherValue) & (0xFF)) : ((b + iCypherValue) & 0xFF));
offset += (b & 0xFF) << 16;
b = inputstream.read() & 0xFF;
b = (bCypherAddition == 1 ? ((b - iCypherValue) & (0xFF)) : ((b + iCypherValue) & 0xFF));
offset += (b & 0xFF) << 24;
b = inputstream.read() & 0xFF;
b = (bCypherAddition == 1 ? ((b - iCypherValue) & (0xFF)) : ((b + iCypherValue) & 0xFF));
next = (b & 0xFF);
b = inputstream.read() & 0xFF;
b = (bCypherAddition == 1 ? ((b - iCypherValue) & (0xFF)) : ((b + iCypherValue) & 0xFF));
next += (b & 0xFF) << 8;
b = inputstream.read() & 0xFF;
b = (bCypherAddition == 1 ? ((b - iCypherValue) & (0xFF)) : ((b + iCypherValue) & 0xFF));
next += (b & 0xFF) << 16;
b = inputstream.read() & 0xFF;
b = (bCypherAddition == 1 ? ((b - iCypherValue) & (0xFF)) : ((b + iCypherValue) & 0xFF));
next += (b & 0xFF) << 24;
if (file.regionMatches(true, 0, sFileName, 0, file.length())) {
found = true;
}
}
if (!found)
throw new Exception("Entry " + file + " not found.");
if (offset >= skipped) {
inputstream.skip(offset - skipped);
}
else
throw new Exception("Wrong PAK file format.");
buffer = new byte[filesize];
for (int i = 0; i < buffer.length; i++) {
b = inputstream.read();
b = (bCypherAddition == 1 ? ((b - iCypherValue) & (0xFF)) : ((b + iCypherValue) & 0xFF));
buffer[i] = (byte) b;
}
inputstream.close();
inputstream = null;
System.gc();
}
catch (Exception e) {
buffer = null;
System.gc();
e.printStackTrace();
return null;
}
return Image.createImage(buffer, 0, buffer.length);
}
This IS the best way to create the smallest JAR file as possible... There are some backside of this technique as stated in my earlier posts.
Of course you can still create filmstrips and all this, at least for animations.... The point is that there is a limit to how wide your image can be, at least if you want to support phones like M55 and SL55, T610 etc.... Also, its not always a good idea to have to big images when drawing as it will in some cases slow down the pain instead, which is obvious a bad idea on a device with limited CPU capacity.
I have squeezed in A LOT OF GRAPHICS into our 2 games Winter Sports (http://www.digiment.no/main/main.jsp?category=mobilegames&sub=3) and Racing Destrucions (http://www.digiment.no/main/main.jsp?category=mobilegames&sub=5) with the technique I have just mentioned above...
I mention one more time, if anyone else is interessted in my code for creating this PAK files and the J2ME code for reading out the files from the PAK file, just drop me an email or send me a ICQ msg or whatever...
And as a comment to your 768 bytes saving for 256 colors palette.... Sure if you have 20 images which each has its 256 color palette sotred in file and the palette is the same in ALL cases, of course you can save 19*768 bytes by putting it all in 1 file.. but I say HALLO, who has 20 pics which ALL uses 256 colors??? I think you better start to think about reality here on how things works in pracsis... This images can for sure reduce their color palette to a number less than 64 colors in most cases, probably even less than that too, which leads you to that there are so few bytes to save on platte anyway... But as you already have proven for yourself, you see that the main thing is to keep everyting in one file because of the compression and not the palette data....
|
|
|
|
« Last Edit: May 26, 2004, 11:32:59 pm by calvin-c »
|
Logged
|
|
|
|
|
|
shendley
Moderator
Senior. Member
Posts: 346
J2ME drains the soul
|
Ok, I really dont want to turn this into a war but I again I have to disagree with you on a number of points, not to be difficult but becuase I want to know how to get my apps as small as possible.
But, filmstrips decrease the JAR size, however, THE VERY BEST way to get the smallest JAR file is the solution I say, to place ALL IMAGES into ONE SINGLE BINARY FILE which you then read the images out from, then you get the very best compression in ALL cases. Regardless if you use filmstrip or not.
In my previous post I showed that this is not true, I did an experiment that shows that the concatonation is NOT ALLWAYS the best method. If you dont believe me then just do the experiment yourself or PM me and I will email you the test images I used. Perhaps if you use a PNG type that doesnt use palletes (more below) what you say is allways true but this may not be so for everyone who is reading this thread.
I went back to the PNG spec docs http://www.libpng.org/pub/png/spec/1.1/PNG-Contents.html and tried to figure out how why we seem to have differnt ideas of the PNG file format. I think the confusion may be coming from the exact PNG format we are using, there are 5 differnt "color types" that the file can use. Only one of them uses a PLTE index. I use Paint Shop Pro 5.0 and all the non-true color PNGs it makes, and therefore all the PNGs I see, use this format. The other types use a direct RGB triple to define the color.
What image software are you using? I would like to know how the differnet types compare.
Using PSP5 I took the graphic at the top of the screen (big red image that says "J2ME.org" and "discussion....") and converted it to PNG. As a truecolor PNG it has no PLTE chunk and is 5,911 bytes long. A 256 color one (with PLTE) is 4,261 bytes long and a 16 color (with PLTE) is 2,265 bytes long. If you have a few moments to spare can you do a similar test and tell me what your software spits out. (BTW the conversion to 16 color format was not perfect as the background was using way more than 16 colors.)
Tellling that palette data needs to be part of a header to get the color data out to display the image is just bull..... You are absolutley correct if you use these other "color types" then there is no need for the pallette data but anyone else following this discussion should look into what exact format their image software is using before disregarding the things I have said about reducing the pallette size.
Just to clarify the terms I am using, when I say the "header" I am talking about the extra data that does not change format when you alter the actual image information. By that I mean, if I was to alter a picture by adding another frame of the sprite it would not change. (beyond updating the size of the image and that sort of thing). I would consider the tRNS (transparency) chunk or the gAMA chunk as part of the header, maybe you wouldnt, but it isnt really material to our discussion.
By "renderer" I was just refering to any piece of software that has to decode the PNG file and turn it into a displayable image.
But of course, for images that can all use the same palette of 32, 64, 128, 256 or whatever saves space by rather storing 1 palette than many, that for sure.
Unless I have misunderstood something the spec docs (http://www.libpng.org/pub/png/spec/1.1/PNG-Chunks.html#C.IHDR) say that there can only be 2,4,16,256 and true color PNG images.
Color Allowed Interpretation
Type Bit Depths
0 1,2,4,8,16 Each pixel is a grayscale sample.
2 8,16 Each pixel is an R,G,B triple.
3 1,2,4,8 Each pixel is a palette index;
a PLTE chunk must appear.
4 8,16 Each pixel is a grayscale sample,
followed by an alpha sample.
6 8,16 Each pixel is an R,G,B triple,
followed by an alpha sample.
|
|
|
|
|
Logged
|
JFGI just isnt getting my point across; how about TGF - Try-Google-First.
|
|
|
calvin-c
Member
Posts: 61
I'm not a llama! I am Ghostinator!
|
First, I would just like to say that I am a bit tired of quoting your stuff and commenting all of it so I just write it all clean here.
Next, I agree that it is no need for us to start a war, but I must admit that it is hard to avoid with your stubborness. You just repeat over and over what I have earlier said, paste stuff in from the PNG format which has little to do with tings and bring up other things that also has nothing to do with this things at all.
So, I take this again step by step.
1) Forget all about different types of palette, forgot that you can have true colors. We are talking about a normal palette here consiting of 16, 32, 64, 128 and 256 colors.
2) When you do tests, do it not once but 100 times and use realistic material that you would use in a real application.
3) For you information, so have I worked as a games programmer for small ang big companies for over 13 years (most with C/C++), where as over 2 of the last years includes developing proffesional games for the J2ME plattform. In other words, it is part of my DAILY work to do research and extensive tests on such things like we are discussing here so there are no need to send me code as I already have tons of it. Part of it is pasted in above.
4) Yuo neither do not need to paste in all kinds of things from the PNG fileformat coz I have most of it in the top of my head, so it is uncessary to bring things into this discussion that has nothing to do with the case.
5) We better keep to the case which is about 2 things; One where you claimed that palette data IS and HAVE TO be part of a header and second what methods is BEST to minimize JAR file.
And as answers to 5 and comments to your last posts:
First, you talk towards yourself, you claim that palette data (and YEAH we talk about plain normal 16, 32, 64, 128, 256 colors palette so stop draggin in all greyscales and 1 bits and true colors all the time) have to be part of the header. At the same time you say that PNG does not have any headers. Then you start to talk over and over again about headers. Then after mentioning headers and headers and headers, and after me explainng several times that there are no header in PNG format, only chunks, you explain that you mean chunck when you say header.
And that is fair enough but why do you still claim that palette data is part of the header and that it has to be?? The palette data is part of its chunk, not a header that PNG does not have.
My advice to you, extend your knowledge and look up one of the twos simplest graphics format around, the BMP and the PCX format. THEY have a header which describes the file and where to find the data, including where the palette data is located (which is NOT part of the header).... Then you can look up the 3DS format whihc uses CHUNKS the similiar way as PNG do. And learn the difference!
Of course, then you can just say that "I told you that when I said header, I ment chunk, so when I said that palette had to be part of the header, I ment that it had to be part of the chunk".... And no matter if that is true, it is just very silly to claim.... You are mixing 2 definitions which are NOT interchangable with each other.
But I admit, I did the same but in a very very different way which I also explained straight after you started to twist things around. I also used the word header when I talked about the desc fields for each chunk. I did this for simplisity instead of writing that all chunk desc fileds whihc is ment to describe the data in the the chunk take up roughly 40 bytes +/- (and NO the DATA, including palette data, is ONLY part of the chunk and NOT the chunk desc fields whihc only surronds the data it describes!), becuase I assumed that most people here is not to familiar with how the PNG format itself is defined.
What you do, is to twist things around. However, IF you mean the chunk DESC fields when you say HEADER, you are still wrong in that the palette data have to be part of it or is part of it. Of course the palette data have to be part of the chunk, thats obvious, that is what the palette chunk is for! However, claiming, becuase of this, that is part of what you call header is false information because it is not.
To make a very simply example, which is NOT taken from PNG, just to illustrate what a chunk really is...... So, to put PNG format aside and lets say we have our own format with PALS, IMGS and CEND fields for indicating start of palette data and start of image data... THe file could be something like this:
41424344 // SIGNATURE (ABCD)
PALS // START OF PALETTE DATA CHUNK
0020 // NUMBER OF COLORS (32) (THIS FIELD IS EVEN NOT NECESSARY, JUST READ TO ENDC AND COUNT)
// AND HERE COMES THE PALETTE DATA!
000000 // COLOR 0 IN RGB
001F00 // COLOR 1 IN RGB
002F00
002F10
...
FFFFFF // COLOR 31 IN RGB
// END OF PALETTE DATA
CEND // END OF CHUNK
IMGS // START OF IMAGE CHUNK
0040 // WIDTH OF IMAGE
0020 // HEIGHT OF IMAGE
// START OF IMAGE DATA
AAAA
BBBB
CCCC
DDDD
....
EEEEE
FFFFF
// END OF IMAGE DATA
CEND
In this format there are NO headers and there do not need to be any because it is bulild as chunks that you just read chunk by chunk....
With a header, you would have done something like this:
41424345 // SIGNATURE
000C // SIZE OF HEADER
0040 // WIDTH
0020 // HEIGHT
0020 // NUM OF COLORS
// HERE COMES IMAGE DATA
AAAABBBBCCCCDDDD….EEEEFFFF
// HERE COMES PALETTE DATA
000000001F00002F00002F10...FFFFFF
OR
41424345 // SIGNATURE
000C // SIZE OF HEADER
0040 // WIDTH
0020 // HEIGHT
0020 // NUM OF COLORS
// HERE COMES PALETTE DATA
000000001F00002F00002F10...FFFFFF
// HERE COMES IMAGE DATA
AAAABBBBCCCCDDDD….EEEEFFFF
The last two is the same only which order the palette and image data is is different.. In the last format, opposite to the chunk where you read in chunk by chunk, you read in the HEADER, parse it, calculate where image data is located in file, read it in, and calc where the palette data is in file and read it in….
I have BIG PROBLEMS understanding which part of this things you don’t understand, regardless of all palette formats PNG format uses.
Next thing is compression. I shall admit that using the word ALWAYS might be wrong coz you will of course find exception to this rule. But that is just to pick on things and nothing else. I have done extensive tests both on high and low level whit this things, and on top of that I have extensive knowledge to many compression methods and algorithms, including the one used in PNG, ZIP and JAR….
PNG file itself is very well compressed (except for certain part of the data like the palette etc) and taking one PNG file and ZIP it will give no or almost no compression..
However, when you concat 2 files together, the compression algorithm gets more data and pattern to work on which leads to that it almost in ALL situations will compress this 2 files even more down!
To me, it looks like you have no knowledge at all about compression except for a simple test you have made.
The matter of fact, a compression can even INCREASE the file size instead of REDUCING it, there is not guearantee that a compression method will compress absolutely all kinds of data to a smaller size! Still we ALWAYS get smaller files…
I again mention 2 of my games (which I gave links to above) that has A LOT OF GRAPHICS IN THEM which you will NEVER ABLE TO squeeze in without my method. The graphics is stored optimal for SPACE reduction AND for SPEED on phone. You will never ever be able to squeeze in as much of this graphics no matter how many filmstrips you create… The only time you can beat it or come close to it in this games is by putt ALL graphics into ONE PNG file which is obvious impossible and not a good idea to do…..
I can also mention that a lot of the ppl here in the forum that got my code was suprised over the reduction they got though my method...
Also, it is very important to define the difference between just getting a smaller size of JAR file and getting a smaller while squeezing a lot of things in... I think you think more of the first one and I more of the second one, so in this case you are very much right in what you say... However, the problem is that you focus like on having 5 pictures in a file while I focus on have some animations, objects, background graphics and more into the file, togehter with all kind of files....
|
|
|
|
« Last Edit: May 27, 2004, 02:03:18 pm by calvin-c »
|
Logged
|
|
|
|
calvin-c
Member
Posts: 61
I'm not a llama! I am Ghostinator!
|
Just to clarify the terms I am using, when I say the "header" I am talking about the extra data that does not change format when you alter the actual image information. By that I mean, if I was to alter a picture by adding another frame of the sprite it would not change. (beyond updating the size of the image and that sort of thing). I would consider the tRNS (transparency) chunk or the gAMA chunk as part of the header, maybe you wouldnt, but it isnt really material to our discussion.
By "renderer" I was just refering to any piece of software that has to decode the PNG file and turn it into a displayable image.
Well, your definition of header is very wrong. And of course, the PNG format does not change when you change your image, the DATA does, including the palette data....
And no, tRNS and gAMA chunk is NOT PART OF ANY HEADER, how many times to I have to repeat that there are NO headers in PNG? You are mixing things and just twisting it around....
A format like PNG that uses chunks is ment to be read in chunk by chunk, it has no headers that describe the file itself, it has fields to indicate start and stop of a chunk and similiar things... A file with a header has a STRUCTURE which is the HEADER that describes how the file is build and where to locate the data and how much to expect..... I showed you the difference in post above, if you then do not understand the difference here, I then give up explaining it anymore....
|
|
|
|
|
Logged
|
|
|
|
|
Pages: [1] 2 3 ... 12
|
|
|
|
|
End of story....