Hmmm... not sure what you mean by not doing work in loops... if he's using the "two thread" model, then I'd everything I possibly can inside a loop.
Code:
public void run() {
while (state != STATE_EXIT) {
long startTime = System.currentTimeMillis();
// game logic
int nextState;
switch (state) {
case STATE_LOADING_PLAYER_IMAGE:
playerImage = loadImage("/player.png");
nextState = STATE_LOADING_ENEMY_IMAGES;
break;
}
// allow screen to update
repaint();
serviceRepaints();
state = nextState;
// regulate frame rate
long endTime = System.currentTimeMillis();
long elapsed = endTime - startTime;
long sleepTime = FRAME_DURATION - elapsedTime;
if (sleepTime < MIN_SLEEP) {
sleepTime = MIN_SLEEP;
}
try {
Thread.sleep(sleepTime);
} catch (InterruptedException e) {
// ignore: doesn't happen on CLDC-1.0 anyway
}
}
}
In this model, putting repaint(), or any game logic, inside the keyPressed() method means you will have two threads updating the game state in parallel, and screen updates occuring while the game state is only half updated. I have seen many games with game logic in the keyPressed() method, and they always prove problematic in porting, even though they may behave fine on the original device (usually a Nokia) they were written for.