buggy PM_AdjustAimSpreadScale(), spread fps dependent


(brugal) #1

There seems to be a bug in bg_pmove.c:PM_AdjustAimSpreadScale() with respect to frames per second and mouse rate. The higher your fps compared to your mouse rate the more it’s seen as a series of pauses and violent movements. For example, if you have 300 fps and your mouse updates at 100 times per second, PM_AdjustAimSpreadScale() will be called
roughly three times for every mouse update. Only one of those calls will see a change in mouse movent and increase your spread, the other calls will see zero change and simply apply a spread reduction. The problem is that there is a max error value for viewchange, so it’s beneficial to have your movement seen all at once as opposed to spread out.

You can test this out visually with cg_crosshairpulse. Find a map where you can get really good fps and move the mouse around while trying different com_maxfps values.

On my computer, at about 200+ fps and mouse rate approximately 100hz, I can move the mouse around all I want and not even affect my spread. With fps like 43 and 76 it doesn’t take much to reach max spread. :frowning:


(ouroboro) #2

what if i cap at 125 fps but i have messed with my usb drivers so i get 500 hz on my mouse? am i getting the opposite effect = MORE spread than i should?


(djmels) #3

don’t think so, since the engine (as far as I know) will only “check” the mouse location for every frame it renders, not in between the frames. so, if mouserate > fps, effective mouserate = fps. this is only my theory, I am NOT BY FAR sure :wink:


(squadjot) #4

You can test this out visually with cg_crosshairpulse. Find a map where you can get really good fps and move the mouse around while trying different com_maxfps values.

On my computer, at about 200+ fps and mouse rate approximately 100hz, I can move the mouse around all I want and not even affect my spread. With fps like 43 and 76 it doesn’t take much to reach max spread.

if thats a fact that would be terrible…


(Sauron|EFG) #5

Are you sure it’s not simply another case of client-side prediction not matching what happens on the server? It would still be a bug I guess, but I don’t think anyone cares if it only affects crosshair pulsing.


(ouroboro) #6

i am VERY interested in this. hopefully an etmain/etpro dev can speak to this issue. perhaps reyalP also. i hate to say it, but if there is in fact a legal exploit to get reduced spread, simply knowing that others are aware of it would force me to do it as well.

i really hope it’s untrue, but if it is, i hope it can/will be fixed…


(Rain) #7

I’m fairly certain that the client doesn’t predict the spread scale at all, in which case this is Badâ„¢.

Looking at this is on my todo list, I’ve just been quite busy work with lately. :weird:


(ouroboro) #8

thanks Rain. please let us know anything you discover, this could be big stuff :eek:


(squadjot) #9

i was also very interested in this… i asked reyalP and he discovered a actual bug, and fixed it too \o/

http://www.splashdamage.com/index.php?name=pnPHPbb2&file=viewtopic&t=11974


(SCDS_reyalP) #10

Note that what I found isn’t related to mouserate. There might still be some issues with that too.