Develop Reference

Best Timer Designs for Java2D video games

I am building a Java2D video game with multiple sprites updating on the screen at once, and was looking for feedback with regard to best way to handle updates via use of Timers.
I was looking for feedback on best way to handle Timer design that would update locations of each Sprite. Currently, the way I have been doing it, is I have one Timer. When it expires, I update the position of each Sprite. I only ever Update Sprite location by 1 pixel, to keep motion smooth. If something was to update slower that then rest of the Sprite, I update it's position say on every 3 or 5th call of a getImage() call (used to get the current icon image of the sprite).
Now with this approach, all updates are dependent on the main timer, and the Sprites sort of update in relation to each other. So if I wanted to speed up the game, I just update the refresh rate of the main timer.
However, I don't know if this is the best approach. Would it be better to put each object on it's own timer, but would that cause other issues? Maybe cause problems for the main paint() method?
Was just looking for feedback on a good design technique for this.

It is possible to keep using one timer while having perfectly smooth animations despite different animation and movement speeds between different sprites. The way to do is by changing your animation and movement of sprites from a tick based approach (move x many pixels per update) to a time based approach (move x many pixels per how much time has elapsed since the last update).
This would mean your Sprite class (or whatever you have), has floating point x and y positions, as well as floating point x and y velocities. To change the speed of a certain sprite, you would change the velocity (which would be pixels/drawingUnitsEtc per millisecond/nanosecond), and won't be limited by how fast you can make the timer run.
However, I don't know if this is the best approach. Would it be better to put each object on it's own timer, but would that cause other issues?
Well if you did use a timer per Sprite that used a different speed, you would run into overhead problems if the timers ran on their own thread, and if the timers were executed on the same thread then you are technically updating your Sprites based on how much time has elapsed but just moving the velocity constant to an integer.
You would also run into a problem of how you can ensure the Timer consistently returns. With separate timers, imagine that there may be two sprites that are walking next to each other in game which want to update at 10ms, but one of them is running at 11ms due to a laggy timer, eventually one will run into the back of the other and turn around and mess up your level design or some other game mechanic. Another one is that they could be two Sprites of the same kind but now one is now an animation frame ahead of the other while that didn't hold true for the first few seconds that you saw them. With a single timer that updates all sprites that operate together you'll get those consistent results.

Assuming you're using java.util.timer's schedule method.
You could use the scheduleAtFixedRate method for cleaner looking code.
Only use one instance of Timer and attach all sprites to it, this keeps all sprites running on the same thread because then you eliminate all forms of concurrent modification, using a new thread for each sprite is way overkill as the threads will be running as fast as possible and maxing out the computer.
You could also simply make something along the lines of a SpriteManager class which extends Thread so that you don't even need to use timer, all sprites will be running as fast as possible but on one thread, it wont put too much load on the cpu but it worth it. Professionally, movement falls under physics so a game would have some physics thread that handles all updates to everything.
You could get even more detailed in the physics thread by realising that throughout the course of gameplay the amount of objects on the thread will change therefore will update less frequently making everything slower (even if it is microseconds). To keep everything running smoothly you can delta scale. Delta scaling simply takes the time it took last frame as a hint to how fast the thread is running and scales the speed of objects up or down appropriately - this is how (most) games don't run slower when the frame rate drops, instead, they look like they jumped to where it would be at that point in time.

JavaFX Smooth Animation

So I have this Timeline custom animation. Node transformation is irrelevant.
final KeyValue kv1 = new KeyValue(angle, HALF_PI, Interpolator.LINEAR);
final KeyValue kv2 = new KeyValue(angle, -HALF_PI, Interpolator.EASE_BOTH);
final KeyFrame kf1 = new KeyFrame(Duration.millis(0), kv1);
final KeyFrame kf2 = new KeyFrame(Duration.millis(500), kv2);
Timeline animation = new Timeline(kf1, kf2);
animation.setRate(1);
My angle variable is modified in this timeline and used in the transformation of a node. As you can see, in this case the rate is 1, and the duration is 500.
To smoothen out the transformation, I'm guessing that the angle should go through several discrete values, which are set by the Interpolator.
Also, I'm not inclined to use a Task to achieve this. Only if the lagginess is severly less than if using the Timeline.
Question:
Which adjustment smoothens out the animation?
A. Low rate + High duration
B. High rate + Low duration
C. ??? Other

The rate is not the frame rate. None of these settings will affect the smoothness of the animation. Using a Task won't help: the Animation API is just a high-level mechanism to update properties of your UI on each frame render, in a way that interpolates values with respect to time. If you put work in a Task, you'll have to update the properties on the FX Application Thread anyway, so you're just replicating the code that's provided for you by the Animation API.
Behind the scenes, JavaFX has a thread which renders frames to the graphical system. The target frame rate is (currently) 60fps. At each frame render, the rendering thread has to synchronize with the JavaFX Application thread, so if you're doing too much work on that thread the frame rate will be below 60fps.
I think Animations work as follows: At each frame render, any running animations will update their associated properties by interpolation along the time line between key frames. The basic algorithm is pretty obvious: look at the current time, subtract the start time, divide by the difference between the end and start times, use that value to update the property.
All the rate does is act as a multiplier for the interpolator. So if you set rate=-1, the animation runs backwards. If you set rate=2, it completes in half the specified duration. If you set rate =-0.5, it completes in twice the specified duration, and runs backwards, etc. The frame rate is still going to be whatever the underlying FX implementation can squeeze out of the system, up to a maximum (in the current implementation) of 60 fps.
Smoothness is basically affected by frame rate (again, the only control you have over this is to make sure you're not flooding the FX Application thread with too much work), along with how much motion you get per frame. Very fast animations will involve something moving considerable distances per frame, and will look less smooth than something that is moving a barely-perceptible distance per frame.

Slick2D game speed changing

I created a game using Swing, and it was a bit unreliable, so I started remaking it using Slick2D game engine and I have encountered issues.
The background of the game rolls across the screen at a certain about of pixels each time the update method is called. This keeps speeding up and slowing down, so the background will move very fast, and then very slow, and keeps fluctuating.
I have tried * by delta (which monitors the refresh rate, I think!) on my value which moves the background, but as this wont give me an exact value I can use to reset the background to the left hand side (2 background move from right to left. left hand one goes to the right at -800 pixels).
What is causing this and how do I overcome it?
Thanks

Here's some reading for you (there's a gamedev-specific StackExchange site, BTW):
https://gamedev.stackexchange.com/questions/6825/time-based-movement-vs-frame-rate-based-movement
https://gamedev.stackexchange.com/questions/1589/fixed-time-step-vs-variable-time-step
One of the most important points in these articles is that things move at a certain rate OVER TIME, not over a certain number of frames. Since frame rates can unpredictably change, time-based and frame-based movement don't wind up being equivalent to one another.
And here's some explanation...
So, your computer and OS are multithreaded, and thus, you can never know what's happening outside your app, and what the overall load is on the machine. Because of this, even when you're in full-screen mode you aren't getting exclusive access to the CPU. So, that's one factor to why things speed up and slow down.
The delta's purpose in Slick2D is to allow you to deal with this speed up/slow down, and allow your app to change its frame rate dynamically so that the perceived movement on the screen doesn't change due to the load on your machine. The delta is not the monitor the refresh rate (which is constant); the delta is the number of milliseconds that have passed since the last call to update.
So how do you use this delta properly? Let's say your background is supposed to move at a rate of 100px/sec. If the delta (on a given call to update) is 33 milliseconds, then the amount you should move your background on this update is 100*(33/1000.0) = 0.033 - so you would move your background by 0.033 pixels. This might seem weird, and you may wonder what the point is of moving <1 pixel, but stick with me.
First, the reason you have to divide it by 1000.0 instead of 1000, is because you want the movement of the delta to give you a floating point number.
You'll notice that the 2D graphics stuff in Slick2D uses float values to track the placement of things. That's because if the delta tells you to move something by 0.033 pixels, you need to move it by 0.033: not 0, and not 1 pixels. Sub-pixel movement is critical to smoothing out the increase/decrease in frame rates as well, because the cumulative effect over several sub-pixel movements is that, when the moment is right, all those little movements add up to a whole pixel, and it's perfectly smooth, resulting in the correct overall movement rate.
You may think that, since your screen resolves images to a given pixel, and not sub-pixel elements, that it doesn't matter if you do sub-pixel movement, but if you convert all your movement tracking to floats, you'll see that the effect you're observing largely goes away.

Limiting frame rate with Thread.sleep()

I am working on a live wallpaper, so no worries about physics collisions. I just want to have as smooth a frame rate as possible, up to a limit of 30fps to conserve battery.
To do this, at the end of the loop, and I measure time since the beginning of that loop. If the frame took less than 33ms, I use Thread.sleep() to sleep the number of ms to get up to 33.
However, I know that Thread.sleep() is not super accurate, and is likely to sleep longer than I ask for. I don't know by how much.
Is there a different method I can use that will provide a more even rate?

Yes, Thread.sleep() is not super-accurate.
You can try to use adaptive strategy -- do not just sleep(remaining), but have a variable long lastDelay, and, each time you observe too high frame rate you increase it, and Thread.sleep(lastDelay), each time you observe too low frame rate -- you decrease it. So after second or about your code find right number...
By the way, the Thread.sleep is not the best way to limit frame rate. Using of Timer is more promising -- but you'll have same problem, since Timer accuracy is likely the same, as Thread.sleep()

I'm not 100% sure about this, but have you tried using a Timer (http://developer.android.com/reference/java/util/Timer.html) and TimerTask (http://developer.android.com/reference/java/util/TimerTask.html)? You should be able to use that to schedule your updates.

30fps does not look smooth at all in a canvas animation. One should always try to keep about 60fps and then adjust the speed of sprite movement according to the screen density. Thread.sleep() is accurate enough for wallpaper or 2d game animations, one cannot notice the difference if the fps goes up or down just few frames.
Or use the so-called frame-rate-independed-movement where
deltaTime = timeNow - prevFrameTime; //for 60fps this should be ~0.016s
object.x += speedX * deltaTime;

Is it impossible to make an Android game stutter-free? I am going crazy here

I have been working on an Android game for the past 6 months or so, and have posted on here several times about various lag issues that I cannot get rid of.
I ended up grabbing the LunarLander example and stripping it down to its very core components to see if I could make anything at all that doesn't lag. All it really does is change the amount the canvas is translated each frame, and then draw a background onto the canvas. EVEN THIS, about as simple as you can get for a surfaceView application - stutters...
My game is a scrolling game where you continuously move up the screen (think of a flying game), but the way I am currently doing the background results in constant stuttering every second or so for about 50-100ms. This isn't game breaking, but it is very distracting and makes the game seem as if it was programmed by a complete moron (though I am starting to suspect this might be the case).
No, it is not the garbage collector, there are no new objects being created at all during the game's run loop, and the GC barely ever runs while my game is running.
I am practically tearing my hair out with frustration. I have spent over 40 hours just trying to get rid of the lag on this simple application example over the past week alone and it is driving me crazy. How can an application as simple as the one I have linked possibly have lag issues? You wouldn't think a scrolling background could get much simpler than that...
NOTE: This demonstration constantly gets about 60fps on my phone (A Motorola Milestone). Uncomment the FPS code in the example to see the FPS.
TL;DR: Extraordinarily simple program that is just a scrolling background shows stuttering. Please have a look...
Link to download simple stuttering example based off the LunarLander example:
http://dl.dropbox.com/u/4972001/LunarLander.rar

I have downloaded the RAR file with your scrolling background (looks like a grassy field), and installed it on my Motorolla Droid.
I can perceive no stuttering as it scrolls, I've watched it for well over a minute.
Based on your description I'd wager the Milestone hardware/platform has some weird video drawing/timing issue.
Perhaps the explanation is something along the lines of this: The Milestone's diplay refreshes at 60 Hz (just picking a number here, I don't know what it really is), and your frame rate is just slightly off that - say 63 or 57 Hz ... is it not conceivable that approx once a second the timing of your draw, and the timing of the hardware display update mismatch just enough that the background doesn't get a re-draw that one time, and has to wait until your next frame? And that occasionally the timing lines up just enough that you might miss the timing of two or three draws in a row (depending upon how far off your frame-cycle is from the actual screen refresh cycle).
EDIT: Actually, I watched it for another minute I did did see one very short (just perceivable) stutter.

I've been having this same lag issue in my game (and I did something similar you did to LunarLander loop and reached a similar conclusion). If you open logcat, you see can that the lags happens together with GC_FOR_MALLOC (50 ... 100 ms, our lags 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'll try to reduce the use of garbage collector and see if I achieve a lagless condition hehehe =]

Have you considered jhouse's suggestion of a minimum frame time?
I am using that idea on my current project. I expect phone hardware to have made considerable improvements in the next year or two so this will stop your game becoming unplayable in future.
My code is 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 sleep exception handling from a forum (probably this one!) but have never seen the exception thrown