While checking the logs I came across “j2me png manipulation”. So, a few tips that you probably have heard before:

  • The less, the merrier. If you can combine the images in a single file, you save JAR space.
  • Indexed PNGs are your friend. You can do a lot with 256 colors (hell, I grew up on the Amiga 500 that had 32 colors for gaming).  If you have a lot of  black an white graphics, MAYBE you can save some space by combining them  and using indexing and keep your colored ones separate,but this is on a case by case basis.
  • Try a few different PNG encoders. Their mileage may vary
  • Another bonus is that if you have few (or even better one!) PNG file, you can encrypt it (most of the encryption I have seen is XOR but ok, that will stop the casual thief), decrypt it in memory (which in most Nokia S40 phones is more than you have available for your filespace), hope the garbage collector does its job ( calling gc() does not guarantees execution and you might be a victim of memory fragmentation but most of the time works ok).
  • Since reading from the JAR is slow and space is extremely limited anyway, the evident benefit of keeping your assets in a single file (like most PC/console games) is not of concern.
  • If the API has extensions for mirroring, by all means use them. Once again, you trade off JAR space over RAM.

A J2ME quick tip

September 17, 2007

In Java bytes, shorts, ints and longs are all considered signed. The only unsigned type is the 16-bit char. To use the sign bit as an additional data bit you have to promote to the next bigger data type with sign extension then mask off the high order bits. i.e. To get the effect of an 16-bit unsigned:

int i1 = inputstream.read() & 0xff;

So, if you see something like the above, don’t let it suss you, it justs reads an unsigned int (i.e. you can see it often in PNG manipulation code.