I’m seeing an issue with mouse Coordinates while using jme3-LWGL3.
The coords are not accurate, they come across as “SCREEN COORDS” not window coords.
When using JME3-LWJGL the hit box for GUInode work correctly but when using JME3-LWJGL3 the mouse coords do not work as the Node might say 100,100 but the mouse Coords could some across as 3200,1000 depending on where the window sits.
Kevin
Which JME versions are affected?
It does it in 3.4 and 3.5.
This is due to the onCursorPos. It is scaling the mouse coords because of the DPI scaling. So on my machine shows a a screen scale of 2.5 (DPI). So this method is multiplying the mouse coords by 2.5. So if you define a 200x200 window. The far left will be 500 and top will be 500.
So all of the coords will not hit right with Ray or anything like this because the Node position might be 100,100 but when your in the middle of the screen you get 250,250. So the AABB checks will fail.
I don’t know why scaling for mouse coords are inside this function. This is not normal.
Can someone explain the reason why they think this should be in there because any program using LWJGL3 will need to get the DPI and divide the coord again to get clicks inside of screen space.
I say this scaling should be removed.
GlfwMouseInput
private void onCursorPos(final long window, final double xpos, final double ypos) {
float[] xScale = new float[1];
float[] yScale = new float[1];
glfwGetWindowContentScale(window, xScale, yScale);
int xDelta;
int yDelta;
int x = (int) Math.round(xpos * xScale[0]);
int y = (int) Math.round((currentHeight - ypos) * yScale[0]);
xDelta = x - mouseX;
yDelta = y - mouseY;
mouseX = x;
mouseY = y;
System.out.println("Delta "+xDelta+","+yDelta+" M: "+mouseX+","+mouseY);
if (xDelta != 0 || yDelta != 0) {
final MouseMotionEvent mouseMotionEvent = new MouseMotionEvent(x, y, xDelta, yDelta, mouseWheel, 0);
mouseMotionEvent.setTime(getInputTimeNanos());
mouseMotionEvents.add(mouseMotionEvent);
}
}
The onCursorPos() scaling code isn’t included in v3.4:
Please re-confirm whether this happens in 3.4 …
Sorry, my engine was based on 3.4 but I did pull in several changes from 3.5.
Looks like it was changed in.
Alright, I’ll revert PR 1607 and cut a new beta.
Yes it works in 3.4.
I read the comments for this MAC needing the scaling. Just know Windows and Linux doesn’t need this and if MacOS needs this, then it needs to be checks for Mac or not.
On the internet there are many people talking about needing this for MacOs because it works differently.
Just to be clear: the issue is caused by the “UseRetinaFrameBuffer” app setting defaulting to “true” on non-Macintosh systems?
If so, then setting settings.setUseRetinaFrameBuffer(false) in your main() should solve the issue. Does it?
That has no effect. The scaling in that method is set to do this no matter what.
May it should check to see if this setting is on and then do the scaling.
But the default is TRUE so it would do it all the time and all games will break when it comes to GUI interaction.
With the scaling off it works out great on my apps and all the other JME apps/games I got off GitHub, when it is in there none of the clicks on buttons work.
HiDPI and scaling are a feature also on Linux and Windows. Just that Macs beat everyone else in the game with those Retinas. Thus being more common there.
GLFW seems to handle Retina differently from pixle scaling on non-macOS platforms. It defines a window hint specifically for Retina:
/** Specifies whether to use full resolution framebuffers on Retina displays. This is ignored on other platforms. */
public static final int GLFW_COCOA_RETINA_FRAMEBUFFER = 0x23001;
and when that hint is set, mouse locations require extra scaling.
Yes. I think the scaling should placed inside a “IF” statement if Retina is on then do scaling otherwise don’t. And default should be “OFF”
That solutions works for me.