MIDP-Man: Technical stuff
If you have tested Sun's reference implementation of MIDP, you should be
familiar with how to run MIDlets contained in JAR files. Let's say you
installed the midp-fcs directory in c:\ on a Windows PC. Then
you use the DOS console and, while standing in the same directory where
you keep midpman.jar, you type
c:\midp-fcs\bin\midp -classpath c:\midp-fcs\classes;
You may have noticed that the background in MIDP-Man reminds a lot of the
classic arcade game Pac-Man. That's because I used the same graphics, scaled
down to exactly 50% and cleaned up a bit.
On the left is the original and on the right the maze I use in my game. I
had to make the blue quite a bit brighter, or it would have completely
blended with the black background. I also made the dots bigger and turned
the energizers white instead of pink like regular dots. They blink in the
real Pac-Man, to stand out better, but I didn't want to waste computer power
on that type of effect.
The scrolling background seemed necessary, because even at 50% the maze is
still 112 by 124 pixels, which doesn't fit the 96x101 drawable area of Sun's
MIDP phone -- especially when I need some additional space for
the score and level numbers. I decided it was better to
keep the original layout than to shrink things even further or remove parts. Also,
if future devices don't use exactly the same screen size, the game might not look
good anyway. Of course, not being able to see the whole maze makes the game more
difficult, so I removed one of the four ghosts to compensate.
Why MIDP stinks as a game platform
Three words: no image transparency.
Think about it. All mobile objects need to be rectangular, or they will look
awful when drawn against other objects or a background with more than one color.
In MIDP-Man, the graphics are so small that you barely notice the problem.
In addition, the ghosts are almost rectangular anyway and MIDP-Man
clears the background under himself (by eating the dots) as he moves along.
There is no Graphics.copyArea method. This means you can't keep all your
graphics data in the same buffer.
There is no way to extract small regions of image data from a larger image, other
than creating small images and drawing the bigger image on top of them. Then each
little image needs its own Graphics object, which will most likely never be
used again. This seems like a big waste of time and memory. In MIDP-Man I ended
up saving twenty-eight images into separate files, most of which were
only 8x8 pixels or smaller.