PDA

View Full Version : Why is my framerate capped at 60fps?


vivarey
08-06-04, 10:58 AM
Running at 1280x1024, Ultra High graphics with AA set to 4x (don't know how to set AF inside the game). I can't seem to break the 60fps mark, even though I sit exactly at 60fps during most of the game. It seems like I'm capped at that framerate. Anybody else experience this? Vertical Sync is OFF. Thanks.

MUYA
08-06-04, 11:03 AM
Thats the way iD intended it. The 60 fps cap only comes off if you are benchmarking using the "timedemo demo1" command in the console.

Kamel
08-06-04, 11:04 AM
i'm nearly certain the reason why is because of an intellagent vsync thing they added to the game (which i am not sure if they have added, nor am i sure if there is a way to toggle it off), even though vsync is off, once you go over your refresh rate, you can not notice an improvement in FPS. it's possible with lower than 60FPS if you consider that half of a frame a new frame, but it's simply cut up when going over, and does not enhance your experience at all.

so, technically, i *think* they added the cap so that you wouldn't get visual tearing, and 60FPS is as high as your monitor can possibly display at 60hz anyway. as far as turning it off, no idea if that's possible.

you can change your refresh rate by r_displayrefresh value... should you want a higher cap, it can probably be done this way; though i have no idea if it can or not.

to answer your question though, yes the game is capped at 60FPS.

majortom
08-06-04, 11:51 AM
i think its because god hates you...

Kamel
08-06-04, 11:55 AM
well, satan is trying to kill him with his demons... wow, how does it feel to be a rogue in the religious world? lmao

ynnek
08-06-04, 12:30 PM
Its set at 60 hz, because the game's internal calcs and timings are set at 60 hz.. something like everything in D3 world is discretely calculated out.

Ninjaman09
08-06-04, 12:41 PM
Everything above except for MUYA's post is speculative. id designed the game that way simply because they felt like it. It's worth mentioning that FPS above 60 aren't really noticable. Maybe they did it to get people to focus on playing the game and not obsessing over their frame rates?

CaptNKILL
08-06-04, 12:42 PM
Its set at 60 hz, because the game's internal calcs and timings are set at 60 hz.. something like everything in D3 world is discretely calculated out.
60Hz isnt 60fps


Also, i was wondering, how the hell does Vsync work in this game if the framerate is capped at 60fps? The framerate must match the refresh rate (in my case 75Hz@1600x1200) or else the framerate will be halved. I have noticed some huge drops in performance but its acting as if my refresh rate is 60Hz (i never seem to get 50fps, its either 60 or ~30).

Ill go look more closely at the frame rates to see if i can figure this out.

Maybe the game uses a triple buffer (forced) so it can smooth out framerates with Vsync on.

Can anyone who knows the answer comment on how Vsync can work with a framerate cap lower than my refresh rate?

ynnek
08-06-04, 01:00 PM
EDIT: oh, rereading my previous post, I see the confusion I did mean to say "the 60 fps cap is because....."

60 Hz = 60 cycles / sec which direcly maps to the max rendered 60 frames per second.

Did a google:

http://www.bluesnews.com/cgi-bin/board.pl?action=viewthread&threadid=44949


They quote id's John Carmack on the reason for this.
"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."


A 60 fps lock at say 75 hz would equal a few repeated frames.

Ninjaman09
08-06-04, 01:13 PM
No he's saying the game's internal timing system loops 60 times a second so there's no point in trying to get higher framerates because it would just render the same frame until the next tic. Like if the game was running at 120 FPS, you'd still only see 60 FPS because it only redraws the screen once a tic. Screen refresh rate doesn't have anything to do with it except tearing. I've noticed that if you set the refresh rate to about 70Hz the game looks awesome and it pretty much eliminates tearing. I don't go below about 40 FPS and it's 55-60 like 90% of the time, but with VSync on I frequently go to 30 FPS. Not worth it if you ask me.

ynnek
08-06-04, 01:21 PM
Yes, thats exactly the point!!!!! The definition of 60 Hz is 60 cycles or times a second. So just replace "60 times a second" with "at 60 Hz" :ORDER: :) Thank you... lets close this thread now.


What you are talking baout below is the age old debate of vsync..some people can't stand the tearing effect, and would rather take a possible slight fps hit to ensure a clean redraw... others aren't affected by it.



No he's saying the game's internal timing system loops 60 times a second so there's no point in trying to get higher framerates because it would just render the same frame until the next tic. Like if the game was running at 120 FPS, you'd still only see 60 FPS because it only redraws the screen once a tic. Screen refresh rate doesn't have anything to do with it except tearing. I've noticed that if you set the refresh rate to about 70Hz the game looks awesome and it pretty much eliminates tearing. I don't go below about 40 FPS and it's 55-60 like 90% of the time, but with VSync on I frequently go to 30 FPS. Not worth it if you ask me.

CaptNKILL
08-06-04, 01:26 PM
Guys i think i figured it out.

Vsync with a 60fps cap still works with 75hz refresh rate. My framerates are either 60 or 38 with Vsync on (though both fluctuate quickly by a few fps), with it off they are rarely under 60 and when they are, they usually arent under 45.

Its hard to explain how my framerate counter locks at a minimum of 25 some times (when i look at the fire from the monorail crash my framerate sticks to 25... vsync on or off)... but everything else leads to Vsync still working with the 60fps limiter. Im guessing it probably still has to process 75fps to match up with Vsync, even though only 60fps are being displayed. This is apparent when the scene becomes too complex to process 75fps and my framerate drops to 38 (roughly half of 75).

Just to show my point, here are two screen shots, from the same exact scene. One with Vsync on, showing 39fps (fluctuated from 37\38 which is exactly half of 75). The other with Vsync off showing my fps maxed (it says 69, but the framerate just flickers between 60 and 70 constantly... even tho its limited to 60).

Im going to live with a little bit of tearing and go with my doubled frame rates. I wish I had thought about this before, because i deffinitely prefer 60fps (almost constant) with tearing to 37fps (or lower) without.

EDIT: Keep in mind that when theres a lot going on on screen, theres a lot more to process, so right in the middle of large battles is when the framerate will be halved... baaaaad timing :|

Ninjaman09
08-06-04, 01:30 PM
That's true, ynnek. I kinda got used to a little tearing in some of the Q3 engine games that didn't properly support VSync (MOHAA and Jedi Academy to name a couple). But I was trying to say that at 70Hz the tearing goes away without using VSync, while there was more at 75Hz, for whatever reason. Might be worth checking out for some people.

Pafet
08-06-04, 01:46 PM
Type "com_fixedtic 1" in the console to let the game run as fast as it can for benchmarking. It forces the game to draw every 'tic' per frame (it's like the frameskip option used in emulators).

"com_fixedtic x" will make it draw every x'th tic per frame. Just try it, you'll see

:PopCorn
08-06-04, 02:29 PM
"com_fixedtick x" will make it draw every x'th tic per frame. Just try it, you'll see

This command isn't recognized by Doom 3 for me. Link to where you got this info please?

Kamel
08-06-04, 02:34 PM
EDIT: oh, rereading my previous post, I see the confusion I did mean to say "the 60 fps cap is because....."

60 Hz = 60 cycles / sec which direcly maps to the max rendered 60 frames per second.

Did a google:

http://www.bluesnews.com/cgi-bin/board.pl?action=viewthread&threadid=44949




A 60 fps lock at say 75 hz would equal a few repeated frames.

very cool, makes tons of sense... however i still don't see why they must calculate physics at every frame; that's something they had done since the first q3. for this reason, trick jumpers would set their max FPS to either 43, 76, 125, or 333. this makes the physics the most perfect, and will allow the trick jumpers to jump onto boxes that normally you can't get to. this was solved by pmove_fixed on the server, but caused lag. some mods fixed it with the mod though, which makes no sense of why they wouldn't use a similar method in d3.

Ninjaman09
08-06-04, 02:41 PM
Um...did you not read the post? They DID fix the physics thing by calculating each tic instead of basing it on the frames. Carmack himself even said that frame-based physics in their old engine (Quake 3) caused the problems which was why they changed to a fixed tic rate. In other words, trick jumping is not possible in Doom 3.

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.

Kamel
08-06-04, 04:04 PM
eh, that's not what i meant. i did read the post; it's you that didn't understand me.

i was attempting to explain to those who didn't know the old system and how it worked.

the manner in which mods fixed it would not make frames duplicate.

Ninjaman09
08-06-04, 04:56 PM
OK? So what exactly DID you mean by this? I'll paraphrase what you said as I interpreted it, based on the context of the thread:

however i still don't see why they must calculate physics at every frame; that's something they had done since the first q3.

I understand this as: "In Doom 3 they calculate physics at every frame, which is something that was done in Quake 3. I don't see why they still do this."


some mods fixed it with the mod though, which makes no sense of why they wouldn't use a similar method in d3.

I understand this as: "Some Quake 3 mods fixed the problem (trick jumping), and it makes no sense why a similar solution was not implemented in Doom 3, which has inherited the same problem."

Am I off base here? I don't see how I can interpret what you said in any other way! "Frames duplicating" simply meant that since the game only updates at a set 60 tics per second, it is impossible to achieve a framerate higher than 60 FPS since the scene hasn't redrawn yet. Because of this, if the game were allowed to run at say, 120 FPS, you would still see it as 60 FPS because the game isn't redrawing the screen fast enough. It doesn't mean it would skip or lag or anything. It would just keep drawing the same frame until the game sent it a new one.

Kamel
08-06-04, 05:09 PM
I understand this as: "In Doom 3 they calculate physics at every frame, which is something that was done in Quake 3. I don't see why they still do this."

eh, i didn't say this right at all. what i meant to say is that i don't see why they don't calculate physics every frame like in quake3, in order to make framerates scalable (or change the update interval via a setting; which would have a nice side effect of being able to notch it down to say 30 for slower processors). they could have done this without having to take away from the goal of physics not depending on the framerate by tweening between the physics calculations. (on other clients, as opposed to their own)


I understand this as: "Some Quake 3 mods fixed the problem (trick jumping), and it makes no sense why a similar solution was not implemented in Doom 3, which has inherited the same problem."
no, they didn't fix the trick jumping "problem" (though some possibly may have); they simply made it so that everyone was on the same level. if playerA could jump onto boxA, so could playerB -- regardless of framerates. in vanilla quake3, if playerA was running at a constant 76FPS, he could jump onto boxA with no problems, whereas if playerB was running at 27FPS, he could not jump onto boxA. this was fixed by taking a prediction of the trajectory (the jump delta iirc) and assuming the maximum height of the jump. also, it was scalable between different frames per second, because where the world around you may be stuck in sortof a freezeframe for a moment, you yourself could move, changing the orientation with you and the frozen objects; thus making the frames non repeating (only the relationship of the physical location of characters in the world).

i could be wrong about this, as i'm no programmer; i'm just going by general knowledge and what i've learned from being close to a dev team of one of these mods.

edit: note, in original quake3 style games, trickjumping could normally be done with any framerate, it just made it easier to achieve certain heights with certain FPS caps (due to the physics calculations).

edit2: clicky (http://ucguides.savagehelp.com/Quake3/FAQFPSJumps.html)

edit3: i'm not satisfied with my explanation yet, lol. if you click the link and check the second picture, you will see how the physics update with every frame. well, i'm sure you know physics is the orientation with you and the world; so not calculating the rest of the physics is actually a great thing (especially for slow processors), except the peak of the jump can be cut off between physics calculations; THAT is the problem. when physics are calculated with every frame, that will use the least amount of processing power required for the speed in which your computer can run the game (that's why it's a good thing). that's the reason why you should cap your FPS at 43, 76, 125, or 333... not because the physics calculations are "better", but the crest of your jump will be at the maximum physics capible height, as opposed to cutting it off as others would do (note how the purple one relates to the white one on the crest of the jump).

hopefully that explains it better.

Pafet
08-06-04, 05:18 PM
I worte "com_fixedticK " instead of "com_fixedtic"
sorry :)
and FYI you can use TAB for autocomplete