Is there a limit to how fast a system mouse can move?
I'm playing around with "cliclick" a mac osx library that controls a system mouse. I'm moving the system mouse from 0,0 to 100,100 covering every point in that rectangle. Cliclick lets me set a delay of 20ns per movement. It should cover 10,000 pixels in 200ms, but instead it takes about 3 seconds even if the delay is set to 0. Is there a limit to how fast a system mouse can move to different points on the screen?
Related
I'm currently trying to make my simple game scale with the resolution. I've noticed though when I change the resolution not everything works out. For instance from the shift from 1280x720 to 1920x1080 the jumping distance changes slightly. The main problem I've noticed is that when I fire a projectile with a velocity. On lower resolutions it seems to travel across the screen significantly faster and I can't understand why as it should scale down with the size of the window. Here is a snipet of the code that fires a projectile:
m = new Box(l.pos.x+Width/32*direction2, l.pos.y-Height/288, Width/64, Height/72, true, 4);
m.body.setGravityScale(0f);
boxes.add(m);
m.body.setLinearVelocity(new Vec2(Width*direction2, 0));
In this scenario m is a box I'm creating. In new Box(spawn x coordinate, spawn y cooridinate, width of box, height of box, is the box moveable, type of box) l.pos.x and l.pos.y are the positions I'm firing the box from. The Height and Width variables are the size of the current window in pixels being updated in void draw(), direction2 is either 1 or -1 depending on the direction in which the character is facing.
Hard to tell how the rest of code affects the simulation without seeing more of it.
Ideally you would want to keep phyics related properties independent from the Processing sketch dimensions in terms of dimensions but maintain proportion so you can simply scale up the rendering of the same sized world. If you have mouse interaction the coordinates would scale as well, but other than the position, the rest of physical proeprties should be maintained.
From what I can gather in your code if Width is the sketch's width you should de-couple that from linear velocity:
m.body.setLinearVelocity(new Vec2(Width*direction2, 0));
you should use a value that you will keep constant in relation to the sketch dimensions.
Is it possible to get the position of a ltk (Common Lisp basic GUI library) window (one of its corners), in pixels from the top left screen corner?
I'm trying to use mouse movement to control an applet I'm making (details here), but I can only find the mouse's position relative to the window, and I can only set it relative to the screen itself. I want to hide the cursor and return it to a fixed point after every move, noting how it has moved. I need to know the window position to correct for the different measurements.
The manual gives several options for manipulating the toplevel, such as moving the window around or finding its position and dimensions. The particular expression needed here is (geometry *tk*), which returns a list of the window's x and y position and size.
I'm trying to build an Input Handler in Coco2D-x for a 3D game.
I want to control the camera rotation using the mouse, like an FPS. To achieve this, I need to store the previous and current mouse position every frame to calculate the delta movement per frame and apply it as a rotation.
The only way that the documentation shows to get the mouse info, is through Mouse Events and the Event Dispatcher. I tried that, but it is not useful for the position because, that way, I will only refresh the previous and current position when the mouse moves. if the mouse doesn't move, I still have some delta movement (calculated N frames ago, when the mouse moved the last time) and the camera will move forever.
Is there any way to get the position of the mouse every frame?
I'm also open to any suggestions on how do the camera movement with the mouse.
I'm using Cocos2d-x 3.13.1 and Visual Studio 2015 on Windows 10. The project is on C++.
Thanks.
I am not an expert on Cocos2D, but from this:
The only way that the documentation shows to get the mouse info, is
through Mouse Events and the Event Dispatcher. I tried that, but it is
not useful for the position because, that way, I will only refresh the
previous and current position when the mouse moves. if the mouse
doesn't move, I still have some delta movement (calculated N frames
ago, when the mouse moved the last time) and the camera will move
forever.
I think that resetting the deltas to 0 after the camera rotation calculations will solve your problem using these events.
I found a solution, maybe not the best, but the easiest one.
InputHandler is still in control of the mouse events, and it only stores the current position of the mouse. This position is updated only when the mouse is moved.
CameraController is asking, every frame, for the current position of the mouse. Before doing this, it's storing the previous one.
That way, I can control if the mouse moves or not.
So basically I calculate the delta wherever is necessary (camera controller in this case) instead of calculate it every frame (as I intended with the Input Controller).
This is within the update function in CameraController
mousePreviousPos = mouseCurrentPos;
mouseCurrentPos = inputHandler->GetMousePos();
mouseDelta = mousePreviousPos - mouseCurrentPos;
if (mouseDelta.x != 0)
{
ApplyRotationAroundY(mouseDelta.x);
}
if (mouseDelta.y != 0)
{
ApplyRotationAroundX(mouseDelta.y);
}
I will stay tunned for more or better solutions.
Thanks!
In my simple school project, there is a character that moves using buttons. When deciding how I wanted to move a sprite I stumbled upon this dilemma, why use speed? They look pretty much identical to me so far.
Here is what I mean (the top MoveTo block and the bottom one seem the same)
of course given i set the character.speed to 10 in screen init.
What would I benefit by replacing the simple integer value with character.speed?
You can set the heading and the speed of an image sprite and the image sprite will move automatically into the direction defied by heading. Alternatively use the MoveTo method to set the image sprite to a defined x/y coordinate.
See also the documentation
Heading
Returns the sprite's heading in degrees above the positive x-axis. Zero degrees is toward the right of the screen; 90 degrees is toward
the top of the screen.
Interval
The interval in milliseconds at which the sprite's position is updated. For example, if the interval is 50 and the speed is 10, then
the sprite will move 10 pixels every 50 milliseconds.
Speed
The speed at which the sprite moves. The sprite moves this many pixels every interval.
Is there a way (API) of getting the size (vertical and horizontal) in pixels of the resize corners?
I am referring to the area at each of the corners of a window where you can resize the window in both directions (Left-to-Right and Top-to-Bottom) at the same time using your mouse. You will know you are there with your mouse cursor when you hover over the corners of the window and the mouse cursor is a Diagonal Resizing cursor.
Thank you
Edit:
An example: Hover your mouse over the right edge of a sizable window. Start in the middle (vertically) of the window and move the mouse up along the edge until the horizontal sizing cursor changes to a diagonal sizing cursor. How do I determine by asking the OS how far that position when the cursor changes, is from the top of the window.
I would suggest to use the size of the scrollbars. Call GetSystemMetrics with SM_CYHSCROLL and SM_CXVSCROLL. May be also SM_CYSIZEFRAME and SM_CXSIZEFRAME sizes can be combined.
But I think a better value is to use the height of the status bar. However even Microsoft Windows seems to use some fixed value as can seen on the screenshot.
Comparing the results of GetClientRect and GetWindowRect will tell you how wide the non-client (border) area is along each edge of the window.
If you're concerned that it might not all be active for sizing (true especially along the top), or you want to distinguish the diagonal sizing areas from edge sizing areas, you can take the coordinates discovered in step 1 and pass them to SendMessage(WM_NCHITTEST) See its documentation for the various return codes. There's no problem sending this message repeatedly -- it's designed to be called for each mouse move event and therefore is very fast.