Resolution Timers

Newbie & Debugging Questions
#1

Well, the only bad question is one that doesn’t get asked, right?

I’ve been reading a lot on high-resolution timers and such, and how they’re supposed to add a professional feel to games. Question though: Most games try to achieve as many frames per second as possible. So why limit them? Wouldn’t it just be better to create two threads, one to perform the redraw, and another to calculate object positioning - then let them fly as necessary?

Honestly, I’m quite new at this, so any information would be incredibly helpful.

#2

Yes but if you have two threads going only one instruction at a time can still be executed on a single processor computer. So it You cant really multithread a game like that and then expect good performace from it.
A game loop does not limit the frame rate if written properly. A real game loop does the following:

while (running)
{
render()
if (specific amount of time passed)
gameUpdate()
}
So you do a specific amount of game updates and then render as often as possible. The faster the machine the more renders you get. You can have 2 renders between gamticks or 5 renders between gameticks. The more reneders the more fps and the smoother the animation.

#3

Actually you don’t even render as often as possible - you render as often as necessary. Typically anything over 25fps looks ok, and 50fps looks excellent. Because the lowest most monitors go to is 60Hz then 60fps is a great target to look for to make your game look ultra-slick.

Cas :slight_smile:

#4

Well, let’s say you have a sprite with a walking animation, wich was ment to run at 25fps. If the time between the frames is exactly 40msecs it looks perfectly smooth.

But what will you do if it runs at 34fps? You’ll have to show some animations twice (if you want to maintain the speed), wich will look jerky.

Generally spoken - it depends on the game if frame capping makes sense. A pinball/arcanoid/3d game for example can run as fast (fps) as possible.

However, in both cases you’ll need an accurate timer… for calculating the exact time, wich elapsed in the meantime.

#5

Where’s the merit in running the game faster than the monitor is refreshing? The updates never reach the screen…

Cas :slight_smile:

#6

Wow guys! Thanks! I hope you know that a community has a tendency to make or break a project, and that you are all doing an excellent job at establishing Java as a serious gaming language.

Thank you again!

#7

[quote]Where’s the merit in running the game faster than the monitor is refreshing? The updates never reach the screen…
[/quote]
Well, if it’s vsynced it’s basically capped… that’s true :slight_smile:

Turning vsync off is just for benchmarking purposes.

The Q3 engine for example can spit out up to 500fps (lag occures - crash @ 1000fps) and it allows the user to use either fps capping (with com_maxfps), enabling of vsync (with r_swapinterval) or disabling of the limiters alltogether (both 0).

That’s pretty cool imo. It even allows 60(vsynced) fps @ 120hz (r_swapinterval 2) - that makes sense if your comp is slow and your monitor is kinda nice :slight_smile:

However, it allows everyone to run the game as smooth as possible. For me it’s 85fps@85hz, for others maybe 60/60 and for others even 120/120.

Oh and if vsync is off the frames reach the screen… well not completly hence you’ll get tearing.

#8

[quote]Where’s the merit in running the game faster than the monitor is refreshing? The updates never reach the screen…

Cas :slight_smile:
[/quote]
If you are vsynced the one issue is that if you are just able to render in one refresh period, occasionally you will go over… when that happens with vsync on your frame rate suddenly drops to half… this is disturbing, often more than tearing in the display would be.

But as for running the game faster than you can draw… well yeah, not much point, except if it makes things like collision detection more accurate if you run your physics more often… but that depends on the algorithm you use. You certainly don’t want to paint more often than you have to.

#9

If only triple buffering were in OpenGL :-[

Cas :slight_smile:

#10

??? it IS - at least using ATI drivers…