About framerate

OpenGL Development JOGL Development
#1

I have just started using jogl and i have a question about animator class.
Can i somehow control speed of its calls to display method(with that option i would be able to control frame rate).

Maybe it’s a wrong piece of code to check for framerate…

Help,please.

#2

Search for FPSAnimator class in this forum.
With this you can control the fps.

#3

I don’t know about the FPSAnimator class, but:

Concerning animation, a fixed framerate is not a good the solution. It’s better to measure the time between to display calls in use this a scaling factor. As a result animation is still correct, even if the framerate drops.

In order to display the elapsed frames per second, you could measure the time t between a certain amount of frames n, then you have n/t frames per second.

#4

Ah bugger, you’ve done it now. Expect several pages of arguing over which is best, filled with lots of misconceptions of the “refresh rate” of the eye and other such oddness.

#5

Sorry, I don’t get the point. Besides that I doubt that a high framerate has any negative effect on the eyes using double buffering, people worrying about the “eye refresh rate” only have to set ‘enable verticel sync’ to ‘always’ in the driver settings. As a result the frames per second will match the monitor’s refreshrate and every should be fine. So please tell me what I’m missing.

#6

Physics…

Variable frame rates affect physics in a very bad way. Hence, most games fix their FPS so that physics calculations that depend on the step size are not affected, thus making the physics simulation reliable.

#7

I’m guessing when Orangy Tang spoke of misconseptions about the eye’s ‘refresh rate’ he was talking about the fact that having a high framerate (and monitor refresh rate) will only make a difference to a certain point because our own eyes won’t ‘refresh’ the image as fast.

#8

This argument always goes the same way:

  • Someone says they’re using fixed/variable framerate
  • Someone contradicts and says variable/fixed is clearly far superior
  • Members from the ‘variable’ camp say they don’t want a game fixed at a low framerate on their uber computer
  • Members from the ‘fixed’ camp say they don’t want choppy gameplay and lousy scrolling
  • Much debate ensures around deterministic logic, physics update frequencies, methods of interpolating between logic ticks, crazy multithreading ideas, 2d vs. 3d, monitor refresh rates, etc.
  • Sooner or later, someone insists that ‘the eye can only see 24fps anyway’ and that the whole discussion is moot.
#9

Except they would be wrong, and even if they were right it would mean you would have to implement proper motion blur, because natural objects do not teleport from one point to another, they move through every point on some path between the start and end.
:slight_smile:

#10

Thats kinda my point. ::slight_smile:

#11

Never heard of that, can you give me an example please?
Again, I can’t imagine such a situation. If you’re doing intersection tests at two successive frames (which of course isn’t enough for a good collision detection) , then the accuracy increases with the framerate. In cases you use a more sophistaticated approach, you’d either have to solve some equations containong time as a variable or the time interval is subdivied during some iterations, but I can’t see a benifit a fixed framerate here. Moreover only the maximum of a framerate can be fixed, since running other applications in the background can always lead in a drop. In conclusion animation and physics should ever be implemented independent of the framerate.

And concerning the discussion in general: I’m just sharing my experiences, hoping it will help others. And if it comes to a discussion, because someone has good arguments against my proposals, I’m very glad, I probably will learn something :slight_smile:

#12

NOOOOOOOOOOOOOOOO not the roving framerate thread! Move to Clubies. Or banish it to the fiery pit from whence it came etc. but whatever you do, don’t start talking about it again! Orangy Tang summarized 100 threads in one funny post there.

Cas :slight_smile:

#13

Do some tests with ODE, Tokomak, Newton and you’l see they are frame-rate dependant. Novodex is also frame rate dependant, but somehow, they can go around that but they do say its not reliable.

By reliability I mean if you run your simulation 100 times, in a fixed frame rate game, you are guaranteed 100 times that the object falls in exactly the same spot. However, with a variable frame rate, its all over the place. Hence the simulation is not reliable.

Yes, for once i agree with princec, move to clubiiiiies!

#14

Actually, as a “variable framerater”, I found darkprophet’s comment quite useful, since I’d heard the ‘physics needs fixed framerate’ before, but didn’t understand the issue. Guess I’ve got a foot in each boat now. OooooOOO Splash! ;D

Alan

#15

At first, thanks for the second reply darkprophet.

I only have looked a havok physics engine yet and although it seems to have no problems with a variable framerate, I must confess that I never have made such a reliable test.

On the other hand we’re are talking about the graphics framerate, at least I assume that in the jogl forum ;), and a fixed time update step in the physics engine can coexist with a variable (graphics) framerate. Even if you call the ‘update physics’ within the display method you can adjust it respectivly to the measured time: either you have to call multipliy times for a low framerate or ignore it having a high-framerate. Then you have an equal update step, which as you indicated, is required for some physics engines. Of course this is not very different from applying the same algorithm originally used to fix the framerate, on the physics method.

#16
To compensate for low-frame rates (or large step sizes), it is usually recommended that you increase the step interactions taken by the physics engine. Step interactions can be thought of as a simple formula: divide the step size by the step interactions number and update the engine with the new, smaller, step size for [i]stepInteraction[/i] loops . This results in a more accurate calculation of forces accumulated as the penetration depth between two objects will be at a higher accuracy and is close to what it truly is, also, because friction coffecients are calculated by depth penetration testing (in most modern engines), then that will also be affected by the frame rate . How much to increase the step interactions by is highly user dependant as well as library dependant, so assumptions about calculations (like stepInteractions + (fixedFrameRate - ActualframeRate)) cannot be generalised. Also note that the engine also makes assumptions about the step interaction size and optimises for it, so setting the step interactions to 1 and doing the loop manually is [b]highly[/b] not recommended.

Personally, i dont mind either one, variable frame rates or fixed frame rates. As long as my calculations are frame-rate independant, my other threads in the engine are getting what they need, does it really matter?

Anyways, yes, this is a JOGL forum, graphics…etc, enough chit chat about physics.

DP

#17

a good conclusion :slight_smile: