*Is a wondering wanderer, with questions.*

Last year, there was more talks and articles about the FPS in games. Like how Call of Duty runs at 60 FPS and Battlefield runs at 30 FPS.
Some Devs also commented about the pro's and con's of each.

But, can someone clarify a bit more on the issue? What's this having 33ms to draw a scene for 30 FPS? 16ms for 60 FPS?
Does that mean doing A.I, Physics, Rendering, etc...in that amount of time? Is that what a Game Loop is, correct? What more goes in a "Game Loop"?

Also, why does no one make a 45 FPS game? Is it not possible? That would make it 24-25ms to draw a scene, better visuals than at 60fps yet more responsive than at 30fps, no?

And, does it even matter on PC games? As the Hardware varies and you can get less or more of an FPS. Unless you lock it? Should you lock it?

(If I am completely wrong here, please, correct me. And if you got more to add or teach, go right ahead.)

*Here to learn.*

What's this having 33ms to draw a scene for 30 FPS? 16ms for 60 FPS?[/quote]

That is all the time you have to render one frame.

Does that mean doing A.I, Physics, Rendering, etc...in that amount of time?[/quote]
Yes.

why does no one make a 45 FPS game?[/quote]

Most screens refresh at 60Hz or 60 frames per second. By rendering at 30 FPS, you draw every other frame.

45 FPS would mean rendering every 1,2,1,2,1,2,... frames, causing visual stutter.

60 is loosely related to NTSC video format, which displays roughly 30 frames per second. Legacy...

As the Hardware varies and you can get less or more of an FPS. Unless you lock it? Should you lock it?[/quote]

Not following screen refresh rates causes tearing. Next frame is rendered before previous one is done, so upper part of picture is old and lower part is new. The faster the update rate, the more such tears occur.

Such effects are not desirable as far as image quality goes, but once upon a time it was considered an advantage to have highest possible framerate.

Consistent 30FPS tends to be better than uneven 60FPS. For TV screens, going beyond 60 isn't viable, especially since LCDs have other limiting factors and will typically need 5-10ms to update anyway, less if they're designed for 120Hz.

Another factor are the delays caused by transmission. Delay from keypress to pixel change on screen has been measured at 4-7 frames, or around 100ms on typical configuration. There is nothing one could possibly do to get around that, 30FPS works better in this case than 60FPS.

There is a certain "bare minimum" frames-per-second that you need in order for your rendering to look smooth to the eye. 30 is a commonly accepted value for this bare minimum, although it also depends on genre. That is to say, in a tight action-based shooter, the higher the better, but in a turn-based strategy you can get away with somewhat lower. Still, 30 is a good ballpark figure. Some people swear by 60, though; at 60, almost nobody can detect any kind of frame choppiness.

60 is a common number as well, since for a long time that was one of the default refresh rates for monitors. You see a lot of higher refresh rates these days, but still; if you're shooting for a decent frame rate, you could do worse than 60.

As far as capping framerate, this does occur if V-sync is enabled, capping fps to the refresh rate of the monitor. Outside of refresh rate, I tend to prefer not capping fps explicitly. I simply do everything that I need to, then allow the framerate to "fill the holes" and go as fast as it can. That's only if you choose not to enable v-sync; but IMO you really ought to. Without v-sync, you can get ugly tearing.

Now, all of this is in regards to visual framerate, and is entirely separate from other uses of the word framerate, such as physics and logic. Most games are going to decouple the various framerates from one another, so that for example the speed of the physics simulation isn't dependent upon the speed of rendering, and vice versa. Old DOS games would frequently tie simulation and rendering together into the same rate, and as processors advanced older games became unplayable due to excessive speed of updating.

A common implementation is to update physics and logic at a relatively low fixed rate, and allow the screen to draw as fast as it can in the meantime. To "fill the holes" so to speak. This requires interpolation of game states in order to work, otherwise even if you have a high frame rate the render system will spend a lot of that framerate just redrawing the same exact scene over and over. By interpolating states you get a consistent update rate that is easy to manage as far as physics and logic are concerned, plus you get a silky-smooth visual framerate as far as rendering is concerned.

Where you fix your simulation update rate is entirely up to you and is, again, subject to genre. A fast, physics-based shooter needs as fine a simulation step as you can manage, lest numerical instability in the physics system cause odd behavior. And, once again, a turn-based strategy needs a much less frequent update. For example, in the current turn-based iteration of my RPG I have a 4-updates-per-second logic simulation step, yet the rendering consistently manages 156 fps or so, and everything is silky smooth. Many RTS type games will go as low as 10 or 15 FPS for the simulation step, to allow more "in between" time for pathing calculations and the like.

All of this is subject to the requirements of the project, and there really are no hard and fast rules. I recommend reading the old standby Fix Your Timestep. It goes into detail about the ins and outs of the various approaches to constructing a loop.

Does that mean doing A.I, Physics, Rendering, etc...in that amount of time?[/quote]
no only the rendering
you normally seperate rendering & everything else
eg
Im working on a phone game at present (CPU not as fast as desktop)
Im doing all calculations @ 30fps but the rendering @ 60fps

though if youre doing a fast twitch game (fast FPS, driving etc) you will most likely want the updates > 30fps (and perhaps drop the rendering down to 30fps)

Most screens refresh at 60Hz or 60 frames per second. By rendering at 30 FPS, you draw every other frame.

So by rendering every other frame you get an empty frame that "helps" you draw the next one? I know, weird question...what I'm trying to get at is, If most screens refresh at 60FPS and you make a 30FPS game, whats happening with the other 30 frames? Like, lets use BF3(30FPS) and CoD3(60FPS) as an example. BF3 looks better and has more going on than CoD. Why is that? or How is that?

Not following screen refresh rates causes tearing.

So anything below or above 30 FPS, 60 FPS and 120 FPS will tear? If you have Vsync on and something causes a slowdown(bombs going off) in the game, would that tear or just slow down looking all nice?

Delay from keypress to pixel change on screen has been measured at 4-7 frames, or around 100ms on typical configuration. There is nothing one could possibly do to get around that, 30FPS works better in this case than 60FPS.

Is this what is called Input Latency? If so, I thought that was one of the advantages of going for 60 FPS...because of the smoother gameplay. Maybe I understood it wrong, can you explain a bit more?

As far as capping framerate, this does occur if V-sync is enabled, capping fps to the refresh rate of the monitor. Outside of refresh rate, I tend to prefer not capping fps explicitly. I simply do everything that I need to, then allow the framerate to "fill the holes" and go as fast as it can. That's only if you choose not to enable v-sync; but IMO you really ought to. Without v-sync, you can get ugly tearing.

You are reccomending to use Vsync, but you don't use it. What are the advantages of not using it? Why don't you use it? If you can say.
And well, if you use Vsync, what are the disadvantages of it?

Now, all of this is in regards to visual framerate, and is entirely separate from other uses of the word framerate, such as physics and logic. Most games are going to decouple the various framerates from one another, so that for example the speed of the physics simulation isn't dependent upon the speed of rendering, and vice versa.

Is this one of the reasons why there are very very few physics heavy games? Like Imagine playing a Tank and slowly going up against a building and breaking the walls realistically by what part of the Tank touches the walls, columns, etc...and then having those realistically broken or shattered pieces affect the world and its players. Leaving tread marks on the grass, sand, streets and stuff. I think I went a bit offtopic...But, why don't we see games like this? Just much more polygons on the screen.

A common implementation is to update physics and logic at a relatively low fixed rate, and allow the screen to draw as fast as it can in the meantime

Would the more "real to life" way of doing things would be to update everything at the same time? Otherwise, if your logic(A.I?) step is running at 30FPS and you are rendering at 60FPS does that mean that the enemy will take twice the time to react to the scene or the player? Did I make sence? Not sure...I mean, if you have one thing running at a slower frame then the rendering, they would not be in-sync/union to each other. So, there would be some form of a disadvantage to that?

Im doing all calculations @ 30fps but the rendering @ 60fps
though if youre doing a fast twitch game (fast FPS, driving etc) you will most likely want the updates > 30fps (and perhaps drop the rendering down to 30fps)

You mentioned having higher update rate than rendering rate. So its possible to have Physics,Logic, etc higher than your rendering? Advantages and disadvantages?
If I remember correctly, I read that either Forza or Gran Turismo(or both) had alot of physics going on per second. I'll try and look that up.


Thank you all so much, but sadly, I had more questions for you all! This thread just became an instant bookmark for me.

Tearing happens when the monitor refreshes its view while the graphics card is in the middle of redrawing the scene. You get part of the screen still showing the previous visible frame, and part showing the new frame being drawn. Produces an odd shearing effect along a scanline that looks pretty bad. I was a bit misleading in my post. I always use v-sync in my personal projects, but it is a driver option that can be disabled by the user, so often the dev has no control over the use or non-use of v-sync. Some people like to see big numbers or to know the maximum capabilities of their card, so they'll disable it. If you hard-cap the game to a fixed framerate, they get misleading data.

Would the more "real to life" way of doing things would be to update everything at the same time? Otherwise, if your logic(A.I?) step is running at 30FPS and you are rendering at 60FPS does that mean that the enemy will take twice the time to react to the scene or the player? Did I make sence? Not sure...I mean, if you have one thing running at a slower frame then the rendering, they would not be in-sync/union to each other. So, there would be some form of a disadvantage to that?
[/quote]

No, you don't want to update at the same time, if I understand what you mean. You need the simulation to be predictable. By fixing your logic step, you can ensure that logic updates are applied in a consistent and deterministic manner, unaffected by hiccups in the rendering framerate. In a fixed timestep loop, if the game falls behind in the simulation it is possible and desirable to skip rendering for a bit while the logic module updates multiple times, rather than let the simulation fall behind. Sure, you get a bit of visual lag, but at least you keep your simulation on schedule. This is especially important in multiplayer games, where if your simulation de-syncs on one machine it can case a disconnect or otherwise wreak havoc. The simulation always gets priority. That is what I meant by letting the visual framerate "fill the holes." Once you have your simulation scheduled, whatever is left is given to rendering.

The enemy isn't going to take twice as long to react as the player; I doubt there are many players who actually have reaction times that fast, and I doubt that 17ms is going to make a difference. Once the input impulse is received, both player and enemies are locked into the 30 fps (or whatever) logic rate. If it somehow does become a problem, rather than letting player input immediately affect the simulation, you can queue the impulses and have them applied to the system during the next logic step. This way, everything is "fair". It's probably the way you would want to do it in a multiplayer scenario anyway. This does introduce what they call "input lag", but from a tactile standpoint it is scarcely noticable if the logic rate is high enough, and from a simulation standpoint it is nonexistent, since everything can only add impulses to the system during logic update.

The way to think about is that the logic runs completely unaware of the visible part of things. It doesn't care who does or doesn't see what's going on. It just steadfastly does its thing at a fixed, deterministic pace across all the machines in the game. Sending updates, moving stuff around. The rendering thing is just an observer. Every once in awhile it "takes a peek" at what's going on, a snapshot of the current state of action, and throws it up on the screen. The trick is to balance the allocation of CPU time to the different components, ensuring that 1) the logic system stays in sync and 2) the visible framerate stays high enough to ensure a smooth visual experience. They are both important, but keeping the logic in step is more important.

Now, numerical simulations such as physics live and die by numerical approximation. A physics subsystem works by integrating a large number of fairly complex equations, and can only do so in a highly performant manner by making approximations. Thus, they can and often do suffer from numerical instability, especially if you use larger timesteps. This is the reasoning for dropping the visible framerate and increasing the logical framerate; the smaller you can make your timesteps when it comes to integrating a physics simulation, the more accurate that simulation will be. Given that human perception has soft limits on the framerate they can perceive, it makes sense to sacrifice ultra-high framerate to achieve a more stable physics simulation.

It becomes a balancing game. What physics timestep can you use that will provide the most stable simulation you can achieve on the target machine spec while maintaining the most smooth visible framerate? By decoupling rendering and physics, you can more easily tweak the numbers and thus the allocation of CPU resources to achieve this balance.

[quote name='Antheus' timestamp='1333915028' post='4929383']
Most screens refresh at 60Hz or 60 frames per second. By rendering at 30 FPS, you draw every other frame.

So by rendering every other frame you get an empty frame that "helps" you draw the next one? I know, weird question...what I'm trying to get at is, If most screens refresh at 60FPS and you make a 30FPS game, whats happening with the other 30 frames? Like, lets use BF3(30FPS) and CoD3(60FPS) as an example. BF3 looks better and has more going on than CoD. Why is that? or How is that?
[/quote]

The simple answer is that BF3 spends twice as long rendering each frame so it has time to add more visual detail.
Rendering is normally done to a backbuffer (which isn't visibible) , when the frame is completely rendered it gets swapped over to the front buffer and displayed, The image in the frontbuffer stays visible until a new swap is made.

Think of it as an artist(The renderer) sitting in the back of a room drawing pictures, and a camera(the monitor) taking photos of whatever picture it has in front of it 60 times per second.

Now, the artist can only put a new picture in front of the camera between shots (if he tries to swap picture while the camera is shooting you'll get a blurry picture or his arm might get caught on camera, with computers we get tearing instead in that situation), so the picture has to be changed between the cameras shots(vertical synchronization), if you render at 60 fps then the artist has to churn out 60 images per second and put a new one in front of the camera between every shot (so each shot the camera makes is of a new image), the artist however really doesn't have much time to draw his images so he can't add too much detail to them if he want to keep this pace (if he takes too long to draw one image he'll miss the opportunity to swap in his picture and has to wait for the camera to complete its next shot before swapping it in, (So if the artist only manges to render 50 pictures per second the camera will take 2 shots of 10 of those pictures, but only 1 shot of the rest which makes the resulting animation uneven)

at 30 fps the artist takes longer to draw his pictures and only puts a new picture in front of the camera between every other shot, thus the camera will take 2 shots of each picture, (This effectivly gives you the same effect as you'd get if the camera only took a picture every 30 seconds), By taking longer to draw each image the artist(renderer) can put more effort and detail into each image and still make the swaps at the appropriate times.

Now the artist isn't just drawing whatever ideas he has in his head, he is looking at a world and tries his best to make a nice drawing of it, the simulation framerate determines how often that world changes and if you use interpolation the artist will look not only at the latest version of the world but also the previous version and then draw moving objects in imaginary states somewhere between those two world states, (If the world just changed then the artist will make his drawing very close to the old world, if it is almost about to change he will make it closer to the new world), this can give you a smooth looking animation even if the world updates happen at a rate that differs from the render rate.