What is the difference between mouse position data received from SDL_GetRelativeMouseState() and SDL_PollEvent() ?
That's the same difference that there exists between SDL_GetRelativeMouseState and SDL_GetMouseState.
The former works as though x and y are:
set to the mouse deltas since the last call to SDL_GetRelativeMouseState() or since event initialization
The latter works as though x and y are:
set to the mouse cursor position relative to the focus window for the currently selected mouse
Note that events usually come with both the position relative to the active window and the delta with the last known position.
Related
I'm trying to adjust user mouse input (slow down/fasten mouse pointer) by calculating and setting the new position of the pointer every mouseMoveEvent().
It looks like the pointer is drawn in it's normal position before mouseMoveEvent() is executed. This results in a bad looking, twitching cursor.
Here is an example of how I would try to keep the pointer in a place, ignoring user input.
Expected behaviour: The pointer stays steady in one place when I move the mouse.
Observed bahaviour: The pointer jiggles. For a fraction of a second, a new pointer is drawn in the position where the mouse is moved, after which it's moved back to it's oldPosition.
void MainWindow::mouseMoveEvent(QMouseEvent *)
{
// [event->accept();] Setting this does not help
// [setCursor(Qt::BlankCursor);] Setting this does not help
QCursor::setPos(oldPosition);
// [setCursor(Qt::ArrowCursor);]
}
P.S. May be there are other ways to adjust mouse sensitivity in qt embedded. Am I doing it right?
Short answer: No.
Unfortunately, there is no way to adjust mouse sensitivity using only QT libraries.
The twitching you are experiencing is because the OS does the work of drawing the mouse pointer, the frequency of which can be different from how frequently you receive mouse move events from the OS.
There is also no way to tell QT or the OS to send you mouse move events before every frame the cursor is drawn.
Workaround: You could hide the mouse pointer completely, and draw your own. This way you will have full control over when the cursor is drawn avoiding the glitches.
I am developing a brush just like the brush in mspaint, but I cannot get all the pixels from
WM_MOUSEMOVE when the mouse move over the pixels.only can get a set of desultory points.
You can use GetMouseMovePointsEx to get a history of the last 64 mouse points, which may include points that were never delivered to your app via WM_MOUSEMOVE.
But you can often improve the performance in this sort of application by ignoring the actual mouse position that WM_MOUSEMOVE sends you and instead query the pointer position directly with GetCursorPos.
Either way, you'll never get enough resolution from the mouse to draw a smooth joined-up line - the best you can do is draw straight lines (or even interpolate splines) between the coordinates.
Is there a way to get initial position of mouse in SDL 2.0 ? I try to get mouse coordinates by SDL_GetMouseState(&mouse_x,&mouse_y), however I get the result I expected only after using the function SDL_PollEvent() and also I can't see a value other than (0,0) if the mouse has not been moved at least once since begining of the program.Although I don't check SDL_MOUSEMOTION and connect SDL_GetMouseState() to it, I get mouse coordinates only when mouse is moved.So what's wrong? Or is SDL_GetMouseState() suitable to do so?
Edit : Why, Why is there no any answer?
Try calling SDL_PumpEvents() before SDL_GetMouseState().
The SDL updates the position of the mouse internally in SDL_PrivateSendMouseMotion, which is called by various mouse related functions in the same file.
These functions are called in the event loop processing function WIN_WindowProc in response to the mouse events dispatched by Windows.
Thus, if you do not move the mouse, no event is dispatched and the SDL does not know where the mouse is. The solution is to wait for a mouse event before requesting the position and to find a workaround until this event.
I know it's late, but just chipping in with a resolution I found.
If you get zero coordinates, call SDL_GetGlobalMouseState(&x, &y) then offset x and y by the window.x and window.y coordinates.
I have a problem when I try to update my camera.
I want to change the pitch and yaw of the the camera (where its looking) via the mouse
But I want the mouse to stay positioned to the center of the window.
//where MouseP.x .y is the mouse position
//(which is centered to the current window)
//get old position of the mouse
OldP.x = MouseP.x;
OldP.y = MouseP.y;
//work out the distance traveled
Delta.x = MouseP.x - OldP.x;
Delta.y = MouseP.y - OldP.y;
//update the camera(using distance traveled)
Rot.Yaw -=Delta.x/5;
Rot.Pitch -= Delta.y/5;
//move mouse to the center of the screen
SetCursorPos(CENTER_SCREEN_X,CENTER_SCREEN_Y);
the problem is the camera snaps back to a certain point as the mouse is set to return to the origin.
I want to update the camera by the distance traveled from the origin but not the distance back to the origin.
If I take it out, it works wonderfully but the then mouse can go out of the window.
One has to be careful with cursor and 3D mouse movement. People tend to think it is related, but in fact it is not.
read the article from the msdn:
http://msdn.microsoft.com/en-us/library/windows/desktop/ee418864%28v=vs.85%29.aspx
"Taking Advantage of High-Definition Mouse Movement"
this is how one must get mouse input in a 3D application.
the cursor should be hidden.
If you try to recenter it, it will create a horrible jaggy feeling where the cursor is trying to escape the center with the user moving the mouse but is kept in place by an invisible spring. Which doesn't look very profesional. You can't fight that because your application is not scheduled before mouse cursor display.
I believe the issue here is that your block of code probably is inside the catch of a WM_MOUSEMOVE event?
When you call SetCursorPos, it itself generates another WM_MOUSEMOVE event, so you process this block of code once when you move the mouse, and once again when you call SetCursorPos and it does the opposite of this.
You probably don't want to put SetCursorPos inside of a WM_MOUSEMOVE event catch, or else you'll generate an endless loop of messages (every SetCursorPos generates another one).
Perhaps you can move this code outside of the message pump, and just run it once per frame in your update loop: query the current mouse position, make your camera transform, then set the cursor back to the origin.
if(g_States::Instance().MouseLook())
{
//Test the mouse input
POINT mousePos;
GetCursorPos(&mousePos);
mouseX = mousePos.x; //g_InputEngine::Instance().GetX();
mouseY = mousePos.y; //g_InputEngine::Instance().GetY();
mouseX = mouseX - m_HalfWidth;
mouseY = mouseY - m_HalfHeight;
mouseFloat = mouseX * C_MOUSESMOOTHINGFACTOR;
g_Scene::Instance().GetCamera()->RotateYaw(-mouseFloat);
mouseFloat = mouseY * C_MOUSESMOOTHINGFACTOR;
g_Scene::Instance().GetCamera()->RotatePitch(mouseFloat);
//Reset mouse to center on the screen
SetCursorPos(m_HalfWidth,m_HalfHeight);
}
So this is the Mouselook function of a spacegame prototype I was developing for fun a while back what I did was change it to use GetCursorPos(&mousePos); instead. This will get the current position of the cursor no matter when your input code updates the mouse cursor location. The rest of the math in the function is just for the sensitivity and actually rotating the camera. Hopefully this code helps a little getting yours working.
Let me know if you need more explanation.
Edit: I just remembered the reason i did this. It was because the screen was flickering it would move but then the input engine would get updated by the SetCursorPos() call because i was using WM_MOUSEMOVE to update the input engine. I'm not sure how your getting your input but this should still help you.
I'm currently writing a c++ console application that grabs the mouse position at regular intervals and sends it to another visual application where it is used to drive some 3d graphics in real time. The visual app is closed source and cannot be altered outside it's limited plug-in functionality.
Currently I'm using the GetCursorPos() function which is easy and fast enough, but I'm running into the issue that all of the data is clipped based on the current screen resolution of 1920x1600 so that all x values are between 0 and 1920 and all y values are between 0 and 1600 no matter how far the mouse is physically moved.
I need to get the mouse position before it's clipped at the edge of the screen, or possibly the deltas which I could use to calculate the current position.
I've seen some references to the windows MouseMove event but I would really not want to implement a window to make it work or especially have it as the active to receive those events.
I'm working in a windows environment and a language change is not feasible.
I might be wrong, but in Win32 land you don't get mouse move messages when the mouse is at the edge of the screen because, well, the mouse isn't moving. The usual way to get an infinite mouse area is to do the following:
Hide the mouse, get exclusive access and record position
Centre mouse to window
When mouse moves, get delta from centre of screen to current position
Centre mouse to window again
The next mouse move should have a delta of (0,0), so ignore it
Go to 3 until end of mouse move operation
Reset position, show the mouse and release exclusive access
If you didn't hide the mouse, then you'd see the mouse moving a small distance and then snapping back to the centre position, which looks nasty.
This method does require a message pump for the mouse move messages so the console application idea probably won't work with this. Can you create a full screen invisible window for grabbing the mouse?
Just get the position, and move it to the center and return the delta yourself
This is how FPS games do it
I don't have any direct experience with raw input, which is probably what you need to tap into. According to MSDN, you have to register the device, then setup your winproc to accept the WM_INPUT messages and then do your calculations based on the raw data.
Here's another relevant link.