Page 1 of 3

com_maxfps

Posted: Tue Jan 01, 2019 8:32 pm
by evirdrevo
Back in the days the fps got max capped at 125hz because of a minor bug gave less spread from moving the mouse. Basicly if you had fps 250 and hz rate 125 you got no extra spread from moving the mouse. I pointed this out ages ago (2005 or so) and the clanbase config and much of the etpub community switched to com_maxfps IN 40 125.

Taking into account most gaming monitors support 144hz out of the box and almost all people having a 144hz monitor would be playing on a 500hz mouse or more, can we restrict the fps cap up to 144 maybe even 200?

Yes if you'd run a cheap non gaming mouse you'd get a minor reduction to the spread but take into account this cfg limit was put into place back when 90% of the people were playing 125hz mouse but today almost everyone uses 500hz or more if he has a gaming mouse. You are still at handicap at 144hz - 125hz mouse and even 200hz - 125hz can be considered fair vs 200hz - 500hz mouse.

For those not getting any of the tech babble, i'm suggesting you can play with more FPS which will give you a noticable better gaming performance with a diminishing return once you go +200hz.

I almost feel like that crazy guy posting ppl controlled his ET ...

https://dev.etlegacy.com/boards/3/topics/513
it this bug but in ET, not ET legacy

Re: com_maxfps

Posted: Wed Jan 02, 2019 1:52 pm
by c0rnn
In QL and Reflex you end up with 166 fps with com_maxfps 144, don't know about ET.

Re: com_maxfps

Posted: Wed Jan 02, 2019 7:29 pm
by Hi123
.

Re: com_maxfps

Posted: Wed Jan 02, 2019 7:31 pm
by Hi123
.

Re: com_maxfps

Posted: Thu Jan 03, 2019 6:35 am
by hyperloop
evirdrevo wrote:
Tue Jan 01, 2019 8:32 pm
that crazy guy posting ppl controlled his ET ...
Why even bother with this guy? This is blatantly just spam, and when he is on the server he only TK's anyway..

Re: com_maxfps

Posted: Thu Jan 03, 2019 5:45 pm
by evirdrevo
indeed, i forgot.

You are better off creating a custom resolution with hz = fps anyways. just like most people on 144hz monitors are too lazy to add 125hz and just use 120hz which is less optimal :p

Re: com_maxfps

Posted: Mon Jan 14, 2019 7:35 pm
by evirdrevo
Since there hasn't been a reply by cornn yet, I'll post a better explanation of the bug.

In ET there are two kinds of spread, spread caused by player movement and spread caused by moving the mouse which is far less noticable compared to the first one mentioned. To try this bug just start a server yourself and set com_maxfps 125 and your mouserate to 125 hz, next use cg_drawspreadscale 1. Every frame ET checks if there is any mouseinput, if yes spread goes up if no spread goes down. When you use 125fps / 125hz you get one mouseinput every frame (well not really but lets assume it does for science sake!) so when you move the mouse a little bit of spread gets added. If you stop moving the mouse the spread drop.

Now in a second scenario you set com_maxfps to 250 and mouserate still at 125hz. Since you only send a mouseinput once every two frames ET assumes you aren't moving and doesnt add any extra spread for moving the mouse.

Now in the third scenario you allow com_maxfps 144 and you will have people who still use 125hz (which is laggy as hell compared to 500 or 1000hz gaming mice use) and they get a small spread reduction -10% on an already small modifier to the gun spread.

In most scenario's people with 144fps and a 144hz monitor are using a gaming mouse running at least 500hz and there will be no benefit except being able to use a hardware standard of 2019 and play a more fluid game!

Re: com_maxfps

Posted: Mon Jan 14, 2019 8:25 pm
by c0rnn
c0rnn wrote:
Wed Jan 02, 2019 1:52 pm
In QL and Reflex you end up with 166 fps with com_maxfps 144, don't know about ET.
If that's okay too I guess.

Anyway, enabled, give it a try and report.

Edit:
Image

Re: com_maxfps

Posted: Mon Jan 14, 2019 10:11 pm
by a domestic cat
evirdrevo wrote:
Mon Jan 14, 2019 7:35 pm
Every frame ET checks if there is any mouseinput, if yes spread goes up if no spread goes down.
Isn't this complicated by the fact ET doesn't use raw mouse input? Just asking, as I fail to recognize noticeable spread difference on any framerate.

Also, as mentioned in previous post - does the alignment worth it considering how it affects physics and also possibly recoil of weapons? Don't get me wrong, I'm not against increasing the limit as it's up to everyones framerate limit, but there's a reason behind 43/76/90/125/250/333 values. With lower limit, you get reduced recoil and weapon spread (sniper, especially), with 125 and more, you can jump higher/more far, but the recoil increases (it's hard to hit someone with sniper on 333, you can actually compute the probability of hit).

Most people use 125, which is somewhat moderate, it's also where pmove_fixed 1 together with unchangeable pmove_msec 8 targets (1000 / 125 = 8) and in an ideal world, players with less then 125 should experience same physics/recoil conditions as those with 125 FPS stable.

Re: com_maxfps

Posted: Tue Jan 15, 2019 12:39 pm
by evirdrevo
Afaik movement has been fixed and is no longer gps dependent. If you tested on a local server you might have grotten bad server settings. Can you test it on hirntot?

Recoil is affected by fps but you can always set luger to 71 fps. alsof you can use rinput to add raw support to er but it won't affected spread. 71fps is the lowest recoil you can have, raising or lowering the fps adds recoil.

The 166fps Cap is indeed 'forced' by the Quake engine, i think you could vsync to get 144 fps but that adds output lag. 166fps Will still give reduced input lag and a smoother game experience, especially for those Running 60hz or 75hz panels.

https://www.crossfire.nu/news/4053/rinput-v12-released