Optimizing Game Size

[DevelopmentTeam]

List some good ways to optimize the game size in J2ME. As every game developer has to know such tricks to manage the game to be run on most mobile models.

[DevelopmentTeam]

Personally I find that proguard has been better than retroguard for our applications and games.

Also you will want to look at optimizing your graphics (.png) to get them as small as possible or even put multiple images in one .png (saves having multiple palette's for multiple .pngs) often known as filmstrip images.

Shockingly, some of the best ways of getting better code size is basically to ignore most of the java object oriented ideas... dont use getter and setter methods, directly modify the member variables instead, things like that.

[DevelopmentTeam]

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

[DevelopmentTeam]

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...

[DevelopmentTeam]

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..

[DevelopmentTeam]

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

[DevelopmentTeam]

You can also write a tool to convert your sprite strips into raw pallete/bitmap data, then re-convert to PNG on the phone (look up the PNG RFC for info on how to encode PNGs).

This has three big advantages:
1) Your image is only compressed once (by jar, or kzip, or whatever you use to package your jarfile - kzip works best, btw) instead of being compressed as a PNG first and then being compressed again during packaging (by jar etc) - the second compression step actually increases the total jar size, unless you are using a crappy imaging program.
2) If you are going to port the game to devices that have proprietary (or MIDP 2.0) drawPixels methods you can very easily just convert to ARGB on the device, and apply transforms for sprite flipping.
3) If you are going to port the game to MIDP 1.0 devices, and you need to flip sprites (or tiles, even) you can do this on the device too (e.g. by reversing the vertical pixels in the data before/while encoding as PNG), hence cutting your spritestrips in half (and possibly reducing your in-jar tilecount, if your tilemaps have lots of flipped tiles).

It also has the (small?) advantage that it makes it extremely simple to perform pallete changes on the device, e.g. swapping all red pixels for blue pixels.

[silvercoder]

Compressing the PNG files too much makes the picture quality poor is my idea, how do you feel?

[DevelopmentTeam]

There are many loss-less compression techniques with which you can do some good stuff. there are a lot softwares available online for PNG compression.

[lararefaeli]

Hello
Buddy its very important and useful thing for me because I always loved to play games. This post is really a useful for me to do optimising game size.Thank you for this post,and in future also send me this kind of post .