Bug: Mouse is tied to FPS

[XiiDraco, Thrower of Raids]

Seriously? The only other game I know that f***'d up the mouse sensitivity this bad is Mass Effect 2. Game's straight up unplayable on M&K right now because of this.

Did ya multiply a frame delta by the inputs to the mouse or something? You have to actively *try* to achieve something like that. >:(

You can see it very noticeably here: https://youtu.be/I9R-DrPH43Y

I love this game but damn if it isn't rough around the edges.

[ChubbiChibbai]

I've played exclusively on mouse and keyboard both locally across two different machines and via geforce now and can't say i'm seeing this issue.

What is the video showing? I don't understand.

[Stret]

Originally posted by ChubbiChibbai:

I've played exclusively on mouse and keyboard both locally across two different machines and via geforce now and can't say i'm seeing this issue.

What is the video showing? I don't understand.

i think his video is trying to show the mouse moving at the same speed resulting in a faster rotation whenever he is looking to the indoors area, which is lighter to render and makes it run better

[XiiDraco, Thrower of Raids]

Originally posted by stret:

Originally posted by ChubbiChibbai:

I've played exclusively on mouse and keyboard both locally across two different machines and via geforce now and can't say i'm seeing this issue.

What is the video showing? I don't understand.

i think his video is trying to show the mouse moving at the same speed resulting in a faster rotation whenever he is looking to the indoors area, which is lighter to render and makes it run better

Yes. Although you have your explanation slightly backwards. The reason the camera turns faster while looking towards the indoors compared to when you look away is because the performance is worse, not better.

If you like very long and very nerdy ramblings on computer science and game development, keep reading.

It's perhaps unintuitive but lower performance results in a higher measurable time between frames. Typically to compensate for different execution speeds of computers, you multiply duration based (not impulses!!!) events by how long the previous frame took to execute in order to compensate (layman's explanation, some compensations are a little more complicated).

Unfortunately, I've noticed that it's all too common for people to go crazy with multiplying a frame delta by absolutely everything without thinking about it, and it stems from a misunderstanding about how eliminating frame dependence typically works and where it's necessary.

Anyway, back to the point, there are 2 main ways you can receive and react to mouse events in most development environments: polling and events. Polling is where you check and ask for the new position of the mouse every iteration and respond accordingly. On the other hand, responding to events involves reacting to changes in the mouse asynchronously whenever the operating system sends a message to the application that the mouse has moved.

Typically for an FPS, TPS, or any game where direct control over the camera rotation is necessary, the latter (events) is used because you can respond to mouse input faster and more accurately, however, it's more complicated as control is asynchronous and you must account for that. At decent frame rates though (60+) the differences between polling and event handling is pretty much negligible.

In either case, both of these methods share a very important trait that isn't true of controller inputs. They both measure the real distance traveled since the last time the code has run. What this means is that the input information from the mouse is already independent from how fast the game runs -- it is directly positional at that snapshot in time. If you multiply a frame delta by this? Congrats, you have now coupled your input to the frame rate and done the exact opposite of what you were trying to achieve.

We know that the game has a controller first focus so this doesn't surprise me that it has happened. When handling controller inputs you receive an x and y axis value for each thumb stick. It's typical for movement control to combine them into a single normalized vector representing direction, but there are many ways to take your inputs. This lets you apply any speed value you want as a magnitude of that vector. You can do the same for camera rotation controls.

The important thing to note here is that the thumb stick only represents a direction, not the physical distance something has moved or changed. The actual distance is dependent on the rotation speed of the camera (what you multiply that normalized vector by). Because this is an operation that happens as a linear constant over time, this needs to be multiplied by a frame time in order to prevent the controller input from being frame rate dependent.

I suspect this is exactly why the mouse is also frame rate dependent. Either someone copied similar functionality or just didn't think about the repercussions of the math involved.

Anyway, whatever the real problem, I really hope they fix it. Guess I'll stick to controller for now.