-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix #1620 #1626
Fix #1620 #1626
Conversation
MSDN says: Do not use the LOWORD or HIWORD macros to extract the x- and y- coordinates of the cursor position because these macros return incorrect results on systems with multiple monitors. Systems with multiple monitors can have negative x- and y- coordinates, and LOWORD and HIWORD treat the coordinates as unsigned quantities.
The OS is already giving us the correct coordinates. No need to scale them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suspect this will need testing on macOS retina screens /cc @colincornaby
@@ -492,7 +492,7 @@ bool plMouseDevice::MsgReceive(plMessage* msg) | |||
fXPos = pXMsg->fX; | |||
|
|||
SetCursorX(fXPos); | |||
fWXPos = pXMsg->fWx * fScale; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change broke macOS. I'll dig into why. Just for background - why didn't this work on Windows?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
WM_MOUSEMOVE and friends send coordinates that are already DPI aware, therefore there is no need to scale them. They are already scaled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That explains it. The input system on macOS does not scale with DPI. Let me consider what to do (including possibly scaling the macOS input by hand) and I'll get back to you shortly.
Suggested change for macOS, in Sources/Plasma/Apps/plClient/Mac-Cocoa/PLSView.mm
|
Co-authored-by: Adam Johnson <AdamJohnso@gmail.com>
@colincornaby I've pushed your change and an additional two to ensure that scaled coordinates are going down when the mouse is being recentered. I've verified that the code compiles, but the client login window doesn't actually seem to appear on my system. Maybe this is just a problem with my setup or an unrelated regression, but I'd appreciate your taking a glance at things. |
I am seeing the login window. Weird. I've seen the login window not appear when the client can't connect to the game server (it just gets stuck in a retry loop, might be its own bug.) When the login window doesn't appear you could try pausing in the debugger to see where it is stuck. Otherwise, this change looks good on my machine. |
Great! I'm going to wait for a green checkmark before merging, though ;)
… Message ID: ***@***.***>
|
Fixes #1620 by avoiding a double-scale of mouse coordinates. I also included a bonus multi-monitor fix.
I hardwired the cursor to always think it's hovering over a player with the name
It's a Spooky Ghost!
...On master:
With this PR:
For reference: