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."
I can HONESTLY say I can notice a difference up to 100fps framerate differences. I am not kidding. We have been playing games like this so long, it is only natural for people to adapt and get "used" to higher framerates.
IDs games have been used for years as a benchmark, and a basis for purchasing beter hardware, and continue to support their game. They can throw that out the window now.
I think if they MUST cap the framerate, then at least try to put it around 85. I understand the reasoning, I just wish there was a workaround.
However, from my understanding, this is NOT a "twitch" shooter, so it probably really doesn't make that much of a difference.
if the engine was capped at 2fps...
Mother is the best bet and don't let Satan draw you too fast.
You have enemies? Good. That means you've stood up for something, sometime in your life. --Winston Churchill
No problems here. I don't think that I can differentiate between 60 FPS and 120 FPS...although I'm no expert.
It seems like this will fix the issue addressed in the post, and it may mess with some benchmarks that will use Doom III (anandtech, tomshardware, etc)...however, I'll bet that you will be able to turn the rate-limiting off for benchmarking purposes. Otherwise, there will most likely be no noticable effect.
-Turkey
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...
I wonder if it'll be anything like the original Doom's deathmatch - one guy wearing bright, glowing green, with three in dark colours. That was fun, as long as you weren't player 1.
I can't say that I don't give a fuck. I've just run out of fuck to give.
Even as an individual who benefitted from the 90+fps bug, I like this idea. It really levels the playing field. Now, I just hope Doom3 plays nicely with my Dual 3200+/9700Pro or Dual 2GHz G5/9600 Pro at something close to 1280x1024(LCD).
John Carmack just scored more points in my book. Now if only we could force everyone to use full shadows...
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!
No, it won't. We'll just have to get accustomed to the term "number of simultaneous Doom 3 windows" rather than "number of hundreds of frames per second".
Quake 1 NetQuake (not quakeworld) was capped at 72 fps. Since QW, Q2 and up does client-side movement/prediction, this has been an issue on the client.
The thing that players need to worry about is MINIMUM FPS. During a firefight, there will be more elements to draw, and hence a longer render time. Having this drop below your framerate cap is a bad thing.
The issue with jumps being variable depending on ticrate has been a problem in Quake1 days too. In NetQuake, it was only the server ticrate which mattered. Today with client-side prediction, its the clients too.
This just makes me say to id: fix your damn physics model! Why should the jump distance be dependant on ticrate?! Some weird quantization errors you have there.
-molo
Using your sig line to advertise for friends is lame.
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
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
Yeah, I can tell the difference between 60fps and 75fps. 60fps gives me a headache after ten minutes.
Here's the thing: The "refresh rate" of the human eye is about 15Hz. It's not really fair to call it a refresh rate since different parts of the eye transmit light level changes at different rates (faster in your periphial vision). It's just that on average, the cones and rods in your eyes take about 60ms to "settle".
Of course, the eye isn't taking snapshots, over this 60ms you're sort of summing the incoming light over the entire period, and transmitting the "average".
Thus, we see everything with motion blur pre-attached. Our brains and optical centers are wired to use that blurring to reconstruct the missing motion. Also used in the reconstruction: the fact that different parts of your eye can update independantly, so you have this distributed stream of information coming in whenever, and your brain is assimilating all of it and using all of it (including differences in timing) possible to get the best representation.
Okay, so then clearly, we need really high framerates because our eyes are not cameras telesynced to the monitor... we need to have the pixels as accurate as possible at every time because we never know when a cells in a region will want to transmit. We "figure out" that we are seeing stop frame animation, even if you saw the "snapshots" of the eye, it still would look somewhat blurred and layered. This is the brain postprocessing outsmarting our technology.
Easy fix? You can use a lower framerate if you add the blur. This is why we can sit through movies at 24 FPS, or TV at 30, since the recording equipment is averaging it for us. Of course, we can still sense the "syncronous" nature of the screen updating, especially when comparing camcoder stock at 60fps and movie stock at 24.
But you don't need to update the screen nearly as fast. 60fps with motion blur is about as realistic as one could ever hope for. Have you seen HDTV football broadcasts! My god!
So if Doom supports capping the output framerate at 60fps, but internally allows motion blurring by rendering at twice that followed averaging, I don't think you'll notice it at all. As far as your eyes are concerned, you're screaming at 120.
The one thing I think is a bad thing is that they chose 60. If this is vsynced on an analog monitor (necessitating a 60Hz vert refresh), it kind of sucks. I can "see" the refresh on lots of monitors at 60, but it goes away at 70. I'm sure many of you know what I mean.
I'd rather them cap it at 70, or 72. With 72 v. ref. you could update the screen at 24fps, tripling each frame, but rendering 3-6 frames when possible to create the blur.... LIKE WATCHING A REALTIME MOVIE. When it gets busy, just cut the number of frames you average.
That would be fricking cool.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON