Archived

This topic is now archived and is closed to further replies.

digitalfreak

now DOOM3's frame rate is capped,why is that?

Recommended Posts

We checked with John Carmack himself about why DOOM 3 will be hard-capped at 60fps in the renderer, and he had this to say: "The game tic simulation, including player movement, runs at 60hz, so if it rendered any faster, it would just be rendering identical frames. A fixed tic rate removes issues like Quake 3 had, where some jumps could only be made at certain framerates. In Doom, the same player inputs will produce the same motions, no matter what the framerate is." so does this mean the Q3A engine can draw more frames on faster machine than on slower machine with the same user input;while the Doom3 engine synchronizes the input and drawing part?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster

It sounds like an ugly hack - why would you tie the physics/movement/etc to the framerate? I thought we''d have gotten past this by now.

Share this post


Link to post
Share on other sites
For those of you who haven''t played alot of q3, there were things players with higher framerates could do that people without them couldn''t. THe game was timed and all, and player movement wasn''t actually faster, but jumping was. Players with faster framerates could jump into places they weren''t supposed to be able to jump, where people with normal framerates couldn''t make the same jumps, and had to go about finding the correct way to get to certain spots. It was an unfair advantage.

Share this post


Link to post
Share on other sites
thats dumb, why in the world would framerate determine how high somone could jump, the physical model should remain in a constant world of units reguardless of how fast the image is drawn or the physics is proccessed, maybe it has somthing to do with modyfying the physics based on varying framerates to give a constant idea of motion, but in that case why not just drop some frames *dont render but proccess the underlying physics*

seems strange to me.

Raymond Jacobs,

www.EDIGames.com

www.EtherealDarkness.com




Voice your discontent! help stop the flames!

Share this post


Link to post
Share on other sites
I think John Carmack is saying that the simulator/physics maximum simulation speed is equivalent to a 60 fps update. In other words if you could draw 61 or greater fps, then at least one of your frames will be identical to a prior frame (and hence no need to redraw it).

[edited by - Cosmic314 on October 23, 2003 4:32:12 PM]

Share this post


Link to post
Share on other sites
Actually for a single player game tying physics to framerate is one of the best options together with Carmack's option AFAICS. Albeit one where you have to be really carefull of corner cases of physics simulation behaviour, which are hard to QA ... as Q3A prooved.

If you have fixed ticks for physics simulation, but want higher fps you have to use extrapolation or interpolation to determine how stuff moves in the extra frames. Extrapolation can be wrong, in which case you get jittery motion ... and interpolation forces you to delay rendering by 1 tick, causing extra latency in rendering. Neither of those are terribly attractive options.

Given Doom3's gameplay a 60 fps maximum seems a reasonable compromise.

For the multiplayer mode he can safely use extrapolation though AFAICS, the client side prediction used to correct for network latency usually tries to predict well beyond 1/60th of a second ... so if the extrapolation causes artifacts those will already be present anyway.

[edited by - PinkyAndThaBrain on October 23, 2003 4:41:36 PM]

Share this post


Link to post
Share on other sites
I''m having problems with my frameRate scaling too.
I use a Performance timer to get the frameTime at the end of every frame, but when the the frameRate is high, the timer is not high resolution enough and the frameTimes are too discrete, and the player starts running slightly faster. For some reason this didn''t happen on older versions of my game, but the engine code is unchanged. I assume it''s just the optimizations I''ve put in lately.
What could be happening?

Share this post


Link to post
Share on other sites
quote:
Original post by EDI
thats dumb, why in the world would framerate determine how high somone could jump, the physical model should remain in a constant world of units reguardless of how fast the image is drawn or the physics is proccessed,


Rounding errors and floating point inaccuracies can easily creep in over many iterations (ie, the hundreds of frames that can be processed in a few seconds) meaning that even clock-time based simulation will suffer from slight variations at different update amounts.

While i''m not totally sure I agree with this, there must be a strong technical reason for this. I doubt Carmack would make such a decision lightly.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by 31337
Not that at any machine will be able to run Doom III at 60 FPS for at least another year


I wouldent count on that. Someone I know that knows someone else that has a brother that got a computer a few days ago has 60 fps at 90% of the time.

Share this post


Link to post
Share on other sites
I guess the problem would be what to draw between those 60hz ticks for framerates higher than 60hz.

It's easy enough to lock and optimize all game physics calculations to be based on a 60hz tick rate, but if the renderer is detached from the physics simulation, there isn't any reason to not be able to approximate the positions of objects in between those times for purposes of rendering more frames.

Unless the calculations are too intense and would ultimately slow everything down, I guess.

But you know what, I wouldn't put it past him to say that the NEXT iteration will not have such a limitation, and he's just holding back to make us look forward to the next thing, just like there was no real reason not to provide the ability to jump or have a decent strafe in Doom 1, and the ability to duck in Quake 1.

It REALLY points to those hardcore hardware owners that REALLY want to have a high frame rate. It just wreaks of itching to wait for the next thing he puts out. Forward planning always seemed to be one of his strong points. You can bet the high end hardware owners will be the first ones to buy his next engine build (IF he makes another one). Perhaps he plans to hand it over to another company to remove the limitation so that another huge batch gets sold when it is upgraded - then he'll have enough money to put a man in space without NASA.

EDIT: This reminds me of a discussion with Lawrence Holland about the XWing vs. TIE Fighter campaign Balance of Power and the Super Star Destroyer. I believe the question was why wasn't the Star Destroyer made closer to scale with the way it was in the movies. The answer was that it would have taken a lot more polygons. HUH??? Just set the scale of the renderer to make it bigger! Sheesh! Perhaps we are supposed to understand the marketing angle as well.


[edited by - Waverider on October 23, 2003 10:01:14 PM]

Share this post


Link to post
Share on other sites
Dude, I think there should be some relationship between the drawing part and other parts in the engine such as game logic or physics engine. I have an example, a user triggers an event such as throwing a stone away, the process should be identical in the real world as long as the user gives the same input. Let's say it takes the stone 1 sec before hitting the ground and it travels 10m in the air. What we want in the game is regenerating this scene as accurately as possible. So with a faster machine which is capable of 100FPS, the distance the stone travels between each 2 frames shoud be 10m/100 = 0.1m,while with a slower machine which can only keep up with 50FPS, the equivalent distance should be 10m/50 = 0.2m.



[edited by - 991060 on October 23, 2003 12:23:00 AM]

Share this post


Link to post
Share on other sites
From the link to the thread posted earlier... Yes, it seems that Quake 3 uses integers instead of floats for all vectors. In my opinion, thats just gay. Not only is it a dramatic loss of precision, but it also makes things harder to program.

Also, it doesn''t really make sense that people with faster machines can jump higher. The movement code should be simulated on the client and run on the server. This means that only the server''s framerate should affect your actual movement. With this model, there could be prediction errors on the client side, but no player should be advantaged.

Capping the game at 60 FPS sounds alot like what they did to Quake (all game code ran at 10 FPS). Carmack later said what they did in Quake 2 was a mistake. Apparently, using integers for vectors has caused other problems with a framerate independent model.

Conclusion: Don''t take Carmack as a model. If you have ever looked at the Quake 2 source, you can tell its just full of hacks. Alot of what has been done by Id Software could be done better. If you just look at Half-life, the movement is framerate independent, and I don''t see people with faster machines getting higher jumps.

I believe its time for engine design at Id Software to evolve. Using integers for vectors is stupid and running at a fixed framerate is stupid.



Looking for a serious game project?
www.xgameproject.com

Share this post


Link to post
Share on other sites
quote:
Original post by Max_Payne
running at a fixed framerate is stupid.


No, running at a fixed timestep is the way to get robust, reliable simulation. Consoles use it because with a fixed hardware configuration and a handy tv refresh rate its practical to use. Military and commercial flight simulators use a fixed timestep to ensure their physics are accurate.

Whether this applied to a pc game where the game may be played on numerous pc configurations of different specification is another matter. Carmack must have decided that he''s going to favor robustness, and that the game is sufficiently scalable to run at this timestep on all computers (now *theres* the tricky part).

Share this post


Link to post
Share on other sites
Waverider: He probably meant that they''d need more polygons so they could light it porperly..they vertex lit everything didnt they? so making the polygons bigger would make the lighting quite horrible looking. Imagine a 1 kilometer stretch of SSD lighting up just because a meter long laser bolt was flying near it...

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
There''s no reason to have a framerate faster than 60, or 30 for that matter. Think of all the important stuff you can do instead, like AI.

Share this post


Link to post
Share on other sites
quote:
Original post by Captian Goatse
[Dumb blah blah]


You are starting to get seriously annoying. You might find it funny to throw around mindless insults on the technical forums, but I don''t.

Probation. One more insult I see from you on this forum, and well, I think you can guess what comes next.

To everyone else: please, let''s keep this thread focused on the (interesting) topic of fixed vs. variable update rate for physics. Everything flame-ish will be deleted. Thanks.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by Anonymous Poster
It sounds like an ugly hack - why would you tie the physics/movement/etc to the framerate? I thought we''d have gotten past this by now.



This is not a hack but the way to go,

Like said before,
the physics is not tied to the framerate :
on PC typically you expect variable framerate and the same
will happen on Doom 3, some machine will only render at 40 fps max, some at variations between 10 and 60 fps depending on the resolution, the charge of the screen etc..

Imagine that you have a physic engine that run at a fixed granularity. You do that for many different reason. The first one and strongest one is consistency. Fixed granularity is quite opposed to a attaching physics to framerate. (attaching physics to framerate would create a lot of inconsistencies).

Now you have to decide a delay for this granularity. You cannot set it too high else slower machines might have difficulties to catch up and the game will simply not run at default detail.
I suspect that Carmack made it 60 update per seconds because it is the number that comes the most when you think of a comfortable framerate.

Of course you can render more than 60 frames per second. His engine won''t be blocked and might run at 100 fps for example. But simply, either you run these 100 fps in accelerated time (a replay for a benchmark for example) or if you run at normal speed then you end up drawing a frame twice (the aspect on screen simply doesn''t change).

You could imagine that animation might not be entirely tied to physics calculation, but interpolation could be the cause of some strange visual artefacts.

LeGreg

Share this post


Link to post
Share on other sites
There was a discussion about this on the game algorithms list a year or two ago. It was gernerally thought that 10-20 Hz is all the physics system needs to remain stable. So you would have to have a way to schedule which frames need to calculate the physics frame or run physics in a thread of its own. That and you would need to interpolate for the other frames.

Share this post


Link to post
Share on other sites