1. Does the 100k limit include art assets that are included in the JAR? I.e. does the definition of the midlet include all associated data?
2. If I am starting with .png files, can anyone suggest how I might get the smallest sizes out of these images. I have seen quotes on sizes for a sprite being around 12K - but if you have a game with a number of tile sets and sprites this will obviously blow out quite considerably.
Cheers.
Motorola V525 and asset sizes
Author
Hi all,
I am looking at doing some game dev work on the Motorola V525/V500 and of course the rest of the phones in that series (300/600). Reading through the docs Motorola have a recommended max size on a midlet of 100k - now bare in mind I am new to J2ME so these questions may sound stupid.
1. Does the 100k limit include art assets that are included in the JAR? I.e. does the definition of the midlet include all associated data?
2. If I am starting with .png files, can anyone suggest how I might get the smallest sizes out of these images. I have seen quotes on sizes for a sprite being around 12K - but if you have a game with a number of tile sets and sprites this will obviously blow out quite considerably.
Cheers.
1. Does the 100k limit include art assets that are included in the JAR? I.e. does the definition of the midlet include all associated data?
2. If I am starting with .png files, can anyone suggest how I might get the smallest sizes out of these images. I have seen quotes on sizes for a sprite being around 12K - but if you have a game with a number of tile sets and sprites this will obviously blow out quite considerably.
Cheers.
Hi!
This size includes all - code, sound, graphics. Sometimes it''s hard to put all into the jar file - nokia series 40 has a limit of 64 kb. You have to fight for each byte :-)
But you don''t really need 12k per sprite. It''s important that you try to reduce the color depth of your png files. Mostly it''s enough to have 16 colors in an image. But for sure you can use different color sets in different images. Also try to use as few different images as possible, because each image has some overhead in the jar file.
McMc
This size includes all - code, sound, graphics. Sometimes it''s hard to put all into the jar file - nokia series 40 has a limit of 64 kb. You have to fight for each byte :-)
But you don''t really need 12k per sprite. It''s important that you try to reduce the color depth of your png files. Mostly it''s enough to have 16 colors in an image. But for sure you can use different color sets in different images. Also try to use as few different images as possible, because each image has some overhead in the jar file.
McMc
Author
Thanks for your reply - makes good sense.
This kind of programming sounds like the good ol'' days. I think I have been spoiled by 1024MB on my PC!
This kind of programming sounds like the good ol'' days. I think I have been spoiled by 1024MB on my PC!
The midlet size is the size of the Jar file which contains all of your application''s code, maps, textures, other resources etc. Naturally, the midlet size is also the download size, when your customer is downloading the application OTA (over the air) to their phone.
Since a jar file is essentially a zip file, the code and other data files are compressed, not so much the textures since these are compressed anyway in png format. Use of a code obfuscator is also recommended to reduce the size that the code takes up in the jar.
This midlet size is not necessarily the size of the application once it is installed onto the phone. Installed size is usually phone manufacturer dependent, but Motorola phones tend to decompress the jar as they install, thus taking up more space. Therefore if you have over 100K of free space on your phone, this doesn''t mean you can install a 100K midlet. For example our midlet (the jar consists mainly of code) which is 32K in size takes up about 59K when installed on Motorola phones.
Another way of reducing midlet size is to use procedural textures, textures you generate at runtime using code, rather than prerendered textures you store in the jar.
Since a jar file is essentially a zip file, the code and other data files are compressed, not so much the textures since these are compressed anyway in png format. Use of a code obfuscator is also recommended to reduce the size that the code takes up in the jar.
This midlet size is not necessarily the size of the application once it is installed onto the phone. Installed size is usually phone manufacturer dependent, but Motorola phones tend to decompress the jar as they install, thus taking up more space. Therefore if you have over 100K of free space on your phone, this doesn''t mean you can install a 100K midlet. For example our midlet (the jar consists mainly of code) which is 32K in size takes up about 59K when installed on Motorola phones.
Another way of reducing midlet size is to use procedural textures, textures you generate at runtime using code, rather than prerendered textures you store in the jar.
Author
quote:
Another way of reducing midlet size is to use procedural textures, textures you generate at runtime using code, rather than prerendered textures you store in the jar.
An excellent idea - thanks.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement