No announcement yet.

Mouse Input investigation

This is a sticky topic.
  • Filter
  • Time
  • Show
Clear All
new posts

  • replied
    There's a guy named Chris - he's doing really nice videos about input latency in games on his channel on YouTube - called Battle(non)sense (but mostly focused on BF, CSGO and Overwatch). I think he could help (if we ask nicely ) with practical data and measurments (as he got high speed recorder and other equipment). I've contacted him a while ago and he did responded but wasn't sure if game is worth looking while being so early prototype.

    Leave a comment:

  • started a topic [OFFICIAL] Mouse Input investigation

    Mouse Input investigation

    Hey everyone, I have been doing some research on the mouse input concerns as it is something the community has been bringing up time and time again. I read through the entire giant mega thread from awhile back and decided to start a fresh and new thread with the issue.

    Pete Knepley worked with you guys in the past to try and find possible solutions. He will still be involved in this however I am going to be a conduit to help find a repro that he can perform. This is the biggest challenge with this issue right now; trying to take an input issue that is primarily felt by the user and not really seen, then translating the issue where it can be confirmed by the devs so they can develop a solution for it.

    Through several scenarios I have noticed a few situations where the mouse input was feeling wonky or off to me personally. These scenarios ranged from testing on 60hz vs. 144hz monitors to different FPS caps. However there can be many causes to this issue ranging from system performance, engine, latency/lag, or possibly other gameplay mechanics that may have influence on aim, such as movement.

    The goal here is to try and separate placebo from hard data, which is easier said than done. I want to have hard evidence that points to something specific so we know where to look without spending too much time chasing phantoms.

    We do not want this thread to descend into unproductive discussion, the entire purpose for this is to focus purely on technical data and evidence. Any flaming, out of line, or off topic comments will be addressed immediately.

    As stated in this reddit thread - having the following information will be helpful. I will catalog all of this information so we have a reference point to feed off of:

    • DXDiag (CPU, GPU, Ram, Current GPU Drivers, etc)
    • Monitor Specs and current Refresh Rate (60hz, 120hz, 144hz, etc)
    • Mouse Specs - Brand, Polling Rates, DPI, etc.
    • Screen settings in UT (Windowed, Windowed(Fullscreen), Fullscreen, vsync on or off, etc)
    • UT Mouse Settings
    • Windows Mouse Settings (is enhanced pointer precision enabled, etc) - this should not have an impact at all because of how UE4 uses mouse input but I would like to have this information tracked.
    • If you have customized your UT .ini files for better ‘performance’ or ‘input’ please share those as well.
    • If you have any information / videos that showcase the input issues you're experiencing this will help as well - granted this will be much harder to read, it will at least give us an idea of what to build a test case around.

    Here is what we do know

    Engine: If this is an engine issue this may be related to 'Input-to-Photon' vs. 'Raw-Tick-Rate'.

    • Quake Live: runs at 150 fps, without a GPU thread or threaded renderer, this puts their input-to-photon time theoretically at 7 ms. Note that this is possibly capped by the refresh rate of the monitor and your computer may run Quake Live even faster than that.
    • Unreal Tournament: runs at 150 fps with a GPU thread and a threaded renderer, leaving our input-to-photon time at 21 ms to 28 ms.

    We have plans to improve input-to-photon. When the engine fully moves to DX12, this should give us a full frame of latency back. There are other very large work items, like running our render and game updates on a single thread or decoupling framerate and network traffic to bypass the 150 fps limit.

    Game Mechanics: Strafing Left and Right may be one related issue to mouse input being thrown off. Strafing left and right in UT has an acceleration and deceleration event. The abrupt change of moving left to right or vice versa may be causing the users aim to be thrown off. This can be felt really well by trying to maintain your crosshair on a fixed target while strafing left and right.

    Performance: There can also be an underlying issue with mouse input and performance, this is an issue that is experienced in other games and could be considered a separate issue entirely.

    The most important thing is that we try to find data that can be quantified. This will not be an easy task, nor a quick one, but I’m hoping that we can work together to find an answer to this concern.

    Thank you all, I look forward to working with you.