0

In my Opengl "Engine" i have the following method to compute all the time values, i could need in a frame:

public static void computeTime(){
    thisFrame = System.nanoTime();
    delta = thisFrame - lastFrame;
    lastFrame = thisFrame;
    deltams = (float) (delta / 1e6);
    deltas = (float) (delta / 1e9);
    fps = (float) 1e9 / delta;
    ticksInSeconds += deltas;
}

Im calling this method at the beginning of every frame. then i use the delta values to compute movement and over things.

Is this a proper way to do this? Or am I missing something in the order of the computations? Because I'm feeling like running applications are kind of lagging a bit... so it cannot be completely right, can it?

genpfault
  • 51,148
  • 11
  • 85
  • 139
T_01
  • 1,256
  • 3
  • 16
  • 35
  • Probably `System.currentTimeMillis` could save you some performance and it won't be inaccurate. – cy3er Dec 15 '14 at 11:51
  • i dont think nanoTime() is much slower than currentTimeMillis()... – T_01 Dec 15 '14 at 11:57
  • @cy3er: Both are kind of inaccurate, these timers are unfortunately ***not*** guaranteed by Java to be monotonic. It is possible under certain circumstances that they will run backwards for brief periods of time. Of the two, however, `nanoTime (...)` is less likely to suffer the problem - an NTP time synchronization is not going to suddenly set the clock that timer uses back 1-5 seconds. – Andon M. Coleman Dec 15 '14 at 14:45
  • What type is `delta`. If it is an integer type then `deltas` will probably always be zero and at very high frame rates `deltams` will lose significant time. – GuyRT Dec 16 '14 at 17:33
  • delta is a float, don't worry. – T_01 Dec 19 '14 at 13:44
  • @AndonM.Coleman what do you suggest then? – T_01 Dec 19 '14 at 13:44
  • @T_01: Of the two, `nanoTime (...)`. I was just pointing out the bigger difference between the two functions. One is based on your system clock (`currentTimeMillis (...)`) and the other is based on a non-clock system timer. `nanoTime` is less likely to return a time in the past on a future call, but it can still happen rarely. – Andon M. Coleman Dec 19 '14 at 14:35
  • okay. but Do you have another idea, than this two? – T_01 Dec 19 '14 at 15:20

1 Answers1

1

Edit

Aparently timers don't always work quite as you'd expect. Please check out the other answer(s) provided in this thread.

Original Answer

Personally I would use fixed movement by frame instead of variable movement based on how much time passed since the last frame.

To implement this you would need a method like update() that updates all the positions and draws the updated view, then call this method periodically using a timer:

Timer timer;
final int FPS = ... //Number of frames per second
final int MS_BETWEEN_UPDATES = 1000/FPS;

ActionListener updater = new ActionListener() {
    @Override
    public void actionPerformed(ActionEvent e) {
        update();
    }
};

void update() {
    //Update your game here
}

void startGame() {
    timer = new Timer(MS_BETWEEN_UPDATES, updater);
    timer.start();
}
Marv
  • 3,517
  • 2
  • 22
  • 47
  • but i want to have the maximum framerate i can reach. – T_01 Dec 15 '14 at 11:56
  • 1
    @T_01 But how do you calculate that? At some point, the system needs to be able push your graphics over to the hardware pipe, but if the system is getting to to process those updates, it's going to start gagging and will either stall or throw away content in an attempt to keep up. – MadProgrammer Dec 15 '14 at 12:18
  • 2
    Don't use timers for timing critical things, I've tested them to be up to fifteen milliseconds late. – Lee Fogg Dec 15 '14 at 16:08
  • Huh, I've used this concept on a simple Snake game once and it worked flawlessly but I suppose If you're running heavier or more timing dependent tasks you could get in trouble. I've edited my answer. – Marv Dec 15 '14 at 16:10