I've seen a lot of different game loops, and before implementing anything complicated I decided to start with a capped 60 FPS. My run method looks like this in my game thread:

 * Fixed Frames Per Second = 60
public void run() {
    new Timer().schedule(new TimerTask() {
        public void run() {
    }, 0, 17);

The stage is a canvas, and the render method looks like this:

public void render() {

    BufferStrategy bufferedStrategy = this.getBufferStrategy();

    if (bufferedStrategy == null) {

    Graphics2D graphics2d = (Graphics2D) bufferedStrategy.getDrawGraphics();

    for (Actor actor : actors) {
        graphics2d.fillRect(0, 0, 600, 600);
        graphics2d.drawImage(actor.getDrawableImage(), actor.getX(), actor.getY(), 32, 32, this);


The only "actor" sprite is 32x32, is currently moving 1 pixel at a time, and is too slow. So I bumped it to move anywhere from 2-4 pixels at a time across the stage, but now it is chunky. Is this related to my implementation or specific to Java 2D? The movement happens while the user presses one of the arrow keys.

  • \$\begingroup\$ How come you are drawing a white rectangle for each actor? And have you actually tried displaying the fps? \$\endgroup\$ – Fault Dec 4 '13 at 19:10
  • \$\begingroup\$ I don't currently have a tile system, so the sprite will ghost if I don't provide some background fill. Are you saying the FPS is not correct? \$\endgroup\$ – user6214 Dec 4 '13 at 19:16
  • \$\begingroup\$ You need to provide a background, sure, but the code should be outside of the <code>for (Actor actor : actors)</code> loop. If you only have a single actor, it doesn't make a difference, except then you shouldn't have a loop there in the first place? And about the fps, you are capping it, but that's a maximum frame rate, not a minimum. So first things first, actually check the frame rate... \$\endgroup\$ – Fault Dec 4 '13 at 19:22
  • \$\begingroup\$ The above example is simply an initial test of the rendering, and is by no means code complete. Eventually the levels and tiles will all be drawn separately, and there will likely be several actors. However, I don't want to get too far into it if I can already pinpoint a problem early on with the rendering strategy. Also, I can check the FPS, but the only way it wouldn't be 60 is if the rendering for a single small sprite took longer than 17ms and the TimerTask run calls bunched up. \$\endgroup\$ – user6214 Dec 4 '13 at 20:05
  • 1
    \$\begingroup\$ I would try setting it with code, have it move w/o the key as a quick way to know if that is the bottleneck. \$\endgroup\$ – nycynik Dec 4 '13 at 20:50

It might be related to the way you are setting the new position. Check this answer for some code related to how to monitor key down events.


  • \$\begingroup\$ I'm going to give this a go and report back. I think this will solve the problem. I noticed in the example link that the answer solution detects the keypress and then basically animates synced to a separate adjustable interval until a different keypress. \$\endgroup\$ – user6214 Dec 4 '13 at 21:08
  • \$\begingroup\$ Good Luck! Excited to know the outcome. \$\endgroup\$ – nycynik Dec 4 '13 at 21:25
  • \$\begingroup\$ Hey that was it! It is definitely much smoother and that made a big difference. \$\endgroup\$ – user6214 Dec 5 '13 at 4:04
  • \$\begingroup\$ Great to hear!! Gl with your game. \$\endgroup\$ – nycynik Dec 5 '13 at 20:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy