J2ME Consistent App Performance

[m0nkeyboy]

Hi,

I am currently working on a J2ME game project (MIDP 2.0) which will be
spanned across multiple mobile devices, ranging from low-end to
high-end in terms of processing power. I was looking for some
tips/advice on techniques/designs to make sure the game executes
consistently across platforms according to its original functional
spec.

With PC based games, I would normally use the well known method of
retrieving the change in system time during each cycle of the main
game loop, then updating the game mechanics appropriate to the value.
Such a method ensures that a faster CPU will still execute the game at
equivalent pace, only more smoothly. Whilst this method can be
implemented in J2ME, there is only such amount of smoothness you can
implement with a limited number of pixels on-screen before you start
wasting paint cycles.

I have thought about using timers in co-junction with screen updates
to always obtain a consistent execution, but I am uncertain if there's
a penalty induced in having the screen updating algorithms seperate
from the main game loop i.e. on a seperate timer thread.

If anyone can offer some tips/advice or even industry experience, I
would be most welcome.

 

[Darryl L. Pierce]

I am currently working on a J2ME game project (MIDP 2.0) which will be
spanned across multiple mobile devices, ranging from low-end to
high-end in terms of processing power. I was looking for some
tips/advice on techniques/designs to make sure the game executes
consistently across platforms according to its original functional
spec.

Good luck. Having done this for several years now, I can tell you that
there's a decided *lack* of consistency between handsets.

With PC based games, I would normally use the well known method of
retrieving the change in system time during each cycle of the main
game loop, then updating the game mechanics appropriate to the value.
Such a method ensures that a faster CPU will still execute the game at
equivalent pace, only more smoothly. Whilst this method can be
implemented in J2ME, there is only such amount of smoothness you can
implement with a limited number of pixels on-screen before you start
wasting paint cycles.

I have thought about using timers in co-junction with screen updates
to always obtain a consistent execution, but I am uncertain if there's
a penalty induced in having the screen updating algorithms seperate
from the main game loop i.e. on a seperate timer thread.

Use simple polling; i.e., at set intervals (and on special events), repaint
the viewport area. If the viewport is already being painted, then don't
queue up the next repaint request, just let it go away. This avoids do a
repaint immediately on top of another. A simple method is to put a boolean
flag at the top of paint:

public void paint(Graphics graphics)
{
if(!painting)
{
painting = true;
// do your magic
// painting = false;
}
}

Use a TimerTask object to do the updates and have it invoke a method (call

If anyone can offer some tips/advice or even industry experience, I
would be most welcome.

Yeah. Don't expect too much from Java handhelds. I've spen the last two
weeks working on just inconsistencies between Samsung, Sanyo and Motorola
handsets and between carriers like T-Mobile and Sprint. Don't go into it
thinking that all handsets are going to work the same, 'cause they don't
and they won't... :/

--
/**
* @author Darryl L. Pierce <[email protected]>
* @see The J2ME FAQ <http://mypage.org/mcpierce/j2mefaq.html>
* @quote "What do you care what others think, Mr. Feynman?"
* @geek echo '$_ = "Jvtu bopuifs Pfsm ibdlfs."; y/a-z/za-y/; print' |
perl
*/