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."
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...
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.
Your monitor's refresh rate is different than the games internal clock. So you can definitely increase the refresh rate on your monitor past 60. There'll just be a bunch of duplicate draws.
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]
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.
Just a tip. The 9200 series are actually WORSE than the old 8500. They are also Direct X 8 series cards, not 9. Spend a bit more on a Radeon 9600 (non pro), it'll last for longer. Otherwise, a Geforce4 4200 would be an excellent choice instead of the 9200. AVOID the low 9000s Radeons.
Mother is the best bet and don't let Satan draw you too fast.
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