i do not love siemens: performance problems

[Serethos]

i have started a similar thread some month ago but perhaps i can describe the problem now more detailed:

my board-like game (only some animations constantly running, no much action) runs very well on all phones except
the siemens series.

i focuse on the stronger phone C65:
- the key input reacts with big delay, sometimes not at all
- there ist constantly a silent 'beep' sound. i really dont know what it is indicating
i heard something similar on the MC60 but not permanent, only after delayed key events

what i have tried so far:
- i think i have reduced object creation and garbage collecting as much as possible
- in general im using image strips and one big background image, but i alos tried bg-tiles and single frames for animation


i would be happy to get some hints or known issues about
siemens devices!

[shmoove]

Have you tried messing around with how the game loop is run?
* Using a while as opposed to looping with callSerially().
* Experimenting with different sleep times.
* Using wait instead of sleep(), or maybe just yield() for the pauses.

I can't give out any specific info on the C65, but these things often have drastic effects on performance.

shmoove

[Serethos]

i experimented with various sleep times (setting it "on-the-fly" via buttons =) and different ways to pause the animation thread. the sleep() method worked best with my experiences.

but please explain me this suggestion:

* Using a while as opposed to looping with callSerially().

i think i have some problems understanding your idea !?

Games published by our own members! Check 'em out!

[shmoove]

You can run a game thread the usual way:

1   2   3   4   5   6   7   8   9   10   11   12

public void run() {   while (running) {     tick();     render();     waitForAWhile();   } } void start() {   running = true;   Thread t = new Thread(this);   t.start(); }

Or you can use the Display.callSerially() method to synchronize the game loop with input and output events. callSerially takes a Runnable object and places it on the event cue (together with repaint requests and key events), and then executes it's run() method. So you can also run game loop like this:

1   2   3   4   5   6   7   8   9   10   11

Display display; public void run() {   tick();   render();   waitForAWhile();   if (running) display.callSerially(this); } void start() {   running = true;   display.callSerially(this); }

On some phones this gives much smoother animation (on others it doesn't make a difference, and sometimes and can work much worse).

shmoove

[Serethos]

ah ok, i really didnt know that. now im richer in knowledge  

some additional infos with my testing:
i experimented a second time with the ticktime and got a result:
if i slow down the fps to very bad 3-5 fps (throttled through a n unconditional Thread.sleep(ticktime)) i get the siemens phones to react much better on key events and to avoid this annoying beep sound.
my first thought was again that siemens has trouble painting bigger amounts of gfx data in 'short' times. but removing nearly all gfx didnt bring better results.
but i cant believe that im forced to accept such low fps even on better devices like the cx65.

[shmoove]

I have a feeling that the beeping is from the key event queue getting filled up. Kinda like when my old computer was stalling with some processing and I would keep on typing without giving it a chance to react to keypresses, after a while there would be a beep for every keystroke because the input buffer was full.

It sounds that changing the threading implementation to use callSerially() might really pay off on this device since this way your game thread is synchronized with the rest of the events and it will block their thread less.

shmoove

[Serethos]

MUAHAHAHAAHA ...
after month of testing the oddest routines, changing gfx and lots of code snippets i found the soulution.

my run method calls the two important methods, named cycle() and paint() for game logic and rendering. if i put after each call a simple Thread.yield() it runs perfectly.
sure you can assume that this is so easy that i have come to this solution much earlier, but!

i tried to replace sleep(..) with a time controled loop of only yields. i put a yield before and right after the sleep call. i raised the ticktime up to 300ms. all that has not the effect like this two stupid yields !

how can it be that a very long sleep can not replace a simple and much shorter yield !?!?!