iBlox: Technical stuff

NTT DoCoMo's i-mode Java reminds a lot of the MIDP standard, but it has a few important differences. First, it can handle GIF files and transparent pixels. This makes it a lot more useful for implementing arcade-style games. Second, it supports a certain type of music files (called MLD or MFi), which at least in theory should allow high-quality sound effects. Third, there is built-in screen buffering.

Those are the good ones. The main bad difference from MIDP is that DoJa limits the size of the program (including graphics and sound) to 10 kilobytes. This means you can forget about building a DoJa version of Doom or any other game concept from later than roughly 1983. I had to cut a lot of corners just to fit Iceblox in there. The whole game was just under 9 kilobytes without sound. After I'd added one sound effect and three small tunes it filled 99.4% of the quota. I doubt I can squeeze in much more.

I should say a few words about MLD files. It's one of those poorly documented standards hardly used outside Japan. Information in English is virtually non-existent. As far as I know there is only one working application (smdEd) capable of building files in that format and all its menus and help texts are written in Japanese. That makes things a little awkward.

But you can live without sound. (At least I'm grateful when people's cell phones make as little noise as possible.) What's more disturbing is the lack of flexibility when it comes to image management. DoJa doesn't let you draw stuff on offscreen images. DoCoMo probably thought it unimportant, since they already have screen buffering, but this makes it almost impossible to create scrolling backgrounds with any type of interactivity. (Well, if all else fails you can always implement your own graphics routines that draw every single pixel individually. It's just that most real-life cell phones won't have the capacity to run such programs at reasonable speeds.)

Technically there's not much to say about iBlox. You can find the source code on the ingredients page. Due to the lack of offscreen buffering, I decided to put the main game loop directly in the paint method, from where I have direct access to the Graphics object of the Canvas that's visible on the screen. So far I haven't bothered to adjust for display sizes that don't conform to the standard 120x130 pixels. I may have to do something about that later.