id Says 60fps Is Enough For Doom III

I wonder... by GreyWolf3000 · 2003-10-23 03:45 · Score: 1

...if this will make my old g400 play Doom III "better" than Quake III. I guess it all depends on whether or not this relic of the 90's will still be able to play it. I hope so, g400's are still really nice (albeit low-end) cards.

--
Slashdot: Where people pretend to be twice as smart as they really are by behaving like children.

One downside... by Dutchmaan · 2003-10-23 03:45 · Score: 1, Offtopic

This will definitely eliminate or hinder using Doom3 as a benchmarking tool.

Re:One downside... by kayen_telva · 2003-10-23 03:56 · Score: 0

troll. flamebait. moron.
Re:One downside... by FunkSoulBrother · 2003-10-23 04:00 · Score: 1

I think he had the troll pre-prepared and shot his load early on it. I mean, it wasn't even relevant to the parent topic.

He just wrote it and wanted to use it so bad he couldn't find a situation where it may have been mildly funny/scathing.
Re:One downside... by fredrikj · 2003-10-23 04:03 · Score: 4, Funny

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".
Re:One downside... by Anonymous Coward · 2003-10-23 04:13 · Score: 0

You're right! Yay for you! Good job buddy! We're all so proud of you back home - we were a bit concerned when you moved out of the garage after your 33rd birthday. But I see now that you're doing well for yourself with that apartment and the ability to post scathing retorts on Slashdot from the public library in between shifts at Burger King! You have arrived!
Your father always said you'd amount to nothing - you have certainly shown him!
Re:One downside... by Anonymous Coward · 2003-10-23 04:22 · Score: 0

A guy who has bad karma is calling someone a troll? Don't be a self-hater kiddo!
Re:One downside... by Directrix1 · 2003-10-23 04:31 · Score: 2, Insightful

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
Re:One downside... by Anonymous Coward · 2003-10-23 04:45 · Score: 0

who cares. it's a game not a benchmark. if you want to benchmark get madonion
Re:One downside... by Synic · 2003-10-23 06:20 · Score: 1

the whole point to benchmarking with a game is to get "real world" performance analysis-- madonion is a glorified demo scene app... if you want to figure out which video card / system components you want then you benchmark the stuff with your favorite game so you know exactly what's better!
Re:One downside... by FunkSoulBrother · 2003-10-23 11:28 · Score: 1

Good Job.. a much more apprpropriate use of that troll.
Re:One downside... by bobbozzo · 2003-10-24 13:08 · Score: 1

When I buy a video card, I want to know that it'll run game X at a good fps AND I want to know that'll it'll have a fighting chance at being able to run future game Z at an acceptable fps.

One of the best way to judge that is by seeing that it has excessive capacity for running current game X.

My current card is a GF1 DDR, and I will upgrade when I need to (probably when HL2 or DoomIII come out), and I don't want to have to buy another card when Quake4 or whatever other games come out next year.

--
Nothing to see here; Move along.

Bad Idea by xagon7 · 2003-10-23 03:47 · Score: 2, Interesting

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.

Re:Bad Idea by Acidic_Diarrhea · 2003-10-23 03:57 · Score: 1

I'm not trying to start some giant debate about the highest frame rate the human eye can perceive BUT I read this bit about the highest frame rate the human eye can perceive and if there is a limit,
"Technically, yes. Practically, no. The technical "limit" would be anything ranging from the speed of light to how long it takes it to reach your eyes to how fast your brain can interpret it. Other things like internal chemical reactions and the state of developed neural connections should also be considered. But still, 300,000,000m/s is pretty fast. What am I trying to say? This:
THERE IS NO PROVEN LIMIT TO THE FRAME RATE THE HUMAN EYE CAN PERCEIVE."

I got that from some guy on the internet, which is obviously a dubious source BUT it seems to make sense to me at least...

--
I hate liberals. If you are a liberal, do not reply.
Re:Bad Idea by Anonymous Coward · 2003-10-23 04:32 · Score: 0

The highest frame rate that can be perceived and the highest refresh rate that can be perceived are different. When turning fast, you are likely to notice just about any practical frame rate.
Re:Bad Idea by PainKilleR-CE · 2003-10-23 04:44 · Score: 5, Insightful

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]
Re:Bad Idea by Anonymous Coward · 2003-10-23 04:58 · Score: 0

"Once it's capped at a certain rate, it limits the possibility for severe slow-downs when framerates drop on complicated scenes. "

Bollocks. read the article. they are not promising a minimum frame rate.
Capping to 60fps doesnt mean that it can somehow magically deal with more things on screen at once.
Re:Bad Idea by MobyDisk · 2003-10-23 05:01 · Score: 1

What refresh rate is your monitor running at? Some monitors can achieve 100hz, but very few of them. If you run at an FPS higher than the monitor's refresh rate, it doesn't display the extra frames, it just displays tearing artifacts.
Re:Bad Idea by PainKilleR-CE · 2003-10-23 05:17 · Score: 1

Bollocks. read the article. they are not promising a minimum frame rate.
Capping to 60fps doesnt mean that it can somehow magically deal with more things on screen at once

I never said anything about a minimum framerate. Just because you can't read what I typed doesn't mean I'm saying something I did not.

When your framerate is 60 fps, the most your framerate can drop by is 60 fps. If it drops from 60 to 30 then you're not going to have as big a slowdown as you would if it dropped from 100 to 30. In one case your framerate cuts in half (60 to 30) in the other it goes down 2/3rds. There is a very noticable difference between 30 and 100 as compared to 30 and 60. If it only drops to 50 because your card can handle 2 people on the screen reasonably well, there's even less of a problem when you're capped at 60.

Many people tend to play fps without a framerate cap and with v-synch turned off because this is the way it's done in benchmarks. Then they complain that their card isn't fast enough or that 60 fps isn't good enough because it feels very slow when their framerate drops from 150 to 60 in Quake 3. The reality is that v-synch gives you better image quality when cards start to have problems with a scene (or set of scenes) by limiting tearing, and capping your framerate somewhere closer to the minimum framerates you see in the game gives you a better experience because it minimizes drastic changes in framerate.

Of course, no one wants to play a game at 10 fps, so if your card sucks it's still going to suck. However, if you cap your framerate at a level where your framerate will rarely, if ever, be cut in half, you're far less likely to notice any slowdowns at all in the game. Unfortunately, with the way that the Quake games have previously handled their physics, you were screwed in certain situations if you didn't have a significantly high framerate. With this cap, there's a solution to that particular problem, although it is most certainly not the most elegant solution to the problem. Maybe some people will finally understand, in a couple of years when everyone's cards can pump out 60 fps consistantly on Doom 3, that your maximum or average framerate is not nearly as important as your minimum framerate and the difference between that minimum and the average.

--
-PainKilleR-[CE]
Re:Bad Idea by PainKilleR-CE · 2003-10-23 05:22 · Score: 1

Some monitors can achieve 100hz, but very few of them. If you run at an FPS higher than the monitor's refresh rate, it doesn't display the extra frames, it just displays tearing artifacts.

It can also happen if you're running at lower fps than the monitor's refresh rate. This is why someone invented v-synch. As long as v-synch's enabled, tearing should be a thing you never see, regardless of your framerate.

Of course, since v-synch limits your framerate to your refresh rate (since it waits for the vertical refresh of the monitor before displaying the frame), it's disabled for benchmarking purposes. If you want to strut around about how cool your new video card is in your system, you disable v-synch. If you want the game to actually look good, you enable it.

--
-PainKilleR-[CE]
Re:Bad Idea by Anonymous Coward · 2003-10-23 05:30 · Score: 0

"I just spend 750 USD on a fscking video card, and DAMN IT, I CAN see the difference" is another way of writing what you said.
Re:Bad Idea by cybergrue · 2003-10-23 05:42 · Score: 2, Informative
The 60fps is the average maximum that most of us can see. Considering that this is twice what movies are shown at,(actually its a bit more complicated, some theaters project each frame twice to reduce flicker) and just under the refresh rate for most monitors, I dont think this is a problem. The only time I have heard this being a problem in computer games was with quick turns and other high speed events.
I was wondering when some game maker was going to decided to cap the fps rate and concentrate on other things. We are close to the point where the computers we play these games on will all be able to exceed the 60 fps limit. (thank you Mr. Moore) By not having to draw more frames then 99% of the pop can see, the game can focus on gameplay, and as a side effect, eliminate slowdowns affecting the # of fps outputted, say when everyone in the room gets fragged by someone suiciding with a big grenade. Hopefully by seperating the drawig routines from the world model, better gameplay can result. By doing this, certain 'cheats' can be implemented, such as lowering resolution durring high speed turns or objects speeding by at high speed. The old burred fence post trick. Your eye cannot see any details on the fence post as wou wiz by it at 60 mph, so why bother drawing all the details on it. A similar trick was used in
- Who Framed Rager Rabbit.
in the scene where Bob Hoskins character was driving the cartoon car, and turned a 90 degree corner quickly. This was done by splicing two pieces of film together, and then hand drawing a approximation of Mr. Hoskins in for the few frames that were impossible to film in real life. The human eye would have detected the few frames that he has missing if they hadn't done this, but cannot detect the replacement of a live human by an animated figure for this short ammount of time.
As I said before, it was only a matter of time before someone did this as drawing something people cannot see is a wast of resources. The next limit I can see would be the number of polys displayed, more or less for the same reason, putting any more on the screen would be wasted because no one could see them. I cannot make a guess about when this will happen, but we will probably be talking about it within 10 years.
Re:Bad Idea by xpccx · 2003-10-23 05:47 · Score: 1

As Carmack said ""The game tic simulation, including player movement, runs at 60hz, so if it rendered any faster, it would just be rendering identical frames."
It seems with DOOM, you can't get any benefit from higher fps since the inbetween frames are identical. Maybe what you notice has more to do with the difference between the refresh rate of your monitor and the fps of the game?

I think where this will suck the most if for those of us who are happy with 40fps but don't have the hardware to run Doom at 60fps.
Re:Bad Idea by Jagasian · 2003-10-23 06:04 · Score: 4, Insightful

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.
Re:Bad Idea by Rimbo · 2003-10-23 06:11 · Score: 1

" The 60fps is the average maximum that most of us can see. Considering that this is twice what movies are shown at,(actually its a bit more complicated, some theaters project each frame twice to reduce flicker) and just under the refresh rate for most monitors, I dont think this is a problem."

There's an important difference between frames on film and frames on a game. Frames on film contain an average of an object's movement over the time frame; frames on a game only have the object at that point. In English, film blurs movement. Ever see a game at 24fps? It looks terrible. But a film at the same framerate looks smooth. Even animated films use techniques to blur objects that are moving fast (Road Runner, q.v.).

What's happening is that people are using the power of new graphics cards to implement new features to make the environments more realistic -- lighting, curved surfaces, etc. Graphics card performance hasn't been about polys and framerate in a long time; all of the big new changes have been based around lighting models and new features.

Incidentally, this is one of the issues that killed off 3dfx in the marketplace; although their cards could stand toe-to-toe with the best Nvidia and ATI had to offer, 3dfx's Voodoo5 was still just fast 16-bit rendering hardware -- essentially the same technology that had been released in the Voodoo 1 years before. Meanwhile, everyone else had moved on to bigger and better things with transformation and lighting hardware integrated onto their boards.
Re:Bad Idea by xagon7 · 2003-10-23 06:14 · Score: 1

Samsung SynchMaster 955df.. 1024x768 @ 100Hz
Re:Bad Idea by SuiteSisterMary · 2003-10-23 06:22 · Score: 1

3dfx realized exactly what you're saying; thirty frames per second is fine, other than the fact that graphics are freeze frames, not film frames. hence, they tried to implement their T-buffer concept, to do motion blur and so on.

Then, the card improvement would be in features and power, not raw frame rate increase.

--
Vintage computer games and RPG books available. Email me if you're interested.
Re:Bad Idea by Rimbo · 2003-10-23 07:09 · Score: 1

3dfx was not exactly making waves with their cards' features at the time. With the Voodoo5, other than the T-buffer, they had just caught up to the feature set where Nvidia's TNT2 had been two generations earlier. Transformation and Lighting features were being implemented by everyone except for them, and they were left behind.

Thus, the story ended for 3dfx.
Re:Bad Idea by SuiteSisterMary · 2003-10-23 07:28 · Score: 1

They just had a different thrust. 3dfx went for film-like quality of motion without requiring massive amounts of horsepower, everybody else went for pretty lighting without requiring massive amounts of horsepower.

Me, I don't know off hand which I'd rather go for. Possibly the first one; like antialiasing, it can make something look much better without doing very much.

--
Vintage computer games and RPG books available. Email me if you're interested.
Re:Bad Idea by PainKilleR-CE · 2003-10-23 07:44 · Score: 1

The 60fps is the average maximum that most of us can see. ...
The only time I have heard this being a problem in computer games was with quick turns and other high speed events.

This just isn't true (the part about movies and refresh rates is close enough and mostly true). 60fps is simply a point at which most people see most actions as fairly smooth, when the framerate is consistent. The same is true of 30fps, but very few people would be happy to see the game capped there. Putting it close to the refresh rate is the most probable reason for capping it there. Most people can discern a change in frames at significantly higher rates than most computers can produce, but we don't need to display anywhere near the maximum framerates to make a clear, smoothly animated game/movie/etc. The only reason that you may have heard of problems with turns and so forth is simply because these are the types of things, when done at high speeds, that can cause framearates to drop or cause an increase in tearing when v-synch is disabled. If you cap your framerates to a fairly low number, the difference between your lowest framerate and your average framerate is smaller (assuming that you can hit the framerate cap most of the time). When framerates drop by significant amounts, there's a much greater chance that the player will notice, and this will make the game seem slower. This is what causes the perception among some people that 30 or 60 fps is simply not enough. When you're playing with v-synch off and you've got 120 or 100 fps and your framerate drops to 60 fps, it feels and looks like a stutter-fest because you've just cut your framerate in half. If you had been playing at 60 fps the whole time, it wouldn't matter as long as your framearate stayed at 60, because there's no change in the number of frames being rendered and displayed, and there's no loss of information in most situations.

I was wondering when some game maker was going to decided to cap the fps rate and concentrate on other things.

The only real concentration here is to correct a problem that is most easily corrected with a framerate cap. Otherwise, Carmack would have to learn how to make his physics and hit detection independent of the graphics display rate. Some games have managed this, some have not. Most people that actually learn game programming specifically learn that this is something you should do from day one. Trying to hack it in after the engine is built is a pain in the ass, if not nearly impossible, so you get a framerate cap that means you won't have the problems that existed in QuakeWorld, Quake 2, and Quake 3 when people acheived higher framerates.

We are close to the point where the computers we play these games on will all be able to exceed the 60 fps limit. (thank you Mr. Moore)

This is only the case when the computer is relatively new compared to the game. The technology that people like John Carmack develop will continue to push the limits of the hardware for a long time to come. There are still a lot more things that he would like to do with a graphics engine that simply can't be done at 30 fps on any current graphics card, and I'm sure he'd be the first one to give you plenty of minute details on those things, including how they should be implemented on the API and hardware sides.

By not having to draw more frames then 99% of the pop can see, the game can focus on gameplay, and as a side effect, eliminate slowdowns affecting the # of fps outputted, say when everyone in the room gets fragged by someone suiciding with a big grenade.

The gameplay is a combination of different effects, but when it comes to things like physics and AI is a simple matter of leveraging the CPU overhead that was freed up by the move to more powerful (and feature-filled) graphics cards. The more of the graphics processing that gets off-loaded the better, but the number of fps you limit the game to has little effect overall, because the graphics card is the part d

--
-PainKilleR-[CE]
Re:Bad Idea by ClioCJS · 2003-10-23 08:03 · Score: 1

I wonder how this affects my TV-output. I hear all this talk of refresh rates, but nothing address the fact that when I play Quake3, it is on both my monitor, and my 36' TV at once.
How does vsync affect this? No clue.
How does my tV render diff than my ATI card? No clue.

Last, but not least, when will they come out with a video card that supports 3-D glasses *FOR IT'S TV OUT*. I know this is technically hard, but 3-D glasses are useless for me now. If I had to pick between a 36" 2-D quake3 and a 15" 2-D Quake3 -- well -- bigger is better.

--
-Clio
Karma: Bad (mostly from not giving a fuck)
Blog: http://clintjcl.wordpress.com
Re:Bad Idea by TheLink · 2003-10-23 08:48 · Score: 1

Actually film's 24fps is pretty jerky. Especially when a scene is being panned. You can see the individual frames alternate.

Go to the cinema and judge the graphics as you would for a 3D computer game. Sure the resolution is good etc but 24fps really is crappy when compared to 85 fps.

As for 60fps being the max. It's not that simple. Eyes have variable sensitivity and it's not the same over the entire retina either. Most ppl can notice the flicker of a fluorescent lamp and that's like 100-120Hz (depending on AC). Even more if they don't look directly at it - and use their peripheral vision.

Even those that don't notice the flicker normally can perceive that the light given off is not as "stable" as other steady sources of light.
--
- Too many replies beneath your current threshold
Re:Bad Idea by Sevn · 2003-10-23 09:07 · Score: 2, Informative

True,

But with quake3 at least, you want to be running at least 125fps with vsync turned off so you can nail your strafe jumps. There are some jumps and other movement oriented things you simply can't do as well unless the game is running at 125fps or higher. I'll take some tearing for some frags.

--
For every annoying gentoo user, are three even more annoying anti-gentoo crybabies. Take Yosh from #Gimp for example.
Re:Bad Idea by Aggrazel · 2003-10-23 10:45 · Score: 1

"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 would imagine they would include a -bench type switch that will throw the game in a non-playable type benchamark mode where the cap will be lifted, just to run benchmarks on.
Re:Bad Idea by HuguesT · 2003-10-23 13:18 · Score: 1

I don't notice fluo flicker when the tube is new, I do when it gets old, I suspect it has to do with something else than just main grid frequency.

I do notice 60Hz monitor refresh rates and that's unbearable. 75Hz is Okay and 85Hz is perfect (for me). I think the cap at 60Hz might be a bit low.

How long before people work out how to uncap the refresh rate?
Re:Bad Idea by Hes+Nikke · 2003-10-23 14:03 · Score: 1

I'm lucky enough to not normally see florescent lights, but i do get headaches from them.

monitors otoh... i can't even stand 85 Hz....

and i'm stupidly getting into the IT business - with SAFE MODE! (it's not the color depth that gets to me, but i want to puke if i look at a 60 Hz screen for more then 2 minutes)

--
Don't call me back. Give me a call back. Bye. So yeah. But bye our, well, but alright we are on a shirt this chill.
Re:Bad Idea by Radius9 · 2003-10-24 04:43 · Score: 1

>>>>>>>>> His physics are independent of the frame rate. The physics are done right. I was actually confused when I read the /. article, then I read the real article on what the problem was, and it made more sense. For simplicity's sake, lets say that we have a ball travelling on a simple arc, with just gravity affecting it. What you normally do is calculate the ball's position on the curve, look and see what the last frame on the curve was, and create a pill shaped collision from the last point on the curve to the current point on the curve, then do collision detection on that. In this example, my physics are correct, as the arc is calculated using calculus, so I can figure out at what point the ball is at given any particlar time, and is independent of the frame rate. But lets say that the arc spans from 1-10 frames, with 5 being the peak of the arc. If I do my collision detection on frames 4 and 6, then when I generate the collision pill, it will cut out the peak of the curve. At that point, my collisions have become dependent on the frame rate, even though my physics are not. Calculating the collision volume for a sphere, moving along a simple arc, is trivial, so in this case, I could solve my problem rather easily. However, creating a collision volume for a 1000+ polygon character, using true polygonal collision, along a curve, is MUCH more difficult, and beyond the scope of a real time game.
Re:Bad Idea by PainKilleR-CE · 2003-10-24 05:24 · Score: 1

Calculating the collision volume for a sphere, moving along a simple arc, is trivial, so in this case, I could solve my problem rather easily. However, creating a collision volume for a 1000+ polygon character, using true polygonal collision, along a curve, is MUCH more difficult, and beyond the scope of a real time game.

I can understand that it would be significantly more difficult to create the collision volume when using polygonal collision (rather than hit-boxes), but they weren't even getting it right with hit-boxes.

The problem described for Q3 is a combination of simple rounding errors by converting from floats to ints in the movement code, using a linear approximation based on previous position (rather than a continuous calculation based on actual location and time variables), and coupling the time-step to the framerate. Quake 3 eventually 'fixed' this in a patch by forcing the time-step to 125Hz. Doom 3 apparently is forcing the time-step to 60Hz (or perhaps is using 120Hz or 180Hz and forcing the framerate to 60fps to simplify the rendering).

In theory, though it would cause some slow-down (not sure how it would affect it as a real-time game, I'd have to do significant testing), you could do simplified prediction for most cases and then more accurate prediction (even in a smaller area) for actual collisions (or predicted collisions, which could still be misses). That should mean that the only time detection is more intensive than the previous hit-box model would be with predicted collisions, though the time savings from complete misses should make up for it.

In fact, for something as simple as deciding whether or not a jump lands at a certain height, you're really comparing the path of a cube anyway, as you only need to determine if the height of the jump was enough to land on the platform and if anything prevented the landing in flight (ie an obstruction at head-height or lower, although you may also have to deal with other players and/or projectiles while in flight).

The biggest point, though, beyond all theoretical tangents, is that whatever shortcuts are made to go away from true polygonal collision and true curves should be consistent for every player in the game. The simulation of the world behind all of the rendering should let every player jump just as high as any other player, regardless of whether or not they can render enough frames to get them there. Just because I reach the proper height to get to that platform between frames 4 and 5 of my jump (and am therefore lower than the platform on both frames 4 and 5) doesn't mean that I shouldn't land on the platform, because the physics simulation should know that the curve of the jump would have put me on that platform before frame 5 was rendered.

--
-PainKilleR-[CE]
Re:Bad Idea by TonyMillion · 2003-10-24 07:07 · Score: 1

This isn't strictly true. You could easily put the mouse input code into a seperate thread which can respond to the mouse input as soon as it comes in, and could take this input and turn it into a vector/percentage/somethingelse, which the game engine working at 60hz would read from.

This is just one solution, there are plenty more I'm sure.
Re:Bad Idea by veritron · 2003-10-24 08:19 · Score: 0

I'm even worse. I can actually see florescent lights discretely flicker if there's only one in a room. I can tell the difference between 100hz and 120hz and prefer the latter.
Re:Bad Idea by suraklin · 2003-10-24 13:04 · Score: 1

Most ppl can notice the flicker of a fluorescent lamp and that's like 100-120Hz (depending on AC).

Actually a fluorescent light runs at 60Hz. The voltage is in the 120 range. Try setting a desk lamp on your monitor.
Re:Bad Idea by TheLink · 2003-10-25 04:11 · Score: 1

Simplistically speaking there are 2 peaks in the AC wave. One positive and one negative. The flourescent lamp lights up when it is far enough from zero.

And so how often the light lights up is 2 x 50hz or 2 x 60Hz, depending on your AC Hz.

There are high frequency flourescent lamps but those tend to be a lot less common.

If I've got that wrong, do explain it to me.
--
- Too many replies beneath your current threshold

It would... by Dot.Com.CEO · 2003-10-23 03:47 · Score: 2, Funny

if the engine was capped at 2fps...

--
Mother is the best bet and don't let Satan draw you too fast.

Re:It would... by Anonymous Coward · 2003-10-23 03:56 · Score: 0

Yeah I think people are failing to realize you still need the hardware to get you up to 60fps, that hardware may not even be out yet the way Id is talking
Re:It would... by GreyWolf3000 · 2003-10-23 06:14 · Score: 1

A g400 plays quake3 *fine*
I dunno how much more doom3 is going to need in terms of power.

--
Slashdot: Where people pretend to be twice as smart as they really are by behaving like children.
Re:It would... by blincoln · 2003-10-23 06:37 · Score: 1

I dunno how much more doom3 is going to need in terms of power.

A lot more. The last I read, it was going to run at about 30fps on a GeForce3.

--
"...always new atoms but always doing the same dance, remembering what the dance was yesterday." -Richard Feynman
Re:It would... by PainKilleR-CE · 2003-10-23 07:07 · Score: 1

A little over a year ago Carmack stated that the Parhelia would run Doom 3, just not nearly as well as the then-current nVidia and ATI parts.

If I remember correctly, the Parhelia is a significantly newer card than the g400, just as Doom 3 is a significantly newer engine than Quake 3 (although they've been working on the engine for 3 years).

Cards that were putting out 100+ fps in Quake 3 quite easily are being crippled by Doom 3, if they work at all, so I'd say good luck, but I don't think there's a chance.

--
-PainKilleR-[CE]
Re:It would... by GreyWolf3000 · 2003-10-23 07:34 · Score: 1

Thanks for the insight...I guess I'll have to ditch this thing after all. I'll probably get an ATI low-9000's, so it plays nicely with Linux.

--
Slashdot: Where people pretend to be twice as smart as they really are by behaving like children.
Re:It would... by Dot.Com.CEO · 2003-10-23 08:04 · Score: 3, Informative

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.
Re:It would... by GreyWolf3000 · 2003-10-23 10:43 · Score: 1

Unfortunately no DRI support for anything above 9200. I'll have to go 8500; I don't want to mess with Binary drivers. Thanks for your help.

--
Slashdot: Where people pretend to be twice as smart as they really are by behaving like children.
Re:It would... by Anonymous Coward · 2003-10-27 03:49 · Score: 0

In gentoo you can just emerge nvidia-drivers and it'll emerge it. gentoo is just great! i emerged the ati9600 too!

It would be nice... by advocate_one · 2003-10-23 03:47 · Score: 1

if my hardware could get anywhere near 60fps...

Yet another way to feel inadequate... insufficient horsepower to make the framerate cap...

anyway... what the heck... this 850MHz Duron box runs SuSE 8.2 perfectly well... s'pose I'll have to save up for a big box just to play the new games on...

--
Donald 'Duck' Dunn: We had a band powerful enough to turn goat piss into gasoline.

Re:It would be nice... by Anonymous Coward · 2003-10-23 07:26 · Score: 0

Like having insufficent hardware to reach that cervical cap. Yikes.

Best Quote of the 2nd Article by TheFlyingGoat · 2003-10-23 03:48 · Score: 5, Funny

Gotta love the sense of humor. :)

The first thing we realised was like: 'Damn, people are hard to kill in Doom 3 multiplayer. Why is that?' And we looked at the damage values, the hitpoints, the armour, but eventually we realised - we're just missing. We're lousy shots."

--
You have enemies? Good. That means you've stood up for something, sometime in your life. --Winston Churchill

Re:Best Quote of the 2nd Article by waaka! · 2003-10-23 04:41 · Score: 1

Well, that's what happens when you have per-polygon hit detection--it's not just a hitbox anymore. All of a sudden, you have the ability to shoot under people's arms, next to their heads, and between their legs.

I didn't get to play Doom III (didn't go to QuakeCon or anything), but that kind of precision sounds really cool.
Re:Best Quote of the 2nd Article by PainKilleR-CE · 2003-10-23 04:52 · Score: 1

Not to mention that per-polygon hit detection also reduces splash damage. Considering the number of people I've seen in almost any Quake-based game that rely heavily on the rocket launcher and the shotgun, I can only say this is a good thing, but that there will be complaints.

--
-PainKilleR-[CE]
Re:Best Quote of the 2nd Article by Winterblink · 2003-10-23 07:19 · Score: 1

Doesn't really matter how you design a first person shooter anymore, there will always be a sizable percentage of people who will bitch about the various choices the developers make. Personally, I think anything devs do to reduce reliance on one single super weapon is a good thing, but there IS such a thing as overbalance.

--
"I'm a leaf on the wind. Watch how I soar."
-Hoban Washburn
Re:Best Quote of the 2nd Article by TheRoachMan · 2003-10-23 09:05 · Score: 1

If you have seperate hitboxes for chest, head, shoulder, upper arm, lower arm, doesn't that mean you can shoot under people's arms, next to their head and under their legs? I'm assuming that hitboxes are animated like the model (eg if a player jumps you see his legs and arms move, and the hitboxes tied to these parts move as well). I mean, per polygon hit detection sounds really cool, but I think it's a bit overrated. Why use per polygon hit detection if you could get the same result by using more and smaller -and thus more accurate- hitboxes. It requires less calculating power and it's almost equivalent to per poly hit detection. If i'm totally missing the point here, tell me.
Re:Best Quote of the 2nd Article by chia+mr.+t · 2003-10-24 07:29 · Score: 1

i'm curious about the implications of per-poly hit detection - does this mean that everyone will play with the doom3 equivalent of the "bones" model and noone will ever play with the doom3 equivalent of the "tank jr" model in the future? i assume smaller models will have a huge advantage over large ones compared to now where the hit box is the same for ever model. or am i missing something?

It doesn't change anything except for benchmarks by j-turkey · 2003-10-23 03:49 · Score: 4, Informative

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

--

-Turkey

Benchmarks, etc. by BrookHarty · 2003-10-23 03:50 · Score: 4, Insightful

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...

Re:Benchmarks, etc. by TwistedSquare · 2003-10-23 04:37 · Score: 2, Insightful

Yes it does seem to be bad code design. Judging from the post, the problem seems to be caused by some combination of premature rounding to integers (performance optimisation?) and also only being able to measure the time in milliseconds which seems to cause a distinction between 60 FPS (1000/60 rounded is 17), and say 61 FPS (1000/61 rounded is 16).
I thought windows now measured time in better intervals than that using its high-performance timers (using QueryPerformanceCounter) so I'd say this looks more like bad coding than insufficient hardware. It was fixed in a later patch I gather so looks very likely...
Re:Benchmarks, etc. by NanoGator · 2003-10-23 08:11 · Score: 1

" Cant really use Doom3 as a benchmark, unless you can override the 60FPS cap."

Sure you can. Use motion blur. The more in-between frames you have to create the blur, the better the blur gets. If you have a 5-frame motion blur, then you've got roughly 300fps of information there, not including the time it takes to average the frames together. This is assuming, of course, that Doom 3 can or will have any such feature.

Frankly, I prefer this as a benchmark anyway.

--
"Derp de derp."
Re:Benchmarks, etc. by Happy+Monkey · 2003-10-24 08:12 · Score: 1

You can just add more stuff to the Doom 3 level until none of the cards can hit 60, and see which one gets closest.

--
__
Do ya feel happy-go-lucky, punk?

warning by kayen_telva · 2003-10-23 03:51 · Score: 0

c+vg requires blood samples and your first born to read
any mirrors ??

hey!! by m00by · 2003-10-23 03:55 · Score: 1

it's ab00t fscking time they got some sense into them. nobody needs 300 fps on quake 3, not that any computer in existence could get close to that in doom 3 =D

Re:hey!! by Anonymous Coward · 2003-10-23 04:40 · Score: 0

ab00t fscking time

u'r kool
Re:hey!! by Anonymous Coward · 2003-10-23 06:17 · Score: 0

he's more than kool, he's k-rad 31337...

Hey look, it's k-rad 31337 demo muzak!
Re:hey!! by UltimaL337Star · 2003-10-23 07:41 · Score: 0

wait till Virginia tech gets a os X port
Re:hey!! by baneblackblade · 2003-10-23 13:19 · Score: 1

60 FPS is plenty to play doom 3. after tinkering with the alpha for more than six months and making my own deathmatch maps, I can assure everybody that even 40-50 FPS would be fine. the game runs beautifully between 25 and 30, but after 55 there isn't much of a difference. Above 65 is absolutely useless; almost no change whatsoever between 60 and 70 FPS, so don't worry!!

Deathmatch by aridhol · 2003-10-23 03:57 · Score: 4, Funny

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.

Re:Deathmatch by sYn+pHrEAk · 2003-10-23 14:57 · Score: 1

When I played at QuakeCon, everyone was the default Doom model we've all come to know and love, but in a variety of colors. I remember Green, Red, and Blue. I don't remember the fourth though.

I like the idea... by Daniel+Wood · 2003-10-23 03:58 · Score: 3, Interesting

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...

Re:I like the idea... by Anonymous Coward · 2003-10-23 07:16 · Score: 0

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 PENIS IS BIGGER THAN YOURS.
Re:I like the idea... by dew-genen-ny · 2003-10-23 22:04 · Score: 1

Someone with mod points mod this up +funny....

--
tom-george.comBecause geeks rate higher t
Re:I like the idea... by cuban321 · 2003-10-27 01:45 · Score: 1

3200+ XPs can SMP?

60 Hz Interference Patterns by yancey · 2003-10-23 04:00 · Score: 2, Insightful

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!

Re:60 Hz Interference Patterns by Lukey+Boy · 2003-10-23 04:27 · Score: 4, Informative

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.
Re:60 Hz Interference Patterns by PainKilleR-CE · 2003-10-23 04:48 · Score: 1

He didn't say anything about controlling your refresh rate with the game code, so it's unlikely that'll be an issue, as long as you have your refresh rate set properly.

Look at it this way, with v-synch on if your card can produce a solid 60 fps average or higher, at least it's less likely that you'll actually drop any of the 60 frames at 72hz.

--
-PainKilleR-[CE]
Re:60 Hz Interference Patterns by PIBM · 2003-10-23 06:29 · Score: 1

What if you use a monitor that give out 85hz at 1600x1200 (NEC FP955) .. would not you want the game to calculate it's physics every 1/85th of a second, and render it ? If you run at 1/60th, some frame will be doubled to fit in between .. don't seem pretty good ! And no, I won't use 60hz.. but anyway, my CPU won't hold it ... FOR NOW :)
Re:60 Hz Interference Patterns by PainKilleR-CE · 2003-10-23 06:43 · Score: 1

Perhaps, if the system could handle it consistently. On the other hand, if the system can handle 85 fps only 50% of the time and drops 10-25% of the time to 40fps or less, would you prefer to cap at 60fps and only suffer a 33% hit in the performance 10-25% of the time or keep it at 85 fps and suffer a 50% hit in the performance 10-25% of the time?

It didn't take me long playing online to decide that I was better off with a lower framerate most of the time to minimize the difference between the highest and lowest framerate being displayed.

On the other hand, I would prefer that the game calculated it's physics at a rate independent of the framerate, because the two do not have to be dependant on one another. The frame being rendered should simply be the graphical representation of the game world as it is when the rendering started. The physics should be calculating changes in the game world as needed, regardless of framerates. You don't need to re-calculate the precise trajectory of a bullet every frame to render it's path, nor does the accuracy of the path need to be decided by how fast that path can be rendered.

If I calculate the game state 200 times per second and only display it 60 times per second, or 50 times per second (for a more accurate division of frames vs physics calculations per second), does it matter that the game state was calculated 3 or 4 times without being rendered? No, it just means the rendered state may be more accurate because there is no rounding involved that isn't being performed on other systems. It's not like the Quake games have been pegging mid-to-high-end CPUs since moving to OpenGL renderers, either, so it's not unreasonable to calculate physics more often than is strictly needed.

--
-PainKilleR-[CE]
Re:60 Hz Interference Patterns by Phronesis · 2003-10-27 02:43 · Score: 1

Just to be pedantic, fluorescent lights flicker at 120 Hz because there are two zero-crossings of the line voltage in each cycle.

Before you get your panties in a bunch... by Hellvetica · 2003-10-23 04:07 · Score: 5, Informative

From here: http://www.shacknews.com/ja.zz?id=8743907

Alright, I'm going to try and break this down... there are actually 3 entirely seperate things people are talking about here: simulation frame rate, rendering frame rate, and monitor refresh rate.

'Hurtz' or 'hz' are a universal term that just means "X whatevers per second", so having 60FPS means your card is rendering at 60hz.

Now, in the post Carmack says nothing about monitor refresh rate, so that really isn't anything to worry about. Your monitor will still refresh at whatever you want it to refresh at, within it's capabilities. The other two things, the simulation rate and the rendering rate are both going to be locked at 60hz/FPS.

Let me try an analogy. Let's say you are in a room, and next door there is a chess match. The frequency at which the chess pieces are moved is the simulation or game rate. Now if you have someone taking a polaroid snapshot at a certain rate, that is the rendering rate, what everyone knows as FPS. If someone else is taking those photographs and bringing them to you, that is like your monitors refresh rate.

This isn't a perfect analogy, but it's good enough to illustrate the point: if the chess pieces only move once per minute, no matter how often someone takes a picture of it, it will always look the same.

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.

Re:Before you get your panties in a bunch... by Goodbyte · 2003-10-23 04:32 · Score: 2, Insightful

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.
Re:Before you get your panties in a bunch... by Anonymous Coward · 2003-10-24 04:38 · Score: 0

Why would I listen to an "expert" that can't even spell Hertz right?

This is probably good. by molo · 2003-10-23 04:22 · Score: 3, Informative

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.

Re:This is probably good. by Goodbyte · 2003-10-23 04:47 · Score: 1

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.

They are fixing it now -- by locking the frame rate. What I think is the source of the problem is:
floating point mathematics has finite precision
it is hard retrieve accurate timings when the framerate is high
fast floating point operations are less accurate You could possibly trade accuracy for speed, but then the frame rate would drop, specially for low-end machines.
Re:This is probably good. by Anonymous Coward · 2003-10-23 05:07 · Score: 0

"floating point mathematics has finite precision"

Yes but here it does not really matter.

"it is hard retrieve accurate timings when the framerate is high"

No the exact opposite. At higher frame rates the physics model becomes more and more accurate so acceleration and speed is matched to real life more accurately. At lower frame rates the samples are so large that acceleration is applied much less than in a constant time cycle. So you travel farther and get more speed from accelerations as the samples get smaller.

"fast floating point operations are less accurate You could possibly trade accuracy for speed, but then the frame rate would drop, specially for low-end machines."

Not sure what you mean by "fast" floating point operations.
Re:This is probably good. by z01d · 2003-10-23 15:57 · Score: 1

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.

it's not about physics model, it's about..um, programming model?

they're actually tring to fix jump-related-to-fps issue now, the thing is, engine is only able to check user input before/after rendering a frame, therefore the fps affect the in-game control.

cap the fps is not really a final solution, if the machine can not render 60fps, the player's movement is still affected. multi-threading seems like the only way to ensure constantly scanning for input, but oh my god, there's so many things need to be synchronized, and the performance will be...doomed.
Re:This is probably good. by SQLz · 2003-10-24 01:02 · Score: 1

This just makes me say to id: fix your damn physics model!

And the physics engine matters here why?

DOOM III BENCHMARKS by Militant+Libertarian · 2003-10-23 04:29 · Score: 1

Right Here

now, some say THG is bias towards nvida. Others will probably say that this is just a 'special preview' and therefore blah blah blah

either way, unless Doom III finds itself faster than this skimmed down release, most of the current cards can't acheive 60FPS anyway

--

I fear nothing but my government. Vote Libertarian.

Wow... by ArmenTanzarian · 2003-10-23 04:49 · Score: 2, Insightful

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'.

Re:Wow... by PainKilleR-CE · 2003-10-23 05:41 · Score: 1

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...

I think the reference has nothing to do with the technical points, but rather with the point in time of the development of the game. Id typically develops their engines first and then straps a game around them. At this point, they're in exactly the place that you are discussing: plot, character design, level design, difficulty, possibly menus and goodies. The engine is for the most part done (probably still some tweaking for various cards), so the majority of their current focus is on gameplay elements.

--
-PainKilleR-[CE]

Benchmarking by dpilot · 2003-10-23 04:56 · Score: 1

I seem to remember that even in the old Doom days, if you looked at the raw realtics and gametics you could come up with numbers higher than 35fps, even though the original engine was capped there. It still supplied some sort of benchmark data above the cap rate.

Besides, when Doom frame rates started going up too far they simply used more stressful levels for better benchmarks.

I've no doubt that some sort of many-monsters, many-colored-light-sources, many-other-things-too levels can be built that will stress today's fastest systems well under 60fps. (probably unplayable on my fastest system)

--
The living have better things to do than to continue hating the dead.

What extras are going be standard now? by kabocox · 2003-10-23 05:00 · Score: 1

Now that he is "standarizing" the framerate, what features do you think will be turned by defualt on and stress the graphics engine the most? You know he will think of something.

probably not by Ender+Ryan · 2003-10-23 05:00 · Score: 1

Just because gameplay is locked at 60, that doesn't mean you can run a timedemo at higher speeds.

Hopefully, it would be a shame for id to lose their standing as the default benchmark for x86 PCs.

--
Sticking feathers up your butt does not make you a chicken - Tyler Durden

Re:probably not by recursiv · 2003-10-23 05:25 · Score: 1

But that's not stressing the video card any more. That's stressing the cpu and memeory.

--
I used to bulls-eye womp-rats in my pants
Re:probably not by PainKilleR-CE · 2003-10-23 05:37 · Score: 1

if timedemo permits the game to render at higher framerates, what it stresses will be completely determined by the requirements of the game itself. In the Quake games, this was typically the video card.

--
-PainKilleR-[CE]

Bad coding style? by kwench · 2003-10-23 05:09 · Score: 3, Insightful

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...

Re:Bad coding style? by AllUsernamesAreGone · 2003-10-23 06:53 · Score: 1

Actually, only later Amiga programmers used timer.device, the earlier ones just grabbed the system clock from the hardware directly - less overhead.

Mind you, on pentiums and later you can use (IIRC) the RDTSC instruction, which gives you the number of clock cycles since the last reset as a 64bit number.
Re:Bad coding style? by falcon5768 · 2003-10-23 07:53 · Score: 1

HA I remeber the turbo button, know what was great with some of those old games like Tie Fighter, putting it on a faster machine than it was designed for and seeing what happened, I remeber vividly my Uncle putting it on his brand new Pentium and having the speech in the game come out sounding like a Ewok on crack when the Imperial trooper asked for you name

--
"Slashdot, where telling the truth is overrated but lying is insightful."

Bad solution by MobyDisk · 2003-10-23 05:15 · Score: 4, Insightful

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:
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 - .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.

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.

Re:Bad solution by PainKilleR-CE · 2003-10-23 05:46 · Score: 1

Far be it for a lowly coder to question Mr. Carmack, but this seems like a hack.

Don't worry, it doesn't just seem like a hack, it actually is a hack.

Unfortunately, there aren't many people out there in the same league as Carmack, so it may be a while before we see him finally decide to fix this properly, rather than just capping the framerate. Personally, I prefer the capped framerate to nothing at all, but I'd much rather see it fixed properly.

All of that being said, I haven't gone into say the Quake or Q2 code and tried to fix it myself, so I'm just spinning my wheels.

--
-PainKilleR-[CE]
Re:Bad solution by Mike+Hawk · 2003-10-23 05:48 · Score: 1

If someone makes a "mod" that breaks the game, why should I care? I have a simple solution, don't use the mod, silly.
Re:Bad solution by gl4ss · 2003-10-23 07:06 · Score: 1

*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.*

unfortunately when doing videogames you have to draw the line somewhere.

oh yeah, there's awful lot of hacks used in coding games(they're used to make the games look cool and playable), they've been used for as long as games have been made. heck, there's awful lot of games that have their whole engines expolarated from some single neat trick that quite well would qualify as a 'dirty little hack'.

**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.*

doing the entire thing from the beginning every frame would be slower?? NO SHIT SHERLOCK. it would end up being much more complicated than what it sounds by taking a quick look into it.

anyways, i'd except them to actually to "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." or something pretty much equivalent(i wouldn't except them to actually try to run the physics engine 60hz on every machine), it's just that they're locking it to 60/s roof.

and had they not told it most of the people who never dwelled into doing mods(or whatnot) for the engine would never known of it.

and oh boy are there lot of experts who know what this does to the engine.

and oh yeah, there's lots of bull in the other posts that has no basis whatsoever on the locking the framerate to a known maximum issue. a much bigger issue is that slashdot is getting slashdotted by itself. error 500 my shiny metal ass.

--
world was created 5 seconds before this post as it is.
Re:Bad solution by etymxris · 2003-10-23 07:38 · Score: 1

It is easy to recompute from the initial position for each iteration if you know that no new information is going to influence the equation after the player has jumped. However, this assumption doesn't hold, as was noted in the explanation. A rocket may come zooming in and push the player off his path. Or the player may exert "air control".

The only way these "free will" elements can be accounted for with a recomputation from the initial position is if every acceleration vector is stored for the entirety of the player's airborne trip. That is, a movement LEFT will have to be stored, and then if the player moves RIGHT that also has to be stored. Then you have to recompute from the beginning:

Jump vector - acceleration + LEFT movement + RIGHT movement + influence of striking rocket + air vent influence, etc.

It's not impossible, but it is not a simple coding change. Even the best throw in a stupid hack every now and then, but I don't think this is one of them.
Re:Bad solution by Dr.+Sp0ng · 2003-10-23 10:30 · Score: 1

y1 = y0 - .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.

That works for your simple example, but many problems in physics simulation have no closed-form solution, and numerical integration is the only way to go about solving the problem. Numerical integration always introduces some error, depending on the method of integration used, and the larger the timestep, the larger the error (at some point, if the timeslice is too large, the simulation will blow up).

Physics simulation is very dependent on timeslice size; if you want a reliable, consistent simulation, you need to have a constant framerate (or at least a constant physics timeslice). Tying the rendering framerate to the physics timeslice is a good idea, as it'll limit rendering artifacts caused by duplicate or skipped frames.

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.

That's incorrect. A well-designed engine will do CPU-based tasks and GPU-based tasks at the same time. The CPU can pass geometry data to the GPU and then go on about its business while the GPU does its work (the GPU can also do more than one thing at the same time - it'll do its transform work and its rasterizing work at the same time - that's what's nice about a pipelined setup). Whichever takes longer (out of the CPU tasks, transforms, or rasterizing) is what the limiting factor in the framerate is. There is always a single bottleneck, and it's always one of these 3 stages. They go at the same time, and ideally, all use the full amount of processing time they have as opposed to sitting around idling while the remainder of the pipeline completes its task.
Re:Bad solution by skookum · 2003-10-23 17:52 · Score: 1

I think you're misunderstanding WHY the frame rate was capped.

My interpretation of this matter is that the game physics engine uses a FIXED and CONSTANT 60Hz time scale. So no matter how fast or slow the graphics are drawn, the piecewise linear simulations are all done with constant delta-t's. Everyone's jump follows the same trajectory, every rocket lands in the same location, etc. regardless of how many snapshots of this motion are displayed (i.e. frame rate.)

The implication of this is two-fold:

1. The motion (acceleration, etc.) is independent of frame rate, it has its own timebase and so calculations do not depend on frame rate in the least. This is likely the whole reason for doing it this way.

2. Frame rates higher than 60 FPS would result in simply drawing the same frame again, since the underlying physics model only updates that fast. Therefore the cap is in place just to prevent this extra pointless work being done. Even if someone were to remove the artificial cap, it would not matter at all because all they'd be doing is drawing more duplicate frames, which probably would consume resources that could be better spent rendering more detail in each frame.

In other words... by stienman · 2003-10-23 05:20 · Score: 5, Insightful

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

Re:In other words... by Jagasian · 2003-10-23 08:16 · Score: 1

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.

If Doom 3 is going to be implemented anywhere near the same as the previous Quakes are implemented, then user input is checked each frame... and mouse looking is client-side and independent of the game world. So a 60 FPS cap would effectively cap your mouse polling rate to 60hz, which is half as smooth and twice as laggy as the 125hz that your mouse can spit out.

This is a huge negative for game controls! The benefit is that it levels the playing field somewhat... but at the cost of smooth, responsive mouse look.

Anyone that has used a PS2 mouse at its typical 60hz polling rate and upgraded to a usb mouse (125hz) or used a polling rate hack to jack up their rate to 200hz will testify to the difference in quality of control.

A 60hz cap doubles your mouse input lag from 8ms to 17ms! While your eyes have trouble distinguishing such small time differences, you can "feel" the difference when mousing with 8ms lag versus 17ms lag.
Re:In other words... by bios10h · 2003-10-23 08:32 · Score: 1

...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.

You obviously aren't aware that new maps WILL be created by mappers and new mods will use the engine so it needs to be much more flexible than "we'll do smart level design to cover". Doing integer math is really really faster HOWEVER I'm not sure yo can do appropriate physics calculations with only integers. Especially when you need to push down floats to the gpu, it doesn't make much sense do calculate everything in integers then cast to floats for the rendering. Well, maybe it does, I don't know :)

"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."

I think EVERY game engine should have an update "pass" (move the guys around based on speed, collisions, physics, ballistics, etc) and a render "pass". The update pass must be at a fixed frequency (to fix problems like explained in the article by Carmack) but I see no reason to have the rendering at a fixed frequency. You only need to interpolate between the last update bones position and the next key-framed bone position. This way you get a smoother movement of the mesh for faster machines.

just my 2 cents
-bios10h
Re:In other words... by Lord_Dweomer · 2003-10-23 09:28 · Score: 1

"Or just turn off the flourescent lights. You want a terrifying experience anyway - who wants to play with the lights on?"
I'm scared of the dark you insensitive clod!

--
Buy Steampunk Clothing Online!
Re:In other words... by The+Dark · 2003-10-23 12:00 · Score: 1

Hey, I'm not that scary.

--
sig's not here
Re:In other words... by stienman · 2003-10-23 12:00 · Score: 1

You only need to interpolate between the last update bones position and the next key-framed bone position.

Ah. So what you're really saying is:
Do physics for frame one
Do physics for frame two
Display frame one
Interpolate between two frames and get an intermediate frame
Do the middle frame
Do the second frame

So you're always one frame behind, and what's on the display has little to do with the controls you are pushing now?

You can't interpolate between two things if you don't have the second thing. If you make everything go in a straight line and do 'guesses' then the frames will look jumpy, since the straight lines or guesses won't really be what your character di in between frames. If you actually want to calculate it a bit more so it's not so much guessing, then you've got half the physics calculations done anyway, so you might as well do all of them.

But then you get back to the problem of round off errors in a variable frame rate engine not being consistant.

-Adam
Re:In other words... by stienman · 2003-10-23 12:17 · Score: 1

A 60hz cap doubles your mouse input lag from 8ms to 17ms! While your eyes have trouble distinguishing such small time differences, you can "feel" the difference when mousing with 8ms lag versus 17ms lag.

No need to use caps, young man. You're beginning to sound like an audiophile who thinks tubes are better, and records are better than tapes and CDs.

There is no doubt that on the old games you can 'feel' the difference in lag between 60 and 125hz update rates.

The new game, however, does not have the old engine. The new game, it appears, is 'slower' and not so much based on 'fast twitch' shooting style that the old games revolved around. I supect that what this means is the game is more realistic - conforming to a slightly better real-world feel. This real world feel will not need really fast mouse updates.

Besides. I dare you to change the direction of your hand at 60Hz.

The 'feel' you are talking about, I imagine, is the feedback loop you've developed between your eyes and your hands. You're brain knows how long it takes for a movement on the hand to affect the screen image. The problem is overshoot/overcorrection. Your brain adapts a little to the lag to prevent overcorrection, but you can only change the movement of your hand so fast. So a faster read and react rate on the part of the computer enables you to do a little less work, both physically and mentally since the lag is not so bad.

If, as the articles seem to say, the game is 'slower', and aiming correctly is more critical than 'getting the first shot in hte general direction' is, then the 60Hz update rate locked to the display frame rate will actually shorten that lag, and make it easier for your brain to computer, which will make it a completely different game experience anyway.

-Adam
Re:In other words... by Anonymous Coward · 2003-10-23 14:04 · Score: 0

Besides. I dare you to change the direction of your hand at 60Hz.
Please post links to scat pr0n.
Re:In other words... by Cuthalion · 2003-10-23 14:28 · Score: 1

So you're always one frame behind, and what's on the display has little to do with the controls you are pushing now?

On average you're half a frame behind. Which is 1/120 second. Which is not very long.

--
Trees can't go dancing
So do them a big favor
Pretend dancing stinks!
Re:In other words... by Jagasian · 2003-10-23 15:18 · Score: 1

I played Doom 3 deathmatch at this year's Quakecon. The mouse look was far less smooth than Quake 1 and 3's mouse look. I figured it had something to do with low framerates... something which would eventually be fixed with ultra fast 3D accelerators. The fact that Id Software is capping the FPS to 60hz means that there will be no fix... mouse looking in Doom 3 will be inferior to Quake 1 and Quake 3.

In fact, Quake 1 has the best mouse look to date because once it became opensource, developers implemented something they call "Advance Mouse Smoothing". This is a zero latency mouse movement interpolation/prediction algorithm that makes mouse looking hands down superior to any other first person shooter to date!

Other first person shooters might have mouse smoothing algorithms, but they add lag to the mouse movement. The mouse smoothing algorithm coded by Id Software, for Quake before it went OSS does just that: it makes movement smoother but more lagged. 1 step forward, 2 steps back.

It is just a matter of fact that a 125hz mouse with a 125hz frame rate in Quake 1 or Quake 3 is superior to 60hz Doom 3. Note that Id Software made the same mistake with Quake 2, where mouse polling was limitted to something like 40hz... even worse than Doom 3's 60hz!!!

Needless to say, Id Software fans were upset that the sequal was quantifiably inferior to the original.

You bring up the point of changing mouse direction at 60hz... that is not the point. The point is best proved by drawing a medium sized circle using your mouse and one medium speed circular motion with your hand... while using a paint program. Do this with a 60hz sample rate and do it again with a 125hz sample rate. Zoom into the bitmap of each image and compare. Note that the 125hz circle is much smoother and less jagged.

The same test can be done by drawing a diagonal line at medium to fast speed. Of course, the faster the speed, the more jagged the line will get, but the 60hz line will always be far more jagged than the 125hz one.

In the end, serious gamers that want the best controls possible will continue to play games like Quake 1 and Quake 3. In fact, since Quake 3 will most likely be opensourced soon, it too will be getting advanced mouse smoothing - putting at the same level of quality that Quake 1 has been at for a few years now!

60? by mojowantshappy · 2003-10-23 05:30 · Score: 1

Oh no, not a cap at 60! I would lucky to get beyond 30 FPS.

--

This page was generated by a Barrel of Circus Midgets, and that is the way I like it!!!

Re:It doesn't change anything except for benchmark by jjhlk · 2003-10-23 05:49 · Score: 1

You can probably see 120 FPS pretty easily, though you might not conciously notice a difference. To test that you would need to have an image flashed at you at 1/120th of a second.

What the hell!? by nomel · 2003-10-23 06:26 · Score: 0, Redundant

Why doesn't he just fix the code? I can tell a difference between 60 fps and higher. It's easy to test, just set your refresh rate to 60 Hz and see if you can see nice flickering.

Re:What the hell!? by PainKilleR-CE · 2003-10-23 07:54 · Score: 1

Why doesn't he just fix the code?

Because it's a lot harder to seperate the framerate from the back-end after the engine's coded than if you do it that way from the start. Why he did it this way in Doom 3 I couldn't tell you, except that it's the way he did it in the rest of his engines, too.

I can tell a difference between 60 fps and higher. It's easy to test, just set your refresh rate to 60 Hz and see if you can see nice flickering.

Umm, you're not testing whether or not you can see the difference between 60 fps and higher, you're testing whether or not your lights run at 60 hz, and since you see the flicker, they do.

A real test is to drop a random frame into an animation that will run at 60 fps and see if you can see the random frame. Almost everyone can. On the other hand, that has nothing to do with whether or not 60 fps is an acceptable framerate for a game, because even 30 fps is, as long as it's consistent (lower than 30 fps can give you some very real problems, but regardless of the framerate you'll never see a real flicker in the images displayed as long as your refresh rate is not being interfered with by lighting conditions).

By the way, I get headaches when my monitor runs at 60Hz refresh rates, but since games simply display the same frame over again, it's not like your monitor goes blank between frames (like a movie does, though most movie projectors display the same frame 2 or 3 times). If your game is running at 60 fps and your monitor is displaying the game at 72Hz it just means that your card isn't sending a new image to be drawn for 12 of your 72 cycles in that second, it's just redrawing what was already there. Mine's currently running at 100Hz at 1280x1024@32bpp, but that doesn't mean there's anything new from the first image displayed to the second, or that I'll notice unless there is.

--
-PainKilleR-[CE]
Re:What the hell!? by nomel · 2003-10-23 19:34 · Score: 1

With the monitor refresh test, I was just showing that the eyes can detect visual changes at 60 changes per second.

But, I agree.

That's one of the reasons I love LCD's so much. Sure the pixel refresh is slow and blurs, but it sure is nice on the eyes for reading and whatnot. :)

Re:It doesn't change anything except for benchmark by GreyWolf3000 · 2003-10-23 06:30 · Score: 1

Or they can run them in rooms with such complicated surfaces and lighting that even the newest graphics cards won't maintain 60fps.

--
Slashdot: Where people pretend to be twice as smart as they really are by behaving like children.

Re:It doesn't change anything except for benchmark by j-turkey · 2003-10-23 06:38 · Score: 1

You can probably see 120 FPS pretty easily, though you might not conciously notice a difference. To test that you would need to have an image flashed at you at 1/120th of a second.

I can notice a difference between a 60 and 120Hz refresh rate on a monitor -- but this is mostly the "flashiness" they produce out of the corner of my eye. I think that if the refresh rate is set properly, it will be hard to notice (although I can see what you mean by higher framerates being registering unconciously). However, there has to be some kind of threshold where you really can't notice. I'll dig around for published studies...I'm sure they're out there.

FWIW, I have a friend who is a coder for Bungie -- he's been into realtime 3D coding for years and he swears by the 60 FPH benchmark for 3D gaming. He says that there's not much reason to have any more (or any less).

--Turkey

--

-Turkey

60fps? by Anonymous Coward · 2003-10-23 06:49 · Score: 0

I think that keeping it at 60 fps wil help the game run smoother an better than if the rate is all over the place

Interesting idea from this by Anonymous Coward · 2003-10-23 07:50 · Score: 0

We all have heard of power-ups. What about power-downs? If you accidentally run over a certain "orb," your character glows in the dark, making you stand out really well within the doom3 shadows.

Re:Interesting idea from this by GigsVT · 2003-10-27 01:33 · Score: 1

Rise of the Triad had power-downs.

--
I've had enough abrasive sigs. Kittens are cute and fuzzy.

Yeah, I can tell. by Dissonant · 2003-10-23 08:07 · Score: 2, Funny

Yeah, I can tell the difference between 60fps and 75fps. 60fps gives me a headache after ten minutes.

Re:Yeah, I can tell. by Anonymous Coward · 2003-10-23 15:50 · Score: 0

60fps gives me a headache after ten minutes.

It would if your monitor is set to 60hz.
Quake 3 (for instance) uses 60hz by default- even though /r_displayrefresh displays the value "0".

I apologize if you knew this already..

IMHO, 60fps is only 60fps if my monitor is set to at least 85 hz.

To all the benchmark worriers... by Anonymous Coward · 2003-10-23 08:15 · Score: 0

...you'll notice the benchmarking paradigm is shifting away from max fps, and on to much more useful 'time spent in an unplayable fps' or similar.
So fear not! It will still be great to use as a benchmark, just not in the more useless max fps sense.

On Perception, Simulation, and Benchmarking... by cyranose · 2003-10-23 08:41 · Score: 1

On perception, studies from the visual simulation field showed that 60HZ is plenty. In fact, having a solid 60HZ is inordinately better than a variable framerate, even if it was often higher. Motion seems smoother, temporal artifacts go away, and our brains can better predict motion, which leads to more of a feeling of "presence."

I wholly support locking the framerate, but I'd prefer if rendering locked to my actual monitor refresh rate, not only 60HZ. That's a bit too monolithic, especially when the problem of special jumps only working at 105fps or whatever is a problem of _simulation_ framerate, not rendering.

On simulation, 60HZ is not the gold standard. Physical simulations are often run higher for various reasons. Positions can be interpolated when graphics and simulation are not integer multiples. Not a problem. But locking the two makes some design issues simpler. Id may have some better way to do all this with a locked 60HZ. I don't know how dynamic their world will be.

On benchmarking, my attitude is this whols FPS benchmark crap was always a mistake. The only useful benchmarks for any video card IMO are how many sustained verts, triangles and pixels per second they can do under a variety of conditions. FPS can be tricked up in so many ways it's not at all useful as a benchmark.

actually, using framerate for tics makes sense by sbma44 · 2003-10-23 09:04 · Score: 1

since it lets you get the most out of your system. if you space your frames out evenly, sometimes you'll have your system waiting around for the next frame to start when it could be drawing something inbetween. or worse, if one frame takes too long -- say you're running at 10 fps and one especially complex frame takes 0.11 s to render. Now your system is sitting there for 0.9 seconds of wasted time, and it's had to drop a frame.

much easier to just scale everything by the time it took to compose and draw the last frame. Unfortunately, it produces weird artifacts that in id's case translated to slight gameplay advantages for higher-framerate users.

I'm glad they're capping it. 60 fps is plenty -- most users don't even realize how hard it is to tell the difference between framerates over 40 or so (possible, certainly, but it's more subliminal than anything). If I have to read one more console game review that claims a game runs at 60 fps (it's always 60 with them) when they're playing it on an NTSC television, I am gonna go nuts.

HOW DARE YOU SLOW ME DOWN? by 00RUSS · 2003-10-23 11:58 · Score: 0

WHAT, you mean they wont let my ultrafast 200mhz with 32megs of ram get above 60fps? and I just upgraded it too!!

--
+-+-+-The folowing statement is true. The previous statement is false.-+-+-+

GOOD! by moosesocks · 2003-10-23 12:02 · Score: 1

Finally, we can get rid of the biggest limitation today in gaming: Rich gamers.

By capping the frame rate at 60fps, gamers with insanely fast computers will no longer be put at an unfair advantage. This will also (finally) end the gaming age of machosim - yes, people STILL buy faster PCs to get more FPS on Quake3.

Honestly, I find that any game above 30fps is perfectly playable. Any more than 60 seems silly. Aside from that, there are few monitors that can draw so many frames per second... I actually find that once my FPS exceeds my refresh rate, the game begins to look worse, and other factors come into play. I perfer a good-looking game with a lower frame rate.

In addition, this may promote the revival of Motion-blur which seemed to die with 3dfx (those who used the technology claimed it to be awesome). Who knows?

--
-- If you try to fail and succeed, which have you done? - Uli's moose

Re:GOOD! by mattgreen · 2003-10-26 13:56 · Score: 1

By capping the frame rate at 60fps, gamers with insanely fast computers will no longer be put at an unfair advantage.
I'll take your computer and play with your unfair advantage, you can have mine, I don't need the advantage!

Just because you are content with 30fps doesn't mean your likes should be foisted onto other people. I want the framerate as high as it goes. If the game isn't nauseatingly fast then I want more FPS. If I get over 100fps average then I put the resolution up until it goes high enough.

And you are an idiot if you think this ends gaming machoism. Its a bunch of prepubscent males on the Internet - all its going to be is gay jokes, consistent misspellings, catch-phrases, and bragging about hardware.

Hurtz? by Anonymous Coward · 2003-10-23 12:12 · Score: 0

Okaaaaaaaaayyy...maybe hertz?

hahHAHAHAHAHAHA!!! by MBraynard · 2003-10-23 13:06 · Score: 1

$50 on what the first Doom3 hack will be.

Normally hackers have to get their hands on the game before they figure out what exactly they want to hack, but Carmack just threw them a big fat one to start thinking about.

Re:It doesn't change anything except for benchmark by jjhlk · 2003-10-23 13:22 · Score: 1

Somebody (The miltary?) did tests with fighter pilots, and the max rate seemed to be 1/200th of a second for maybe the image of a black plane on a blue sky. Hope that helps if you really decide to find a study. I searched the "Academic Search Elite" database but couldn't find anything.

I would agree that there probably is little reason to go higher than 60 fps. I've limited half-life to that and I don't think I could tell when it was increased later.

Famous Last Words: by Anonymous Coward · 2003-10-23 13:47 · Score: 0

60 FPS should be enough for anyone. ~John Carmack

Make it optional? by danila · 2003-10-23 13:50 · Score: 1

Can't they make this optional, like, for example, in GTA? GTA was a lousy PS2 port and was programmed for a fixed framerate (30FPS). When ran with a variable frame rate the speed of certain in-game events changed (!), but the programmers still left the option to play with uncapped framerate. Why should Doom 3 be different, especially if variable framerate is not a problem for the engine?

BTW, Doom3 will become irrelevant much sooner with this framerate cap. Do you think any game site would still use Quake3 in video-card benchmarks today if it was capped at 60FPS? :)

--
Future Wiki -- If you don't think about the future, you cannot have one.

Re:Make it optional? by damiam · 2003-10-23 14:10 · Score: 1

GTA is not a multiplayer game, and so there's no problem with letting the user fuck it up however they want. Doom III is, and it's important that the physics are consistant on all computers.
And really, whether or not some site uses it for hardware benchmarks has absolutely nothing with how "relevant" a game is to gamers, who generally want to play a game more than they want to benchmark it.

--
It's hard to be religious when certain people are never incinerated by bolts of lightning.

Not really a bad idea, (close) by Ayanami+Rei · 2003-10-23 14:07 · Score: 5, Informative

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

Re:Not really a bad idea, (close) by mattgreen · 2003-10-26 13:46 · Score: 1

Good lord would you people QUIT spreading misinformation about maximum frame rate the eye can see? Every single time a discussion like this comes up somebody has to come in and spout "Gee the max FPS you can see is 24 frames per second thats why movies are that fast" or some other completely bogus claim.

This claim has been proven wrong multiple times on slashdot and elsewhere, please get your facts straight.
Re:Not really a bad idea, (close) by Anonymous Coward · 2003-10-26 23:26 · Score: 0

Well, maybe it has something to do with LCD display's which are usually capped, or have optimal performance, at 60Hz ??

Dunno, just a wild guess.

Why? by Ayanami+Rei · 2003-10-23 14:14 · Score: 1

A polygon ray intersect calculation takes fewer calculations than a ray/box intersect.

Considering the rendering engine can pick out which polygons are even visible... and where they are... couple that with the known "crosshair" location and you can have polygon accurate hit detection. You might have on average a few more checks with this method than the previous single bounding box check, but it's better than having to check a bunch of invisible virtual polygons or smaller boxes individually.

--
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON

Alright everybody by _Sexy_Pants_ · 2003-10-23 15:17 · Score: 1

Raise your hands if you upgraded your machine solely so that you could run this game at a million frames per second. I know I'm not the only one

--
Look it's a joke about my sig IN MY SIG! LOL!

Re:Alright everybody by 00RUSS · 2003-10-27 07:11 · Score: 0

Sorry, I upgraded mine for half-life 2.

--
+-+-+-The folowing statement is true. The previous statement is false.-+-+-+

not really... by z01d · 2003-10-23 15:28 · Score: 1

it has no impact to the benchmarking, you can still use the engine to determine how fast a video card is, say 354fps or 432fps, but you'll only get 60 different frames in 1 second. that's what JC said.

no need for cheat-protected cvars, methinks.

not rendering rate... by z01d · 2003-10-23 15:40 · Score: 1

The other two things, the simulation rate and the rendering rate are both going to be locked at 60hz/FPS.

No, according to what Carmack said, the rendering rate can be higher than 60, say, 120, but half of the 120 frames are identical with the other half.

Yes, simulation rate is capped, if the rendering rate is 120, then, the [user input] and [world entities] will only be processed once per two frames. that's the difference with the existing Quake3 engine, which will check the [user input] exactly per frame, depends on your com_maxfps and your machine's power, and [world entities] will be updated according to sv_fps

Shouldn't be a problem now should it? by Thijssss · 2003-10-23 19:47 · Score: 1

I don't see what all the fuss is all about? Sure, the game engine runs at 60Hz.. so? YES, I can see the difference between 60, 75, 85, 100, 120Hz .. I even love seeing 160Hz refresh rates.. we can still use 100Hz monitor refresh even if the game runs on 60Hz internally. It would only redraw the same picture a few times BUT, you would be able to get rid of the flickering. About the mouse running 125Hz .. atleast that's what everybody says.. pfft, I only know about 3 people who were ever able to master the mouse in fps games so scary good that they could acuratly shoot of heads in a reflex.. i'm quite sure all of you won't have a disadvantage so stop complaining :)

pathetic poser! by 6pak · 2003-10-24 04:17 · Score: 1

got to compensate for any physical "SHORTfalls" or what? what a pathetic wimp...

What are you talking about? by daVinci1980 · 2003-10-24 05:22 · Score: 1

That's actually utterly false.

You don't use a 2-D check to determine the ray intersection with the polygon, that would be useless. By the time the rendering is complete (and assuming you lock the back-buffer, which *very* few games do other than for screen-shot purposes), you don't know where a given pixel on-screen came from.

Sure, a line-box intersection is slower than a line-polygon intersection, but you're assuming that they already know which polygon to test. In order to do that, you have to iterate over the polygons through some method (usually not brute force, usually bounding boxes or spheres).

The way this sort of thing usually works (and its really not anything new, just new for iD), is to have the model broken into pieces, the model, head, arms, legs, torso, etc. You test the model through the hierarchy.

First you see if the ray intersects with the model at all (usually ray-box or ray-sphere). If it does, you test the next piece in the hierarchy (usually left/right or along the biped object). Once you've narrowed down your search to a single piece in the hierarchy, usually you just brute force walk through the polys in that section.

--
I currently have no clever signature witicism to add here.

There are other ways to solve this problem by daVinci1980 · 2003-10-24 05:26 · Score: 1

Many quake derivatives have solved it. (BF1942, for instance?)

--
I currently have no clever signature witicism to add here.

Good article on FPS by Nijika · 2003-10-24 05:28 · Score: 1

Just in case anyone fell behind on the WHY of this like I did :)

Here it is

--
Luck favors the prepared, darling.

why not cap it at 100? by Novotny · 2003-10-25 00:30 · Score: 1

Well, I play Counterstrike. I have my fps in game set to 100, I have my monitor running at 100hz and I have v-synched enabled (windows xp, refresh fix). As I understand (and experience) it, everything is in synch. I have an extremely smooth gaming experience with no screen-tearing (thanks to the v-synch). You CAN easily tell the difference in an fps game when you play with lower frame rates. It's that simple, you easily can. Carmack did state a few years ago that a semi-serious gamer would want 60fps and that's true, but it's really the minimum you want for competitive gaming. Any less and things just aren't smooth enough. However, for a single player experience we can deal with a lower fps - I seem to recall that when Quake 2 was released people were reasonably happy getting 30+ fps for the single player experience.

Carmack by Anonymous Coward · 2003-10-25 04:58 · Score: 0

"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."

Well, no shit, Sherlock.

Hallelujah by k8to · 2003-10-26 05:53 · Score: 1

A stable framerate is soo much more pleasing aesthetically. Variable framerates are really distracting and make me think about the engine and the software and the hardware, instead of being immersed in the game.

--
-josh

Computer specs by mattgreen · 2003-10-26 13:48 · Score: 1

Thank you for telling us your full computer specs, they definitely helped out the post. I don't think you could have made an effective post without them!

No. by Ayanami+Rei · 2003-10-27 10:32 · Score: 1

The FFT (flicker fusion threshold) of the human eye varies between 15 and 20Hz (depending on light level and subject age). This is the minimum framerate that appears as multiple still images as opposed to reconstructed motion.

Your eyes also have a secondary process called saccadic movement. It has a varying frequency (4-5 times per second), where the eye makes sudden jerks and focus across your vision. You only see during intervals when the eye stops moving, the periods in between are blanked out by lower brain functions (which controls the eye movement).

Since there are multiple processes and response patterns involved, low framerates are detectable even if they appear to be moving.

But such lower framerates coupled with appropriate blurring and progressive-scan displays or LCDs can eliminate nearly all such senstations.

And citing that your statement was "proved" wrong on slashdot is not lending it much credibility.

--
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON

Geez people use common sense by xintegerx · 2003-10-27 19:07 · Score: 1

USE COMMON SENSE!

When an object moves in front of our eyes or on the screen, yeah we might not need 100 frames per second. Move your outstretched hand left to right really fast in front of your eyes, and you will notice that you see a blurr of a mix of colors. This is what you guys keep talking about. Well, you guys are WRONG for focusing on the WRONG thing.

What you guys are talking about is MOVEMENT, but you should be talking about EYE SCANNING. Yes, our eyes aren't fast enough to see individual frames of fast movement very well, but that is irrelevant. WHAT MATTERS IS WHEN YOU ARE *NOT* MOVING but instead only USING YOUR EYES to look around you. AHA! Here is where you understand my point. Although eyes can't separate frames of fast movement, *when our eyes are the ones moving, we can.* We have a big peripheral vision and we use our eyes to look around, while the big picture of what's in front of us remains the same, causing no frame difference. But on the computer screen, you have NO peripheral vision, so when you turn your character, it's as if his eyes are fixed to the center and you have to turn your NECK to look around, thus causing movement. And with movement, comes the price. If you have a sensitive mouse and you move it up quick, that might last 1/6th of a second. That means in that time, there were updates 6 times. Your eyes can definitely see the difference OF a 17" VIEW MOVING from point a to point b. There is nothing wrong with that, but motion blur needs to exist to make this real.

However, if the screen was infinitely tall and wide to fill up your peripheral vision, you could just use your eyes to look around your peripheral vision isntead of having to MOVE the character's head. Of course, games don't allow peripheral vision, as if you buy a bigger LCD you will only get the same exact image, just scaled bigger. What games need to do is simulate peripheral vision so that on the bottom of the screen, you can see your legs as if you were looking down with peripheral vision. On the top inch of the screen should be displayed what is almost at the top of you, as if you were using peripheral vision to look up. the left inch should try to simulate what you would see if you moved your eyes left, like any monsters coming at you from the left. That way, the world won't be a flat PHOTOGRAPH of the camera, but a simulated person's view of a world in peripheral vision, with everything a normal person would see be somehow displayed on the monitor like I said. Maybe by trying to draw a curved sphere of vision or something.

--

Cover your eyes and click this link!

Slashdot Mirror

id Says 60fps Is Enough For Doom III

163 comments