Slashdot Mirror
id Says 60fps Is Enough For Doom III
Dot.Com.CEO writes "IGN PC reports that the final version of Doom III will be capped at 60fps, quoting John Carmack as saying 'A fixed tic rate removes issues like Quake 3 had, where some jumps could only be made at certain framerates'. Will this put a stop to fans arguing whether there is a tangible benefit for frame rates over 60fps? What do Slashdot Games readers think about id's decision?" Elsewhere, there's a new preview of Doom III at C+VG, including a mini-interview with Carmack in which he comments: "Now's where it goes from being an interesting demonstration of all the technologies to being a fabulous game, and that really does all happen at the end."
Just wondering if this makes Nvidia happy, since both highend cards can push 60FPS. Cant really use Doom3 as a benchmark, unless you can override the 60FPS cap.
And after reading the Q3 Tic, info about jumps, wouldnt that be bad code design that causes the jump distance to alter with higher FPS? Wheres a good FPS Engine coder to coment on this...
Does this mean that the display will also be set to a 60 Hz vertical refresh, which causes "flicker" with 60 cycle per second light sources, like some flourescent lighting? I think I would very much prefer they cap it at 72 FPS, or at least set the vertical refresh higher than 60.
Ouch! The truth hurts!
If you still measure the caliber of a video card in how many quadrillions of frames per second you can get, then you are messed up. You should be looking at the feature set, and seeing if it still maintains the minimum 60fps.
Occam's razor is the blind faith in the natural selection of least resistance and in universal oversimplification. -- EF
60hz is a big leap for the games simulation rate though, if i recall correctly quake 3 ran at around 20 to 25 by default, but you would see inbetween stuff due to a trick called interpolation. The statement in the article seems to imply that doom 3 won't be doing any interpolation, which I think is the most interesting aspect of the comment.
There is one more rate to take into consideration and that is the sample rate for models. When objects in the game are animated, one samples the position of "bones" in the model. If you use motion capture the sample rate is set by the equipment.
Inbetween these samples the model is interpolated so the motion become more smooth. That is where Quake 3 used ~20 samples per second. But the physics engine did one pass per frame, and thus people with certain framerates could make superjumps.
The problem really has nothing to do with how many frames the human eye can see in a second. As was almost implied by the previous reply, it has a lot more to do with your monitor's refresh rate at a given resolution. If your monitor is at 60hz, you're not getting more than 60fps whether your card puts it out or not, because the monitor isn't going to draw them (this is why v-sync is good for games, but is disabled for benchmarks, where the monitor shouldn't have any influence on the test).
;)
Obviously, capping the framerate was the easiest way for id to solve this particular problem, and 60 fps is generally accepted as good enough. Anyone that thinks it isn't probably hasn't played many games capped at a certain framerate (for instance, you can cap your framerate in Half-Life and many other games). Once it's capped at a certain rate, it limits the possibility for severe slow-downs when framerates drop on complicated scenes. This is the real reason that having a card that plays 200 fps on the latest game (besides the obvious issues with previous Quake games) is important, because the higher average values mean higher values for the lowest framerate in a round. If you're playing with an average of 100 fps and the game slows to 60 fps, it's going to feel like it's crawling, but if you're playing at 60 fps and it drops to 50 fps you might have trouble even noticing it. If it never drops, even better
In the end, at least they've done something to address a problem typical with their past engines. I wish they had found a more elegant solution that allowed individuals to choose higher framerates without affecting the gameplay, but something's better than nothing. The only people that will complain are the ones that spend most of their time staring at fps counters while they play or benchmarking their graphics cards with the latest demos. Maybe some people will finally figure out that their games would be more playable if they capped their framerates at a reasonable level rather than trying to buy faster hardware and tweaking their systems all day to acheive a 100fps average that gets slammed to 30 fps every time 5 people are on the screen at once.
-PainKilleR-[CE]
Now's where it goes from being an interesting demonstration of all the technologies to being a fabulous game, and that really does all happen at the end.
Is it just me or does that sound horribly wrong? Actually, we also enjoy good plots, character design, thoughtful level layout, adequate difficulty, intuitive user menus, goodies to unlock...
High fps's and good looking exploding heads don't give us a good argument when the Moms with homicidal moron children come a' suin'.
I wonder which dumba^H^H^H^H^Hmathematical specialist chose to use the framerate as timeunit for all the calculations. That's highly unfair. After all, I want things to happen - even if I don't see them on my 200MHz MMX ATI Radeon. ;-)
;)
And actually, this timeunit problem is quite old: Remeber all those funny M$-DOS-games that you liked to play on your 8086? And then you had to switch this "TURBO" button on your 80286 to be able to play them again.
OK, guys, to troll a little bit:
1) Amiga programmers used to use the time.device.
2) One poster told you Hz (or 1/s) stands for Hurtz. Never heard about Hurtz, but Heinrich Hertz is supposedly upset that someone stole his idea...
Far be it for a lowly coder to question Mr. Carmack, but this seems like a hack. The analysis Slashdot linked to indicates that the problem is caused by a series of errors:
.5*a*t^2. Instead of computing a delta-y at each frame, you should recompute the entire equation each frame, and offset it again from the original point. This means that anything from 1fps to infinite FPS will be accurate, limited only by the accuracy of the FPU.
1) Rounding to integer units in the computations
2) Rounding to milliseconds in frame-rate-control
3) Using frame-dependent computations
These aren't new problems, they are 3 no-nos in game design. Locking the frame rate has many disadvantages (pointed out in other posts). By doing this, it implies that Doom III is still using flawed calculations. How long before somebody decides to create a mod unlocks the frame-rate without fixing the problem? Maybe the timeline is the issue, so I hope it is something addressed in a future patch.
Let me clarify:
1) Most calculations moved from fixed-point integer math to floating-point math in Q1. Integer positions may be okay, if the number is large enough (64-bit?).
2) Timings are accurate enough now that this should not be an issue. Many engines keep values such as the # of ms for the last frame, and the rolling average in floating-point units.
3) This is one of the most common mistakes in game coding and demo coding. Take falling as an example:
y1 = y0 -
Some people will argue that these approaches are slower. But for most games, only about 20% of the time is spent doing calculations for positioning, AI, etc. Most of it is rendering. So a few extra floating-point multiplications per frame is not an issue, even on a slow PC.
Translation:
Our engine is wicked fast because we calculate everything with integer math. Our physics engine runs at a rate fixed according to time, not machine cycles, so that any computer fast enough for the game will run the physics exactly the same as any other machine, and so integer math round-off errors will be consistant, and can be made up for in the map design.
We chose to fix the frame rate to the same rate as the physics engine so that video cards will not be re-rendering the same frame twice. If they did, then the game would appear jumpy.
If you run at 72fps, and the engine runs at 60, then you'd get a duplicate frame every 5 real frames. Since the controls are tied to the physics engine, the controls would feel laggy 12 times a second, until the frame rate again caught up with the engine.
The optimal setup will have the monitor set to 60Hz, or perhaps a higher frequency that is some multiple of 60Hz, but will result in quick beats: rather than 1 in 5, choose 90Hz so every third frame is a duplicate, or best choose 120Hz.
Or just turn off the flourescent lights. You want a terrifying experience anyway - who wants to play with the lights on?
-Adam
This still isn't true. Even if the game world runs at 60hz, your mouse runs at, most likely, 125hz. In all of the Quakes, and the same probably applies to Doom 3, mouse looking is a local thing unrelated to the rate the world runs, but definitely related to your FPS.
In all of the Quakes, if you have a 60fps, then you have an effective 60hz mouse sample rate. Mouse looking at 60hz is far different than mouse looking at 125hz. Hence a framerate cap will decrease the smoothness of mouse looking.
Really bad to hear they are doing this.