Sweet! Two problems down in the last 15 minutes. I simply moved the cursor removal method call after the requestFocus() call...working nicely. (The other problem was rebuilding joal to fix the endian-ness issue with os x)

Now if I can get the robot.mouseMove() from being so choppy, I will be a happy camper. It recenters the mouse, but only intermittently. Since my camera movement is relative to the center of the screen, it looks/runs horrible...

[...]Now if I can get the robot.mouseMove() from being so choppy, I will be a happy camper. It recenters the mouse, but only intermittently. Since my camera movement is relative to the center of the screen, it looks/runs horrible...[...]

Ah... hehe

Well, this isn't a problem with robot itself. It's the way you've used it. Since robot/the event stuff weren't build with first person shooters in mind it's a bit counter intuitive, but not impossible.

Ok. I'll try to explain it.

You need a small object for storing the relative coords. Whenever you pickup those cords you have to set em both to 0. <edit>This is done once per frame</edit>

Your MouseMotionListener needs to overwrite mouseMoved and mouseDragged (mouseDragged just calls mouseMoved with that event object).

Ok. When the mouse is moved you:if(!ignore)-determin the relative offsets-add em to the current relative offsets (that small object, I mentioned before)-set the ignore flag to trueelse-move the mouse to the center-set the ignore flag to false

You have to do it like that, because there can be more than one pair of new mouse coords per frame and because the robot's movements also trigger mouse moved events.

/** The input listener handles all input for the game. It allows direct checking * of key states and processes mouse movements. */publicclassInputListenerimplementsKeyListener, MouseListener, MouseMotionListener, KeyEventPostProcessor{// used for calculating mouse movementprivateintmouselast_x;privateintmouselast_y;

And when you pick those values up (once per frame), you've to set both vars (mouseX and mouseY) to 0.

So if there are two events for one frame... +5/-2 and +3/-1 it ends up with +8/-3 (instead of +3/-1 [your version]). And if there are two frames for one event it could end up with something like +5/-2 and 0/0 (instead of +5/2 and +5/2 [your version]).

Using some filtering method would smooth that case out, where you have more frames than mouse events, but it's usually not important since usb runs usually @125hz and ps2 runs usually @60-100hz (which is high enough for smooth input).

I think I'm going to give up on getting it to work properly on OS X. I understand your code, and I'm actually doing something quite similar, but the accumulation is occuring in the Camera class, then every frame the Camera class is used to update the current view matrix. I left out some important code on my post...

The problem is that on OS X, it really just is not recentering. I noticed it before you helped me fix the cursor. You could move the cursor to the side of the frame and it would stay there until you moved the mouse again.

Anyways, I appreciate your help very much. I will investigate it more when I can, but for now, I need to focus on 'finishing' the game before Friday!!!

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org