darxus's picture

Loop timing of OpenTK

I would like to ask:

1. If the exact methods "OnUpdateFrame" and "OnRenderFrame" are delta-timing safe. In other words, shall I pass exact values for rotation/translation or use delta time value instead?


speedX += 2.0f;


speedX += 2.0f / delta;

2. As far as I seen in the source code, there's a very good and standard timing mechanism (in "Run()" method), but I am a bit worried about it's efficiency. How this method behaves? I know that the best solution is to use frame tweening, is this same as OpenTK's?

P.S. I am a bit noob in these advanced stuff, but I never say no in learning them. ;-)


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture

Calling Run like GameWindow.Run(30.0, 60.0), guarantees exactly 30 UpdateFrame events per second. If the computer can't handle the requested UpdateFrame rate, RenderFrame events will start being dropped in order to maintain it.

Up to 10 RenderFrame events will be dropped this way. If the computer still can't keep up (i.e. it falls below 6fps in this case), you'll see the UpdateFrame rate to start dropping. The correct approach is to define your program's minimum requirements so that this never happens - that's what commercial games do ;)

Obviously, the higher you set the UpdateFrame rate, the more difficult it is to maintain.

Now, the logic behind GameWindow is accurate enough that you can use exact values in UpdateFrame events:
speedX += 2.0f;

Obviously, you shouldn't do this in RenderFrame events, since their rate is much more variable (by design). In any case, everything depends on your design:

  • You could use variable rates and deltas everywhere, which has the advantage of scaling nicely to higher frame rates (smoother movement), but is more CPU intensive (divide everything by delta) and more prone to numeric instabilities.
  • You could use fixed rates everywhere, which is simpler but will not look good if the UpdateFrame rate is lower than the RenderFrame rate (jerky movement).
  • You could use a fixed UpdateFrame rate and a variable RenderFrame rate, and interpolate object positions in the RenderFrame event to obtain smoother movement. Once again, this is more complex but would give the best of both worlds.

There is no clear-cut solution to these issues. You'd have to experiment and pick the one that works better for the program you are going to make.

darxus's picture

OK, Fiddler thanks for clearing this out, I was very curious about this.

Inertia's picture

You can consider e.Time as the percentage you want to step (assuming 1.0 == 100%), so if you want to have an object rotate 90° per second you'd calculate something like this: Angle += 90 * e.Time;