LWJGL Stuttering with this game loop.. Any tips?

Game Mechanics
#1

So I’ve read around and cannot find an answer as to why the rendering is stuttering. I’ve read that using update is slow but I don’t know how to implement that into my game loop.
Also could it be a problem that I am using slick to bind textures to the screen and render them.
Anyway the textured quad seems to stutter even when the fps of the game that is printed out stays the same. Even when I put the targetFPS to Double.MAX_VALUE in the Engine class (see code comments) it still stutters mainly when moving in a specific direction for a while. Normally about 2 seconds or so and it will start, then stop pretty fast but still noticable.
I guess I am really asking, am i using a OK game loop for this situation or do i need to change things. Because in the engine i want the user to be able to specify the TPS and FPS for the game. Also are there some optimizations that i have missed or something? Thanks in advance

Here is the GameLoop:


        running = true;

        long now;
        long lastTime = System.nanoTime();
        double deltaT = 0.0;
        double deltaR = 0.0;
        double tns = 1000000000.0 / Engine.getTargetTPS(); //set to 60.0 (ticks per second) updating
        double rns = 1000000000.0 / Engine.getTargetFPS(); //set to 200.0 (frames per second) rendering
        int tps = 0;
        int fps = 0;
        long timer = System.currentTimeMillis();

        while (running && !Display.isCloseRequested()) {
            now = System.nanoTime();
            deltaR += (now - lastTime) / rns;
            deltaT += (now - lastTime) / tns;
            lastTime = now;

            if (deltaR >= 1.0) {
                render(); //renders the single textured quad on the screen
                Display.update();  //is this a problem?
                deltaR--;
                fps++;
            }

            if (deltaT >= 1.0) {
                tick(); //does the game logic
                deltaT--;
                tps++;
            }

            if (System.currentTimeMillis() - timer >= 1000.0) {
                timer += 1000.0;
                System.out.println("FPS: " + fps + "  TPS:" + tps);
                fps = 0;
                tps = 0;
            }
        }
#2

I once made a “game” (falling sand, if you’ve heard of the genre) with decoupled FPS and UPS, I used a multithreaded approach.

In pseudocode:



ArrayBlockingQueue<GameState> pipe;

@@RenderThread:

GameState currentFrame;

loop { //use Display.sync() for timing
    if(pipe.hasElement())
        currentFrame = pipe.take();
    
    render(currentFrame);
}



@@PhysicsThread:

GameState currentState;

loop { //use System.nanoTime() for timing
    tick(); //assembles currentState for this tick
    pipe.put(currentState);
}

It was more complicated than that (obviously) but you get the gist.

This assumes that the RenderThread is consuming frames faster than the PhysicsThread is generating them, i.e. FPS is higher than UPS.
The problem is that it also doesn’t really help much for that situation, as the rendered frame only changes as fast as the PhysicsThread. (In my engine the physics ran faster than the rendering)
To change that, some engines instead interpolate between two frames when rendering, this creates very buttery-smooth rendering, but has a 1 (or more if you interpolate further) frame latency.

Multithreading may or may not be a good idea for you, it was for me mostly because I couldn’t fit both rendering and physics on the same thread and have acceptable performance. If you don’t have this problem, you might not want to use this technique.

Good article on game loops: http://gameprogrammingpatterns.com/game-loop.html
Make sure to check out the related links at the bottom.

EDIT: just realized it might not be obvious to some, but the GameState needs to be either immutable, or the PhysicsThread has to pass a copy of it’s current state. Safety first!