Show HN: Awesome J2ME

I did J2ME development in the 64KB JAR era.

I can still remember setting up palette swapping (inspired by retro consoles, but still a common contemporary idea e.g. on GBA) by loading the byte data of PNG resources into an array and locating and replacing the PLTE chunk before handing it off to the MIDP image loader. Always wondered if anyone else had picked up the trick. I can also remember people suggesting on Nokia in particular to just store raw bitmaps (since they'd be compressed in the JAR anyway) with their API and that this was saving tons of space for some people... later I found out that one of these reports came from someone who had started out with individual image files for 12x12 tiles that had a full 256-entry PLTE (i.e., more colour entries than pixels).

I also remember a device-specific bug where doing something like `x[y+1]`, where `y` was a static byte set to -1, would produce an `IndexOutOfBoundsError` claiming the index used was -256. I assume this was some threading issue in the Java implementation, where the value would be loaded into a register and then the sign-extension would somehow affect the register after the increment. I only ever reproduced it with static class members, I think (but it did also happen with shorts).

That's just good old fashioned hacking. Wasn't this more a reflection of the various platforms' limited memory resources, and not really anything to do with J2ME?

Gosh! The memories! No floating point!

It was fun to build small apps and felt like magic at the time.

IIRC FileInputStream objects in J2ME can only seek (skip) forward. If you might need data from before your current position, you can either reopen the file, or cache the data as you go (if you have the ram). Reverse seek wasn't added until Java 1.4, and J2ME is based on Java 1.3

I used to run MeBoy under Sony w200 phone. With some frameskip Zelda for the GB was somehow playable. Pokémon ran well enough OFC.