Bug: SWL client mouse pointer drifts even when mouse is stationary.
Cause: Desktop (rclick) / Display Settings / Scale and Layout / (not 100%)
Fix (bad): Use 100% scaling
Fix (better): App (rclick) / Properties / Compatibility (tab) / Override high DPI scaling / Application
The app you’ll want to apply that property to is the SWL icon you typically click to start the game. If you sometimes start the game in different ways, you might need to apply it to each depending on what you’re doing. This is a fix that can easily be done by Funcom’s installer and/or patcher.
The last one might need a little more explanation. That setting has changed names in various Windows versions. Older ones called it something like “Disable automatic high DPI scaling” and the current name change has even less to do with what it does than the last one. The above setting doesn’t disable scaling by the app, it disables the UI/window scaling by the OS for just that app (sets it to 100%).
TL;DR/WOT for the morbidly curious
Why does this cause drift? The app needs the mouse location for two things: gfx location (to target world environment) and windows location (to target UI elements). The mouse is in the same spot for each, but the (x,y) for each is different and the code isn’t written correctly to handle that difference. Likely, they just never tested the game on a display with scaling set to anything but 100%.
The reason this never gets fixed is because apps and MS differ on who’s bug it is. MS does the autoscale by faking the resolution, but only within it’s window/ui. Works great until you mix window/ui with non-window things like a graphics viewport at some other arbitrary resolution. If windows did a complete job, the resolutions would end up normalized on input and output to the resolution of the display. Instead MS assumes that apps all know the window/UI might be at a different resolution and blames them for not handling a potential difference. Apps, of course, blame MS for incomplete scaling or tell users “set it to 100%” – after all, their app is the only one in existence and it doesn’t matter that 100% makes the rest unusable.
BTW, IMHO, they’re both to blame for bad attitudes, but it’s a MS issue. It’s strategically better to fix something in a single location with one bit of code than to replicate that code throughout every app that might require it even if only a small percentage of apps might have the issue. If the CPU cost was large, then MS’ decision makes sense. It’s trivial, though – couple extra integer multiplications applied to mouse movements under scaling.