Quake3World

Hi all,
is it my system capping Q4 at 60fps or is it capped in-game? I can't seem to find any files which would allow it to be uncapped like I used to be able to with Q3.

Any help would be much appreciated.

It's the Doom 3 engine (which is used for Q4) that caps the fps to 60, to prevent things like the speed boost you get at 125 fps in Q3.

Fuck, that's pretty lame. Oh well thanks for your reply.

Why?? 60 fps is more than enough dont you think??

with the new patch 65fps runs smoothly for me. I have no complaints

the cap can be changed server side iirc - the exact command escapes me for the time being though

Zimbo wrote:Why?? 60 fps is more than enough dont you think??

It's 'enough', but more fps makes things noticeably smoother and easier on the eyes.

Oeloe wrote:It's the Doom 3 engine (which is used for Q4) that caps the fps to 60, to prevent things like the speed boost you get at 125 fps in Q3.

is stuff still frame-based? thought they changed it

Oeloe wrote:It's the Doom 3 engine (which is used for Q4) that caps the fps to 60, to prevent things like the speed boost you get at 125 fps in Q3.

NO!

The way the doom 3 engine was written, there is no longer the necessity for 125 fps to ensure proper movement.

60 FPS is more than enough on this engine.

Maybe you should read my post again. I didn't say 125 fps are needed in Q4/D3. Physics are obviously still not framerate independant though, otherwise the 60 fps cap wouldn't be necessary. FPS are just capped at 60 to keep the tic rate constant. Weird things happen when com_fixedtic is disabled.

Oeloe wrote:Maybe you should read my post again. I didn't say 125 fps are needed in Q4/D3. Physics are obviously still not framerate independant though, otherwise the 60 fps cap wouldn't be necessary. FPS are just capped at 60 to keep the tic rate constant. Weird things happen when com_fixedtic is disabled.

Did you read what I wrote?

Here:

John Carmack wrote: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.

more than 60 fps are not needed on this engine.

Zimbo wrote:Why?? 60 fps is more than enough dont you think??

Well I assumed that excessive frames would help with manouverability like it did in Q3 but as I read more posts in this thread I see that it's apparently not necessary.

duffman91 wrote:more than 60 fps are not needed on this engine.

I didn't say it was. I know it doesn't do much as long as the tic rate is fixed at 60 Hz.

More than 60fps isn't "needed," no. But the more, the better, as far as smoothness is concerned. Wish I could raise it to 75 or sth.

if your computer is able to render at 75fps but the game caps it at 60 it doesnt matter for the smoothness, since it can hypothetically render more

This did this so that everybody would have the same movement, therefore people with l33t systems wouldn't gain an advantage.

MKJ wrote:if your computer is able to render at 75fps but the game caps it at 60 it doesnt matter for the smoothness, since it can hypothetically render more

Eh? Duplicate rendered frames obviously can't make things smoother because you can't see the difference between the frames. But if the tick rate could be set to 75 Hz it would be smoother.

If vsync was possible without mouse lags, that would be interesting though. The negative impact on mouse input (delays) makes it unusable for anyone playing Q3 or Q4 (or D3) online.

riddla wrote:maintaining 60 seems to make a huge difference vs getting less than 60 (feel-wise)

that was what i meant, indeed.
i worded it quite poorly

Why the hell and how is VYSNC related to mouse response ?

Jagou

Well, the engine waits to draw the next frame until the next vertical of the monitor takes place. Somehow it lags mouse input in Q3 and in D3/Q4 too. The difference is very obvious when you toggle r_swapinterval in the game (just sweep the mouse from the left to the right).

I believe you. Just seems odd. I suppose, the screen and the mouse / cursor / crosshair.... have to be in sync for it to register properly. In other words if you move the mouse inbetween a redraw, it has to finish the draw before it can update where the crosshair is supposed to be.

That's me speculating, I really have no clue how it really works.

Sounds pretty good though doesn't it :P

Jagou