We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 2671 - Mouse Y gets 22 pixels offset after warping only if X is different to 0
Summary: Mouse Y gets 22 pixels offset after warping only if X is different to 0
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: events (show other bugs)
Version: HG 2.1
Hardware: x86_64 Mac OS X (All)
: P2 normal
Assignee: Jørgen Tjernø
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-05 18:53 UTC by Javi Agenjo
Modified: 2014-08-17 22:24 UTC (History)
2 users (show)

See Also:

Attachments
Simple testcase (2.27 KB, text/x-csrc)
2014-08-09 00:53 UTC, Robotic-Brain 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Javi Agenjo 2014-08-05 18:53:02 UTC 
Problem related to SDL_GetMouseState and SDL_WarpMouseInWindow

I want to create a FPS game, so after computing the delta offset from previous mouse position I warp it to the center of the window. The problem is that if I dont move the mouse, the position I read using SDL_GetMouseState is right where I put it with SDL_WarpMouseInWindow, but if I move the mouse (no matter in which axis) the Y component after SDL_GetMouseState is 22 pixels offseted (plus the obvious offset from my movement), which is the height of the title bar of the window.

If I am in fullscreen (using the OSX corner icon) the offset is only 1 pixel.

It looks like that warp is in window coordinates (0,0 is on the corner of the window) but SDL_GetMouseState is in viewport coordinates (0,0 is right below the titlebar), the weird thing is that the offset only happens if the mouse moves, otherwise there is no offset in Y.

X is perfectly fine.

Tested compiling the HG SDL 2.1 version in a OSX Mavericks.
Comment 1 Javi Agenjo 2014-08-05 19:40:13 UTC 
Also note that the same code works perfectly in windows and linux, it seems more like a bug in OSX event handling.
Comment 2 Alex Szpakowski 2014-08-05 23:16:43 UTC 
Related: https://bugzilla.libsdl.org/show_bug.cgi?id=2655
Comment 3 Robotic-Brain 2014-08-08 20:54:04 UTC 
Can you provide a testcase?
Comment 4 Javi Agenjo 2014-08-08 21:02:41 UTC 
create an SDL application with a mainloop:

int x,y;

while (1)
{
	//update events
	while(SDL_PollEvent(&sdlEvent))
	{
	}
	SDL_GetMouseState(&x,&y);
	std::cout << x << "," << y << std::endl;

	SDL_WarpMouseInWindow(window, 50,50 ); 
}


This will output 50,50 unless you move the mouse, then you will see that the Y has 22 pixels offset (plus your movement)
Comment 5 Robotic-Brain 2014-08-09 00:53:33 UTC 
Created attachment 1809 [details]
Simple testcase
Comment 6 Robotic-Brain 2014-08-09 00:54:35 UTC 
Testing showed, that the SDL_MOUSEMOTION event also returns wrong coordinates

Preliminary bisect results:

first known bad build 8738:354dabd2cb58
last known good build 8721:d73e451f1dc5

all builds in between, so far suggested by "hg bisect", are completely broken in terms of window coordinates
Comment 7 Robotic-Brain 2014-08-09 01:51:25 UTC 
definite last working version 8726:9a5a5808aa14

Bug introduced in 8729:94af945dbb57 "Mac: SDL_SetWindowPosition is now relative to the menubar."

It looks like this change only exposed a bug already pressent somewhere else..
Comment 8 Robotic-Brain 2014-08-17 22:20:05 UTC 
Fixed by https://hg.libsdl.org/SDL/rev/c5e33f9a0d03