Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
PC Games (Games) First Person Shooters (Games) Quake Entertainment Games

DOOM III to be capped at 60 fps 57

Posted by Hemos from the to-cap-it-all-off dept.
StupidKatz writes "The Inquirer reports that DOOM III will be capped at 60fps, primarily to prevent certain exploitations of the game engine (reminiscent of Quakers that could jump higher, etc.). Although the game's graphics challenges most cards to keep up with the 60fps figure, what might this do to ATi and Nvidia sales figures, considering that the next DOOM incarnation is set to be the next heavyweight graphics upgrade reason? More importantly, might this possibly keep the anticipated price drop for the previous vid card generation at bay? The horror... On a more positive note, it is good to see designers anticipating problem exploits - no one likes a mutiplayer cheater." H : Sorry; it's a dupe. My fault.
This discussion has been archived. No new comments can be posted.

DOOM III to be capped at 60 fps More

DOOM III to be capped at 60 fps

Comments Filter:

  • Dupe (Score:1, Redundant)

    by fredrikj ( 629833 )
    This is a dupe of this story [slashdot.org]. Different article though... but no new info.

    • Re:Dupe (Score:2, Funny)

      by Anonymous Coward
      Redundant for pointing out a redundancy... aww.

  • Doesn't matter (Score:2, Redundant)

    by Apreche ( 239272 )
    Someone will write a patch/crack of some sort to make this not go. Someone else will write mods/total conversions that don't have 60fps caps. Someone else yet again will find some way to benchmark your computer using the game and not have an fps cap. A steady fps and a vertical sync will look better than a dynamic framerate over 100 anyway.

    Remember those screenshots that were accidentally on medium quality? Even with the latest cards nobody will be able to turn the graphics all the way up and have a ste
    • I will now have a lot more time between frames to consider the multiple ways in which I will KICK YOUR ASS. Bwahahahaha!
    • 5000$? Whats funny in just a couple years from now we'll be benchmarking this game at 500fps. It is funny how these games that have high system reqs' have a certain "envious" mystique; until the computer hardware catches up. In two years it will be Doom 4 capping at 60 fps on a 5000$ system two years from now, but eveyone will still play good old Doom 3 cause' it runs great on my "budget" machine(two years from now).

      Ah, it is spring again, enjoy the endless cycle of nature!

  • I am sure there will be a benchmark mode of some sort where there is no cap.
  • For the life of me I can't figure out the connection between a client's FPS and his ability to perform unreasonable jumps in the game world as generated on the server. But what the hell, the devs pro'lly know what they're talking about.

    More to the point though (on FPS limiting) - can someone with GPU/DirectX internals knowledge explain why doesn't a game (or a GPU) that realizes its churning more than the 30fps that the human eye can discern dynamically (and automatically) enable FSAA (AntiAliasing) and/or
    • Just because the game is running at 30fps it doesn't mean that it is synced with the refresh rate of the monitor and also in sync to when you're eyes refresh. That's why we can tell when something is running at 60 or 100fps.

      Switching FSAA on and off would look weird, you want to keep it consistent! If anything it's keep everything high unless it's about to go god awful slow then kill things off so it's atleast playable.
    • The physics are calculated on the client and use the framerate as the timer. So, higher framerate messes with the time for the jump. I think that connecting the two is a bad idea.
      • The physics are calculated on the client and use the framerate as the timer.

        I don't believe this is the problem with Doom III, using the frame rate as a timer is the dumbest thing a game programmer can do, because, as already pointed out, fraem rate may vary between clients.
        Anyway, check out the Quake / Quake II engines source code, both use real time as a timer.
        So I doubt this is the reason behind it, any body has more info or something?

        • http://ucguides.savagehelp.com/Quake3/FAQFPSJumps. html [savagehelp.com]
          No, that's pretty much the problem.
          • hmm, how on earth did he/she manage to dive into the source code of Quake III while its not open yet? I know the gameplay source code is out, but I doubt that code dealing with how the game detects collisions and deals with physics is game play, or is it?
            • There are mods out there which will display your speed, height, etc. It's a pretty simple thing to change the fps and just test the values. Basically if you look at the article you can see they didn't need the source to do this testing as gravity and what not are configurable.
        • A vastly over-simplified view of the game rendering engine is
          while (true)
          update_player_position()
          render_frame()
          done
           This calculates the details and spits out the frames as fast as the graphics-card can draw them. The problem is in update_player_positions() - Computers are of course finite precision. Consequently round-off errors occur as soon as you approximate real world physics. Since numerical errors are cumlative, updating the position every frame can produce different results depending on
    • For the life of me I can't figure out the connection between a client's FPS and his ability to perform unreasonable jumps in the game world as generated on the server. But what the hell, the devs pro'lly know what they're talking about.

      It has to do with dynamically calculating the height of the jump and the rounding of floating point numbers during movement (which is calculated per frame). It's not that the jumps are unreasonable, in fact either everyone should be able to perform the jumps or no one shoul
      • I see what you're saying. If you enable FSAA at 31FPS, you'll end up having 30fps one moment, then 15fps with FSAA enabled the next.

        Furthermore, let's for arguement's sake forget 30FPS, and instead use N as the fps value above which we can no longer discern a smoother picture.

        My point, however, remains. Consider the following two points:
        A. There _is_ redering power wasted.
        B. There _are_ more useful things to do with it than render frames I cannot discern.

        What you said does not adress the why/why-nots of
        • I see what you're saying. If you enable FSAA at 31FPS, you'll end up having 30fps one moment, then 15fps with FSAA enabled the next.

          Furthermore, let's for arguement's sake forget 30FPS, and instead use N as the fps value above which we can no longer discern a smoother picture.

          You would actually need 2 values:
          N being the point at which FSAA is enabled
          M being the point at which FSAA is disabled
          and these values would have to be user-configurable. So, if the framerate goes over N while you have FSAA disable

  • 60 + 60 = 120 FPS!! (Score:2, Funny)

    by Anonymous Coward
    This is great news! If you add the 60 fps capped from last week to today's 60 fps, you end up with a whopping 120fps!!

    Sweet!!!!! Thank you Hemos!

  • Let me be the first to embarrass myself to future gamers by saying:
    640kb primary memory... i mean 60 fps should be enough for everyone!

  • Dupe. (Score:2, Funny)

    by geggibus ( 316979 )
    Can't slashdot cap dupes? ;)

    -K
    • Can't slashdot cap dupes? ;)

      Dupes are theoretically capped... at (# of "editors") + 2.

      (I added 2 because I figured Timothy and Michael could conceivably post a dupe of something they already posted...)

  • Didn't realize that not all stories make it to the front page. Hrmf.

  • game tic not frame rate. (Score:3, Informative)

    by illumen ( 718958 ) on Monday October 27, 2003 @09:04AM (#7318407)
    Pretty sure he said game tic, not frame rate?

    The difference is the ai/physics/game rules will be updated at 60hz, whilst the rest(sound video) could be updated at a different rate.

    The benefits for the fixed rate are a few. It is almost very similar to having your elapsed time calculations between frames being fixed.

    The biggest advantage of it is in terms of game play. You can be garaunteed that most players will see a very similar game world each time they play. For example imagine there is a slide which the character has to run down. Then there is a big hole in the ground which the character has to jump over onto a platform past this hole. With a fixed tic rate you can place the platform at such a place that the jump must be timed just right. That is the player will not make the jump unless they jump right from the end. But with a variable tic rate you can not be sure that the player will be able to be at that exact position. Time may move too fast and they may miss the perfect jump location.

    Another important reason to have a fixed tic rate is so that motion looks smooth. There is no point in having all animations being updated 300 times a second in one room, then pause for a quater of a second. It would look jerky.

    It can simplify calculations. Allthough this doesn't really matter too much for someone writing a fairly complex physics simulation like they are. But making sure every thing is done within 1/60th of a second is simplified if you know that rate is fixed. If there is time left over you can do some preprocessing for the next frame if you want.

    Having a slower than maximum tic rate can also allow you more time to render a purty scene, calculate nice interactions with the world etc.


    Have fun!
    http://www.holepit.com/ [holepit.com]
    • Pretty sure he said game tic, not frame rate?

      The article linked here is very short on information (and actually quite incorrect on a number of statements), but the earlier article quoted the framerate cap specifically, with the quote in this article as explanation for the reason why the cap was made:

      The game tic simulation, including player movement, runs at 60hz, so if it rendered any faster, it would just be rendering identical frames

      The article stated 'no more no less', which is just wrong, as no
  • The summary actually contains a dupe acknowledgement!

    Run for the hills! The end times are upon us!!!
  • Looks like they really are doing a sequel, the original Doom FPS was also capped (to 31fps if I remember correctly) Maybe there could be motion blur support to use when cards get fast enough to be able to run it for more than 60fps?
  • "On a more positive note, it is good to see designers anticipating problem exploits - no one likes a mutiplayer cheater."

    Is it a cheat if the only thing it requires is skill, without any modification to the game?
  • I would like to know why they picked 60 FPS. 72 or 75 FPS would have been a better. It just seems to me that since flourescent lighting flickers at a 60Hz rate that 60 FPS would have been best avoided.

Slashdot Top Deals

Your password is pitifully obvious.

Close