Experimenting with BlackBerry Graphics!
As I said the other day, I started my space explorer game by trying out a bunch of different ways to animate the rocketship flying through space. (I’ve bundled all the source code and resources for the complete example — you can download it here.) I started by just creating a standard MIDlet using the javax.microedition.lcdui.game classes. Here’s what it looks like in the debugger:
In the image, I’ve set the debugger to show memory usage. In this case it’s “lcduispace” — the top process on the list. Next, I decided to try out the technique I described in my earlier post: use the same lcdui game implementation, but write each frame into an image buffer and transfer it from the MIDP Graphics implementation to RIM’s proprietary implementation to display it in a RIMlet. Here it is in the debugger:
This time the relevant process is “spacesprite,” shown at the bottom of the list. You can see that — as expected — it’s using a lot more memory than the other implementation.
Next, I tried doing my own custom implementation of the Sprite and background functionality, using just the RIM graphics classes. This is where I got a bit of a surprise in the debugger:
Again, it’s “spacesprite” (at the bottom of the list). The odd thing is that this implementation doesn’t seem to be using any less memory than the implementation that copies the entire game image from one array to another for every frame of the game. I’m not sure why — I can only guess that perhaps the RIM graphics components all by themselves consume a lot of memory, whereas the array copy is using memory in an efficient way.
It also demonstrates that this kind of memory profiling doesn’t give you all of the information you need. Even though the two implementations are comparable in memory usage, the first one (which copies the image data) was visibly slow on a low-end BlackBerry smartphone, whereas the second implementation ran great on the same device. So even if the array copy isn’t costing too much memory, it must cost a fair amount of processing time.
Then, for fun, I compared these two implementations against two SVG implementations. The first just plays a fixed movie:
And in the second the user can actually drive the rocket ship around the screen:
You can see that these two used a bit more memory, but not too much.
As I’ve said, all of these are experiments that I did while writing my book Learn BlackBerry Games Development. If you’d like to see how these examples work, just download the complete projects here. The README file explains how to compile them (it’s just a standard JDE workspace, so you should be able to open and compile it in any BlackBerry JDE with version >= 4.6.1), and also explains how to switch the “spacesprite” project from one implementation to another. (It’s just a question of which FieldAnimator implementation you instantiate from the SpaceManager class.)
I hope you find this example amusing and instructive. :D