Moving a cursor with Robot makes it skip across the window?

Processing Coding Questions
1

So, I’ve been working on a 3d game for quite a while now. It’s first-person, and you look around by moving the mouse - makes sense. I’ve sent the game to some friends to playtest, and it works fine for all but one of them. For one of them, any time they’re in a portion of the game that has a script to move the cursor manually with Robot, their mouse will instead skip to the edge of the window, preventing it from ever being on the actual window. Any time the cursor is not controlled, however, their mouse CAN be placed on the window. Because only they are having the problem, I’m thinking they have some sort of antivirus on their computer that’s messing with the program, but I haven’t been able to find any solutions both online and with them sharing their screen with me. Does anyone know what could be causing this?

I’ll post my code here:

if(surface instanceof processing.opengl.PSurfaceJOGL){
    com.jogamp.newt.opengl.GLWindow window = (com.jogamp.newt.opengl.GLWindow)(((PSurfaceJOGL)surface).getNative());
    com.jogamp.nativewindow.util.Point point = window.getLocationOnScreen(new com.jogamp.nativewindow.util.Point());
    if (phase=="Play"&&pause==false) {
      robot.mouseMove(point.getX()+width/2,point.getY()+height/2);
    }
  }
1 Like
2

if (!pause && "Play".equals(phase)) {

1 Like
3

I appreciate your interest, however, I don’t see how I format my if-statements would be causing the issue. This is definitely a good thing to keep in mind going forward for comparing strings and booleans, but it does not answer my question.

4

@CosmicCrowMC The key to @GoToLoop 's answer is the use of the equals function when comparing strings.

Unlike some programming languages (Python for example), Processing(Java) will not perform a “contents” comparison on strings when double-equal is used.

Let us know if changing that still does not help.

2 Likes
5

You might be better not mixing JOGL and AWT’s Robot. GLWindow also has capability to do similar. Possibly some odd interactions going on. See GLWindow (JOGL, NativeWindow and NEWT APIs)

EDIT : also might want to consider whether it’s a high DPI screen - could be coordinates don’t match up.

Yes, this is true and something to watch for. However, if all definitions of "Play" are literals in the source code, they will also be object identical, so this shouldn’t be the cause of the bug. Worth fixing still!

3 Likes
6

Works like a charm now! You were right - the two libraries must’ve been messing with each other. Thank you so much!!

1 Like