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
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.