Is it impossible to make an Android game carefree? I'm going crazy here

Question

I have been working on an Android game for the past 6 months or so, and have written several times here about various latency issues that I cannot get rid of.

I ended up grabbing the LunarLander example and splitting it into its main components to see if I can do anything at all that doesn't fall behind. All he really does is change the amount that the canvas translates every frame, and then draw a background on the canvas. EVEN THIS, about as simple as you can get for a surfaceView application - it stutters ...

My game is a scrolling game in which you are constantly moving around the screen (think of a flying game), but the way I am doing the background effect is constantly stuttering every second for about 50-100 ms. This is not a game, but it is very distracting and makes the game look as if it had been programmed with a complete moron (although I am beginning to suspect that this may be so).

No, this is not a garbage collector, no new objects are created at all during the game launch cycle, and GC almost never starts during my game.

I practically tear my hair away from disappointment. I spent more than 40 hours just trying to get the backlog of this simple example application in the last week, and it drives me crazy. How can an application just be related to what I have connected? You would not think that a scrolling background could become much easier ...

NOTE. This demo constantly gets about 60 frames per second on my phone (Motorola Milestone). Uncomment the FPS code in the example to see the FPS.

TL; DR: An unusually simple program, which is just a scrolling background, shows stuttering. Please take a look ...

Download link for a simple stutter example based on the LunarLander example: http://dl.dropbox.com/u/4972001/LunarLander.rar

Answer 1

I downloaded the RAR file with your scroll background (looks like a grassy field) and installed it on my Motorolla Droid.

I do not see any stutter, when it scrolls, I watched him for more than a minute.

Based on your description, I would bet on the Milestone hardware / platform hardware.

Perhaps the explanation is something like this: The Milestone diplay is updated at a frequency of 60 Hz (just select the number here, I don’t know what it really is), and the frame rate is a little from this - say, 63 or 57 Hz. ..it is not possible that approximately once per second the time of your draw and the time of the mismatch of the update of the hardware display are enough for the background to not receive a repeated draw at a time and wait until the next frame? And from time to time, this synchronization line is enough for you to skip the time of two or three draws in a row (depending on how far from your frame cycle is from the actual screen refresh cycle).

EDIT: Actually, I watched it for another minute, I saw a very short (just perceived) stutter.

Answer 2

I had the same problem with the delay in my game (and I did something similar with the LunarLander loop and made a similar conclusion). If you open logcat, you will see that delays occur along with GC_FOR_MALLOC (50 ... 100 ms, our delay time). I suspected the source of the problem was the garbage collector. Then I found this post:

http://fanitis.com/2011/02/09/android-game-performance-garbage-collection/

I will try to reduce the use of the garbage collector and see if I have reached the indifferent state hehehe =]

Answer 3

Have you considered the jhouse suggestion for minimum frame time?

I use this idea in my current project. I expect the phone hardware to improve significantly in the next year or two, so this will stop your game unplayable in the future.

My code looks like this:

long frameTime; // calculate time to process this frame while (mSurfaceAvailable) { // ensure minimum frame time can be calculated frameTime = SystemClock.uptimeMillis(); // code to move everything and display a single frame goes here // ensure minimum frame time frameTime = SystemClock.uptimeMillis() - frameTime; if (frameTime < 0) frameTime = MIN_FRAME_TIME; // cope with wrap-around of uptimeMillis if (frameTime < MIN_FRAME_TIME) { /*DEBUG*/Log.v(this.getClass().getName(), "run: Sleeping for "+(MIN_FRAME_TIME - frameTime)+"ms"); try { sleep(MIN_FRAME_TIME - frameTime); } catch (InterruptedException e) { /*DEBUG*/Log.i(this.getClass().getName(), "run: Thread sleep was interrupted (not a problem)"); } } else { if (frameTime != MIN_FRAME_TIME) { /*DEBUG*/Log.v(this.getClass().getName(), "run: System is too slow, by "+(frameTime - MIN_FRAME_TIME)+"ms per frame"); } } 

I got the exception handling for sleep from the forum (maybe this!), But I never saw the exception being thrown