[z64555]

Hey everyone, I'm considering doing a change to the mouse behavior that'll effectively make the turning rate consistent across video resolutions for the same exact player craft and the same exact mouse sensitivity setting. Currently, FSO scales down the turning rate (when controlled by the mouse) as the resolution goes up, possibly a by-product of the differences between the desktop resolution and the game resolution.

I'd like it to be a consistent behavior, so that overly competitive players won't be tempted to degrade their resolution to gain a turning rate advantage over players with normal/higher resolutions.

Since I'm not the sole person playing the FSO, I felt it was a good idea to *ask* the community before this goes into trunk (it'll go through AP first, since SDL Everywhere is in AP right now). So, here's the poll.


Poll results:
27 - Consistent.
0 - Default behavior (ramp decreases as resolution increases)
0 - Opposite behavior (ramp increases as resolution increases)
1- Snuffy

[The E]

Why is this a question? It HAS to be consistent no matter the resolution. Introducing a scale factor based on resolution is completely and utterly wrong.

[z64555]

AFAIK, there isn't a scaling factor applied anywhere in the FSO code. Rather, this is a by-product of what FSO/SDL grabs from the OS's input/output API.

[chief1983]

I'm with The E here, if there is an apparent difference in behavior in game based on your resolution, that's a bug.  If I move my mouse X cm at Y cm/s, the in game view should move Z degrees regardless of resolution.  The only time I can see there being an issue here is with how different aspect ratios might affect the FOV, which I believe would maybe affect how the Z degrees of movement might be perceived.  But that's not so much technically the resolution difference causing it as it is the aspect difference.  If that's the case, we need to investigate how to fix that, but I might be inventing problems in my head.

[Nuke]

so long as the resulting output maps to a -1 to 1 range before being applied to anything in the game i dont care how it scales.

needless to say if you have to change your screen resolution to make your input device work the way you want it to, something is broke.

[Zacam]

To settle this from my perspective (and I think the terminology usage/divide is complicating things):

Changing the resolution in AP Builds or in Trunk Builds, does not currently change the input smoothness/acceleration rate in the mouse flight controls at all. Nor does changing Windowed/Fullscreen/Borderless (-fullscreen_window)

What the difference is, is that currently under the exact same settings and resolutions, flipping between Current AP and Current Trunk has significant differences, so we're discussing how to address that and how to approach the right factor. (Where's Quantum Delta when you need him? )

And at a truly 1:1 mapping, your resolution would control your movement if all else stayed the same. If DPI/Sensitivity dictates that for C in centimeters of physical movement the cursor moves X pixels at Y resolution and it stays moving at the same C to X when you change resolution, your perceived distance of motion is now 'more' or 'less' even though you've still moved the exact same number of pixels in the exact same physical distance traversed.

So, actually, you DO have to enter a scaling factor based on resolution to make the perception of screen traversal RATIO feel the same. People have just gotten used to that NOT being the case or something tells them that it's 'wrong' when working more as intended vs. what they desired namely because a lot of games already handle that invisibly to them outside of whatever modifications they have to make due to customizations or options that adjust that behaviour. And for the longest time, stock Trunk/Retail has done exactly that, where as with the SDL code, we're essentially back at the "drawing board" so to speak, so we're fishing.

[Fury]

How about all three if at all possible? Use no scaling as the default with the other two as user options. That way everyone can pick whatever they find suits them best.

[jr2]

.. Are you saying this would not affect (over or under clock) the turn speeds of various craft at all?

Because it if does, then, basically, you just have to raise / lower your screen resolution to affect gameplay in your favor (or against you, if you have hardware limitations that force you to drop resolution for example)

[z64555]

.. Are you saying this would not affect (over or under clock) the turn speeds of various craft at all?

Because it if does, then, basically, you just have to raise / lower your screen resolution to affect gameplay in your favor (or against you, if you have hardware limitations that force you to drop resolution for example)

That's what the SDL builds are doing currently, or at least, is much more significant than what trunk is currently doing. The maximum turn rates of the crafts are still at a fixed rate, but you just can't hit that maximum with the mouse. In a negative correlation (which is what SDL has), you have less of a reachable maximum as your resolution increases. With a positive correlation (which is opposite of what SDL has), you have a higher reachable maximum as your resolution increases, up until the maximum capability of your craft.

Competitively speaking, I feel that both the negative and positive correlations are a bad idea, because players will opt to decrease/increase their settings for the sake of getting the maximum turn rate possible from their craft, making the playing field biased towards whoever can milk the maximum performance from their craft by exploiting quirks such as this.


Currently, we're shooting for a solution that would at least match trunk behavior. From there, we'll look into improving the status towards whichever correlation the community finally decides on.

[Kolgena]

So, actually, you DO have to enter a scaling factor based on resolution to make the perception of screen traversal RATIO feel the same. People have just gotten used to that NOT being the case or something tells them that it's 'wrong' when working more as intended vs. what they desired namely because a lot of games already handle that invisibly to them outside of whatever modifications they have to make due to customizations or options that adjust that behaviour. And for the longest time, stock Trunk/Retail has done exactly that, where as with the SDL code, we're essentially back at the "drawing board" so to speak, so we're fishing.

Doesn't this only apply to games like starcraft, where a cursor has distinct quantal positions it must reside in? When we're talking about games like FSO or FPSes, movement should be in angles deviation, not screen pixels. After all, it's fairly straightforward in a first person game to make sub-pixel motions when the minimum allowed angle of deviation is very small. Either way, since your quanta of motion is in angles rather than pixels, it should be resolution independent, no?

[The E]

It all depends on how the OS is reporting the mouse movement, and how we're interpreting the incoming data. The movement we receive is always in screen pixels.

[z64555]

K, so, a 27 "consistent" to 1 "snuffy" vote ratio means we can probably remove the poll now.

Courtesy of m|m, the behavior has been applied and committed to antipodes, so expect this feature in a 3.8.0 build soon^TM.

[Kolgena]

I wonder if the way mouse is handled has anything to do with the severe loss of sensitivity and mouse lag at framerates <25 fps...

[m!m]

Did you encouter this in antipodes or trunk? If you encounter it in antipodes then I fixed that issue recently.

[Kolgena]

I encountered it consistently in trunk many months (years?) ago. It usually presented as massive slowdown when you spray primaries at a warship at close/medium range. The 8 lights lighting up a huge chunk of screen used to cut my framerates by 80% and cause me to lose control and crash headfirst into whatever I was shooting.

It's been less of a problem with the new computer, but still sort of happens when I run WiH with shadows and deferred lighting. It's enough that I can't aim for **** if my framerates drop under 60 or so. Do you know if polling rates might play a role in this, either positively or negatively? Is the mouse input polled only once per frame?