Thursday, March 23, 2006
Vicious Circle
Once again the problem from HEAP memory and the JAR file (J2ME) size with the resources. One of the biggest problems we have every day with the most limited handsets (mobile phones), is that compressing our files to the maximum is not enough. This is because although we can resize our JAR files for solving our JAR limit we found that our resource will be decompressed in our HEAP space and we reach the top of our HEAP too early.
The real problem with the memory from mobile phones is that we never have the expected amount. You can read that you have n KB available from HEAP, but we never think about decompressing our images (PNG...) as bitmaps in memory, that our jar file need to be decompressed, that our java classes need to be loaded into memory and then when we run our application we found that we are using more memory than expected from our game logic.
At the end, the solution is a question of balance. If you reduce the size of our JAR package compressing to the maximum and you don’t think about content, when you decompress you will find HEAP limitations. The best way is to think about it from the beginning, with all resources and the order of creating and destroying them in memory.
I am going to enumerate some rules (I think important) that we use when we evaluate the HEAP that we are using with our resources and its working for us with good results:
1 – Never think in the top of the HEAP memory specified by the manufacturer. You will have always less memory in the handset than the expected. This can be because of firmware bugs or by internal use from manufacturer implementation.
2 – Your images prepared for painting will use the amount of memory from the formula:
Image (KB) = (WIDTH (pixels) x HEIGHT (pixels) x COLOURS (bytes)) / 1024
For an image of 64 x 64 in a screen of 65.535 colours (16 bits = 2 bytes) we will have
(64 x 64 x 2) / 1024 = 8 KB from HEAP.
Try to optimize the size of the image for your HEAP and the number of colours in the image for your JAR file.
3 – The code of your classes could have to live in the HEAP. Remember that using a class need of its bytecode in somewhere. Usually the place of storing the bytecode of the class in use will be the HEAP. Think that decompressed classes will use the HEAP when you use them. A good solution could be to have a specific class for one use methods, like loading and preparing. When you finished using those methods, you can set your objects to null for some mobile phones to remove the bytecode from the HEAP.
4 – If you think that your JAR file is not going to be decompressed in the HEAP, you are totally mistaken. Some mobile phones will decompress your HAR file in your HEAP and if you have compressed to the maximum, you will find not too much available HEAP. Try to balance the content from your JAR file with the necessary HEAP from your game. No balancing is equal to enter in a vicious circle between JAR and HEAP. Other solution is to implement a small decompressor for some of your resources (no classes, no images and no sounds), allowing you to maintain them compressed into memory. Balancing is essential.
5 – Most of the resources and classes have headers that need HEAP and JAR space. The lower number of classes and resources files, the lower space you will use. Beware of creating all of your game logic in one unique class or inserting all of your graphics in one image, because using a too big resource or class could reach the top of the HEAP. Again, try to balance between the number of classes and the number of resources files. This is more complex because we need to analyze the game logic for making the right division, but will make easy working in small mobile phones.
6 – Adapt the layout of your graphics inside of your image resources. It doesn’t take up into memory using a more vertical image that a horizontal or a quad image. From a long time ago (old 8 bits games) we know that the layout of the graphics in the images cab use more or less HEAP memory. Sometimes setting your sprites frames into vertical layout (one column) could improve you memory usage. Experiment until you find the best layout and combine it with your number of resource images balancing.
7 – Try to use image optimizing tools like PNGOUT, JAR file optimizing tools like JARG (Java Archive Grinder) or KZIP. With these tools you will improve your JAR file size, but remember balancing with your HEAP space. Using obfuscator tools is mandatory for improving JAR files size and bytecode HEAP usage. Some obfuscators optimize the size better than others but some mobile phones don’t like big classes with some kinds of obfuscation. Try to use the more adequate obfuscator in each case.
8 – Preloading of images and sounds can accelerate the execution of your games but can also limit the game logic to store in your HEAP. Balance your resources cached into memory with your game logic. Although not all of your resources will be cached, you can make some effects during the game play for the user not to fell the loading and preparing times. Load and unload resources from HEAP memory and try to use some tricks during the game for the user. Loading from JAR files is slow and having images (bitmap) into memory prepared for painting is expensive for the HEAP. A good idea is having some image files (PNG...) into memory arrays like if you have a cache, and when you need them, prepare them as bitmaps for painting. This is faster than getting them from jar file and its size in the HEAP memory is the same as the image file compressed in their original format. Same can be done with some audio resources.
9 – Your mobile phone has a persistent memory and in the case of J2ME we can save data using the Record Store. In some cases if your resources and logic don’t fit in your JAR file limit, you can try to add the game logic to the JAR file and initializing the game, the game can download some of the resources storing them into the Record Store. We are using mobile phones that can connect with Internet and we must use these capabilities for improving our games. Gradually the players will assimilate that mobile applications need of connecting to the Internet for updating and others. Creating some Record Store can be a slow action but reading and writing records in a Record Store is enough fast. Order your contents in a way that you can load them without strange feelings, like stopping the action, to the player. You could create cool games in limited mobile phones. Remember that there are some limits for Record Store from a MIDlet.
10 – Balancing and designing. Everything is a question of balancing and depends on how we design our game. If we are able to design basing in the balance between JAR and HEAP, we will obtain to insert a big quantity of contents and we will create levels and screens very complete for the player. When you are making a game for a mobile phone, you must think always in the balance for avoiding headaches. This rule is valid for all platforms because at the end is always a problem of capabilities. The more content, the more balancing work we need.
The real problem with the memory from mobile phones is that we never have the expected amount. You can read that you have n KB available from HEAP, but we never think about decompressing our images (PNG...) as bitmaps in memory, that our jar file need to be decompressed, that our java classes need to be loaded into memory and then when we run our application we found that we are using more memory than expected from our game logic.
At the end, the solution is a question of balance. If you reduce the size of our JAR package compressing to the maximum and you don’t think about content, when you decompress you will find HEAP limitations. The best way is to think about it from the beginning, with all resources and the order of creating and destroying them in memory.
I am going to enumerate some rules (I think important) that we use when we evaluate the HEAP that we are using with our resources and its working for us with good results:
1 – Never think in the top of the HEAP memory specified by the manufacturer. You will have always less memory in the handset than the expected. This can be because of firmware bugs or by internal use from manufacturer implementation.
2 – Your images prepared for painting will use the amount of memory from the formula:
Image (KB) = (WIDTH (pixels) x HEIGHT (pixels) x COLOURS (bytes)) / 1024
For an image of 64 x 64 in a screen of 65.535 colours (16 bits = 2 bytes) we will have
(64 x 64 x 2) / 1024 = 8 KB from HEAP.
Try to optimize the size of the image for your HEAP and the number of colours in the image for your JAR file.
3 – The code of your classes could have to live in the HEAP. Remember that using a class need of its bytecode in somewhere. Usually the place of storing the bytecode of the class in use will be the HEAP. Think that decompressed classes will use the HEAP when you use them. A good solution could be to have a specific class for one use methods, like loading and preparing. When you finished using those methods, you can set your objects to null for some mobile phones to remove the bytecode from the HEAP.
4 – If you think that your JAR file is not going to be decompressed in the HEAP, you are totally mistaken. Some mobile phones will decompress your HAR file in your HEAP and if you have compressed to the maximum, you will find not too much available HEAP. Try to balance the content from your JAR file with the necessary HEAP from your game. No balancing is equal to enter in a vicious circle between JAR and HEAP. Other solution is to implement a small decompressor for some of your resources (no classes, no images and no sounds), allowing you to maintain them compressed into memory. Balancing is essential.
5 – Most of the resources and classes have headers that need HEAP and JAR space. The lower number of classes and resources files, the lower space you will use. Beware of creating all of your game logic in one unique class or inserting all of your graphics in one image, because using a too big resource or class could reach the top of the HEAP. Again, try to balance between the number of classes and the number of resources files. This is more complex because we need to analyze the game logic for making the right division, but will make easy working in small mobile phones.
6 – Adapt the layout of your graphics inside of your image resources. It doesn’t take up into memory using a more vertical image that a horizontal or a quad image. From a long time ago (old 8 bits games) we know that the layout of the graphics in the images cab use more or less HEAP memory. Sometimes setting your sprites frames into vertical layout (one column) could improve you memory usage. Experiment until you find the best layout and combine it with your number of resource images balancing.
7 – Try to use image optimizing tools like PNGOUT, JAR file optimizing tools like JARG (Java Archive Grinder) or KZIP. With these tools you will improve your JAR file size, but remember balancing with your HEAP space. Using obfuscator tools is mandatory for improving JAR files size and bytecode HEAP usage. Some obfuscators optimize the size better than others but some mobile phones don’t like big classes with some kinds of obfuscation. Try to use the more adequate obfuscator in each case.
8 – Preloading of images and sounds can accelerate the execution of your games but can also limit the game logic to store in your HEAP. Balance your resources cached into memory with your game logic. Although not all of your resources will be cached, you can make some effects during the game play for the user not to fell the loading and preparing times. Load and unload resources from HEAP memory and try to use some tricks during the game for the user. Loading from JAR files is slow and having images (bitmap) into memory prepared for painting is expensive for the HEAP. A good idea is having some image files (PNG...) into memory arrays like if you have a cache, and when you need them, prepare them as bitmaps for painting. This is faster than getting them from jar file and its size in the HEAP memory is the same as the image file compressed in their original format. Same can be done with some audio resources.
9 – Your mobile phone has a persistent memory and in the case of J2ME we can save data using the Record Store. In some cases if your resources and logic don’t fit in your JAR file limit, you can try to add the game logic to the JAR file and initializing the game, the game can download some of the resources storing them into the Record Store. We are using mobile phones that can connect with Internet and we must use these capabilities for improving our games. Gradually the players will assimilate that mobile applications need of connecting to the Internet for updating and others. Creating some Record Store can be a slow action but reading and writing records in a Record Store is enough fast. Order your contents in a way that you can load them without strange feelings, like stopping the action, to the player. You could create cool games in limited mobile phones. Remember that there are some limits for Record Store from a MIDlet.
10 – Balancing and designing. Everything is a question of balancing and depends on how we design our game. If we are able to design basing in the balance between JAR and HEAP, we will obtain to insert a big quantity of contents and we will create levels and screens very complete for the player. When you are making a game for a mobile phone, you must think always in the balance for avoiding headaches. This rule is valid for all platforms because at the end is always a problem of capabilities. The more content, the more balancing work we need.
posted by Jaime Lanchares : 1:17 pm
