|
b6afbe63
|
2020-04-07T09:38:57
|
|
Added SDL_log.h to SDL_internal.h so logging is available everywhere
|
|
488b94cb
|
2020-04-07T09:18:19
|
|
Don't interpret raw input messages with no mouse position
This happens occasionally on touch devices when raw input is enabled
|
|
0721931f
|
2020-04-06T19:21:56
|
|
Avoid sending regular mouse messages for touch input
|
|
4dea340c
|
2020-03-16T12:23:38
|
|
Fixed bug 4477 - Support more than 4 XInput-capable devices on Windows
Jimb Esser
Add new RawInput controller API, and improved correlation with XInput/WGI
Reorder joystick init so drivers can ask the others if they handle a device reliably
Do not poll disconnected XInput devices (major perf issue)
Fix various cases where incorrect correlation could happen
Simple mechanism for propagating unhandled Guide button presses even before guaranteed correlation
Correlate by axis motion as well as button presses
Fix failing to zero other trigger
Fix SDL_HINT_JOYSTICK_HIDAPI not working if set before calling SDL_Init()
Add missing device to device names
Disable RawInput if we have a mismatch of XInput-capable but not RawInput-capable devices
Updated to SDL 2.0.13 code with the following notes:
New HID driver: xbox360w - no idea what that is, hopefully urelated
SDL_hidapijoystick.c had been refactored to couple data handling logic with device opening logic and device lists caused some problems, yields slightly uglier integration than previously when the 360 HID device driver was just handling the data.
SDL_hidapijoystick.c now often pulls the device off of the joystick_hwdata structure for some rumble logic, but it appears that code path is never reached, so probably not a problem.
Looks like joystick_hwdata was refactored to not include a mutex in other drivers, maintainers may want to do the same refactor here if that's useful for some reason.
Something changed in how devices get names, so getting generic names.
Had to fix a (new?) bug where removing an XInput controller caused existing controllers (that moved to a new XInput index) to get identified as 0x045e/0x02fd ("it's probably Bluetooth" in code), rendering the existing HIDAPI_IsDevicePresent and new RAWINPUT_IsDevicePresent unreliable.
|
|
e261bd42
|
2020-02-12T12:26:27
|
|
Improved fix for bug 4748 - Calling WIN_UpdateClipCursor() / WIN_UpdateClipCursorForWindows() on WIN_PumpEvents() causes beeping and choppy mouse cursor movement, right-click doesn't work
|
|
6fe6946a
|
2020-02-11T21:19:05
|
|
Fixed relative mode mouse events stopping if you click on the title bar
|
|
c31727c7
|
2020-02-11T10:08:22
|
|
Fixed bug 4748 - Calling WIN_UpdateClipCursor() / WIN_UpdateClipCursorForWindows() on WIN_PumpEvents() causes beeping and choppy mouse cursor movement, right-click doesn't work
The problem here was calling ClipCursor() continuously in a tight loop. Fixed by only calling ClipCursor() if the clip area needs to be updated.
|
|
668276fe
|
2020-02-11T09:41:55
|
|
Don't add a frame to borderless windows.
It was done to allow hotkey resizing of borderless windows, but Windows will sometimes draw it, regardless of our WM_* message handling. See bug 4466 for more details.
|
|
f867cebb
|
2020-02-11T08:36:13
|
|
Fixed bug 4709 - incorrect (not) handling of windows on-screen cursor keys
Alex Denisov
When using Win10 on-screen keyboard (tooltip.exe), the left and right cursor keys in it do not produce SDLK_LEFT and SDLK_RIGHT events.
Windows messages generated by the on-screen keyboard, for some reason, have their scancodes set to zeroes. Here is the log from Spy++:
WM_KEYDOWN nVirtKey:VK_LEFT cRepeat:1 ScanCode:00 fExtended:0 fAltDown:0 fRepeat:0 fUp:0
WM_KEYUP nVirtKey:VK_LEFT cRepeat:1 ScanCode:00 fExtended:0 fAltDown:0 fRepeat:1 fUp:1
Regular physical keyboard produces VK_LEFT (ScanCode:4B) and VK_RIGHT (ScanCode:4D) which are interpreted correctly.
With on-screen keyboard, the switch statement in VKeytoScancode() does not check for VK_LEFT and VK_RIGHT, returning SDL_SCANCODE_UNKNOWN, which in turn does not get mapped to anything (because the scan codes are zeroes).
|
|
a8780c6a
|
2020-01-16T20:49:25
|
|
Updated copyright date for 2020
|
|
c9d0e2ae
|
2019-10-23T09:26:27
|
|
Fixed bug 4840 - Read of uninitialized memory in DXGI_LoadDLL (Thanks!)
|
|
d5d34de4
|
2019-10-23T09:17:53
|
|
Fixed bug 4839 - Read of uninitialized memory in Win32_ResizeWindowShape
(Thanks!)
|
|
758badff
|
2019-10-23T08:58:52
|
|
Fixed bug 4841 - Misplaced parenthesis WIN_WindowProc / WM_ACTIVATE / ClipCursor
(Thanks!)
|
|
8a394209
|
2019-09-05T20:47:20
|
|
SDL_windowsevents.c: remove isVistaOrNewer (not used since 8cb1dc50bb28)
|
|
bf2f4703
|
2019-09-05T10:49:53
|
|
SDL_windowsmessagebox.c: remove unused variable
|
|
cc64b369
|
2019-08-30T15:32:15
|
|
Allow mouse messages from Wacom pens, e.g. right click pen buttons, etc.
|
|
afb9ff95
|
2019-08-30T08:03:19
|
|
Fixed bug where the Steam overlay would generate an event and stop input processing for the frame.
|
|
13c4d5e7
|
2019-08-26T17:43:01
|
|
Fixed Windows relative mouse coordinates when capturing the mouse over RDP
|
|
63197c43
|
2019-08-02T17:19:50
|
|
Fix bug where the wrong button was the default in the old message box because buttons were added backwards, breaking the indexing used by GetButtonIndex.
Add messagebox flags to explicilty request left-to-right button order or right-to-left. If neither is specified it'll be some platform default.
|
|
d5ec735a
|
2019-08-01T18:22:12
|
|
Add a windowID field to SDL_TouchFingerEvent (bug #4331).
This is unimplemented on some platforms and will cause compile errors when building those platform backends for now.
|
|
c37c6cbb
|
2019-07-31T23:37:02
|
|
use WIN_IsWindowsVistaOrGreater() from core/windows for isVistaOrNewer
|
|
4953e050
|
2019-07-31T05:11:40
|
|
use SDL_zeroa at more places where the argument is an array.
|
|
e7c2cf10
|
2019-07-15T09:36:53
|
|
Fixed bug 4704 - SDL_HINT_ANDROID_SEPERATE_MOUSE_AND_TOUCH on Windows?
superfury
I notice that, somehow, when locking the mouse into place(using SDL_SetRelativeMouseMode), somehow at least the movement information gets through to both mouse movement and touch movement events?
My app handles both, so when moving a touched finger accross the app(using RDP from an Android device) I see the mouse moving inside the app when it shouldn't(meaning that the touch movement is ignored properly by the app(press-location dependant) but the mouse movement is still performed due to the mouse movement events)?
|
|
7e09718d
|
2019-07-07T11:23:16
|
|
Ignore synthetic mouse events generated for touchscreens
Windows generates fake raw mouse events for touchscreens for compatibility
with legacy apps that predate touch support in Windows. We already handle
touch events explicitly, so drop the synthetic events to avoid duplicates.
|
|
0beadea5
|
2019-06-26T01:29:01
|
|
windows: Call GetWindowText() with the correct parameters (thanks, Zebediah!)
GetWindowText() wants you to tell it the size of the buffer--including the
terminating NULL char--but we weren't counting that last char, losing the
last char of the string in the process. This was only seen with the special
case of SDL_CreateWindowFrom() to use an existing native window, not
the usual SDL_CreateWindow() codepath.
Fixes Bugzilla #4696.
|
|
399df540
|
2019-06-11T01:14:24
|
|
windows: Drop WM_ACTIVATE when window is hidden, but only if being activated.
Fixes Bugzilla #4571.
|
|
f2c8d8e9
|
2019-06-08T10:47:43
|
|
Fixed bug 4443 - Incorrect scan code reported for numpad 5
bplu4t2f
When num lock is on, the scancode reported for numpad 5 is SDL_SCANCODE_KP_5, which is correct. However, when num lock is off, windows reports the VK_CLEAR virtual key code, which is incorrectly translated into SDL_SCANCODE_CLEAR inside of the VKeytoScancode(WPARAM vkey) function.
|
|
b45abbb2
|
2019-04-02T17:57:27
|
|
Bug 4576: fix warning and compile
|
|
1a4c3b57
|
2019-04-02T16:58:11
|
|
Bug 4576: remove touch/mouse duplication for Windows
|
|
5e13087b
|
2019-01-04T22:01:14
|
|
Updated copyright for 2019
|
|
5029d50e
|
2018-11-10T16:15:48
|
|
Add SDL_TouchDeviceType enum and SDL_GetTouchDeviceType(SDL_TouchID id).
Touch device types include SDL_TOUCH_DEVICE_DIRECT (a touch screen with window-relative coordinates for touches), SDL_TOUCH_DEVICE_INDIRECT_ABSOLUTE (a trackpad-style device with absolute device coordinates), and SDL_TOUCH_DEVICE_INDIRECT_RELATIVE (a trackpad-style device with screen cursor-relative coordinates).
Phone screens are an example of a direct device type. Mac trackpads are the indirect-absolute touch device type. The Apple TV remote is an indirect-relative touch device type.
|
|
4659e738
|
2018-11-01T12:31:45
|
|
merge fallout: Patched to compile, fixed some compiler warnings, etc.
|
|
62494a2e
|
2018-10-31T15:03:41
|
|
Merge SDL-ryan-batching-renderer branch to default.
|
|
b262b0eb
|
2018-10-22T20:50:32
|
|
Small stack allocations fall back to malloc if they're unexpectedly large.
|
|
eff5f650
|
2018-10-09T23:01:43
|
|
Implement SuspendScreenSaver for Win32
Creating a full-screen SDL renderer on Windows will keep the screensaver
suspended by DirectX, as is default for full-screen DX applications. However,
for applications that render in windowed-mode, the screensaver will
still kick in, even if SDL_DisableScreenSaver() is called or
SDL_HINT_VIDEO_ALLOW_SCREENSAVER is set to 0 (default). Implementing
a SuspendScreenSaver() function for Win32 fixes this behavior.
|
|
55b24b93
|
2018-09-26T11:17:43
|
|
Fixed bug 4265 - SDL window falls to the bottom of the screen when dragged down and stuck there
Alexei
On WM_WINDOWPOSCHANGED event, WIN_UpdateClipCursor() is called. SDL_WINDOW_INPUT_FOCUS is set even when the mouse pointer is not inside the SDL window and therefore ClipCursor(&rect) is called. When dragging the window and rect.bottom=800 (i.e. the bottom edge of the screen) the SDL window is clipped to the bottom of the screen and it is not possible to move it back to the center of the screen.
|
|
5febdfce
|
2018-09-24T11:49:25
|
|
Fixed whitespace
|
|
6b3e8931
|
2018-09-14T19:26:26
|
|
Added hints SDL_HINT_MOUSE_DOUBLE_CLICK_TIME and SDL_HINT_MOUSE_DOUBLE_CLICK_RADIUS to allow tuning double-click sensitivity.
Also increased the default double-click radius to 32 pixels to be more forgiving for touch interfaces
|
|
a1ca8441
|
2018-08-26T20:37:23
|
|
Update the cursor clipping each frame, in case it was stolen by another application.
|
|
15b3794f
|
2018-08-26T10:34:23
|
|
Only reset the clip rect if it's currently the rect we previously clipped.
This prevents us from clearing the clip rect globally when another application has set it.
There's also an experimental change to regularly update the clip rect for a window defensively, in case someone else has reset it. It works well, but I don't know if it's cheap enough to call as frequently as it would be called now, and might have other undesirable side effects.
Also fixed whitespace and SDL coding style
|
|
e061a92d
|
2018-08-02T16:03:47
|
|
Some drag'and'drop improvements.
First: disable d'n'd events by default; most apps don't need these at all, and
if an app doesn't explicitly handle these, each drop on the window will cause
a memory leak if the events are enabled. This follows the guidelines we have
for SDL_TEXTINPUT events already.
Second: when events are enabled or disabled, signal the video layer, as it
might be able to inform the OS, causing UI changes or optimizations (for
example, dropping a file icon on a Cocoa app that isn't accepting drops will
cause macOS to show a rejection animation instead of the drop operation just
vanishing into the ether, X11 might show a different cursor when dragging
onto an accepting window, etc).
Third: fill in the drop event details in the test library and enable the
events in testwm.c for making sure this all works as expected.
|
|
862aa4b4
|
2018-07-22T19:28:27
|
|
windows: Fixed some Visual Studio warnings about shadowed variables.
Fixes Bugzilla #4118.
|
|
013b146d
|
2018-06-30T20:55:51
|
|
SDL_windowstaskdialog.h (struct _TASKDIALOGCONFIG): make unions anonymous
otherwise build fails. (at least with my VS2005. and the code accesses the
arms of the unions anonymously anyway.)
|
|
7c2028f8
|
2018-06-29T16:56:11
|
|
Attempt to fix "cast from pointer to integer of different size" warnings.
|
|
9d6ac3de
|
2018-06-05T12:46:09
|
|
Fix creating a minimized window in SDL to not cause focus to be stolen (because ShowWindow( hwnd, SW_MINIMIZE ) would be called after creation, thus changing focus to the prior window based on some per-app list in windows, rather than the window being created with WS_MINIMIZED to start with).
This means we have to consider SDL_WINDOW_MINIMIZED a window creation flag, but on non-windows platforms we just remove it and let the normal FinishWindowCreation re-apply and do the minimize as I have no idea what is right on them or if anything should change.
CR: Phil
|
|
a4d0571e
|
2018-05-07T20:10:12
|
|
Reverted change for bug 4152 - restrict the win10 mouse bug workaround to win10 v1709 only
Daniel Gibson
Sorry, but it seems like Microsoft didn't fix the issue properly.
I just updated my Win10 machine, it now is Version 1803, Build 17134.1
I tested with SDL2 2.0.7 (my workaround was released with 2.0.8) and still got
lots of events that directly undid the prior "real" events - just like before.
(See simple testcase in attachement)
By default it sets SDL_HINT_MOUSE_RELATIVE_MODE_WARP - which triggered (and on my machine still triggers) the buggy behavior. You can start it with -raw, then it'll not set that hint and the events will be as expected.
The easiest way to see the difference is looking at the window title, which shows accumulated X and Y values: If you just move your mouse to the right, in -raw mode the number just increases. In non-raw mode (using mouse warping) it stays around 0.
I also had a WinAPI-only testcase: https://gist.github.com/DanielGibson/b5b033c67b9137f0280af9fc53352c68
It just calls SetCursorPos(320,240); on each WM_MOUSEMOVE event, and it also
logs all those events to a mouseevents.log textfile.
This log indeed looks a bit different since the latest Win10 update: It seems like all those events with x=320 y=240 do arrive - but only after I stopped moving the mouse - even though the cursor seems to be moved back every frame (or so).
So moving the mouse to the right gives X coordinates like
330, 325, 333, 340, 330, ...
and then when stopping movement I get lots of events with X coordinate 320
|
|
606c5a58
|
2018-05-05T10:27:53
|
|
Fixed bug 4152 - Windows 10 v1803 update seems to have fixed the jumping mouse bug (see bug #3931.)
|
|
6a0ef0cd
|
2018-04-09T10:37:31
|
|
SDL:
On Windows, have SDL_ShowWindow() not activate the window if the window has the WS_EX_NOACTIVATE window flag.
|
|
4d78a995
|
2018-03-26T12:38:29
|
|
Fixed bug where an SDL window that was activated while hidden could never be shown.
Test code:
{
SDL_Window *win = SDL_CreateWindow( "Dummy", SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED, 128, 128, SDL_WINDOW_HIDDEN );
SDL_SysWMinfo info;
SDL_VERSION( &info.version );
SDL_GetWindowWMInfo( win, &info );
SetActiveWindow( info.info.win.window );
{
DWORD then = SDL_GetTicks();
while ( ( SDL_GetTicks() - then ) < 3000 )
{
SDL_Event evt;
SDL_PollEvent( &evt );
}
SDL_ShowWindow( win );
then = SDL_GetTicks();
while ( ( SDL_GetTicks() - then ) < 3000 )
{
SDL_Event evt;
SDL_PollEvent( &evt );
}
}
SDL_DestroyWindow( win );
}
|
|
e14278ef
|
2018-03-24T10:26:40
|
|
Fixed bug 3804 - Message box on Windows truncates button ID
Simon Hug
I just wanted to fix a simple compiler warning in SDL_ShowMessageBox on Windows (which Sam fixed recently) and ended up finding some issues.
Attached patch fixes these issues:
- Because Windows only reports the lower 16 bits of the control identifier that was pushed, the button IDs used by SDL (C type int, most likely 32 bits) can get cut off.
- The documentation states (somewhat ambiguously) that the button ID will be -1 if the dialog was closed, but the current code sets 0. For SDL 2.1, I think this should be a return code of SDL_ShowMessageBox itself. That will free up the button ID and it seems a more appropriate place for signaling this event.
- Ampersands in controls will create mnemonics on Windows (underlined letters that, if combined with the Alt key, will push the button). I was thinking of adding a hint or flag to let the users enable it, but that might have unexpected results.
- When the size of the text gets calculated, it doesn't use the same parameters as the static control. This can cut off text or wrap it weirdly.
- On Windows, the Tab key is used to switch between control groups and sometimes between buttons in dialogs. This didn't seem to work correctly.
Attached patch also adds:
- Icons. Just the system ones that can be loaded with the ordinals IDI_ERROR, IDI_WARNING and IDI_INFORMATION.
- A button limit of 2^16 - 101.
- Some more specific error messages, but they never reach the user because how SDL_ShowMessageBox handles them if an implementation returns with an error.
|
|
2419d267
|
2018-03-02T22:53:25
|
|
Progress fixing bug 4100 - errors and warnings after changeset 11917
Ozkan Sezer 2018-03-02 20:02:37 UTC
http://hg.libsdl.org/SDL/rev/d702b0c54e52 resulted in an error and
two warnings when compiled with mingw.
1. Error from SDL_windowstaskdialog.h:
In file included from src/video/windows/SDL_windowsmessagebox.c:29:0:
src/video/windows/SDL_windowstaskdialog.h:23:54: error: expected ')' before 'HWND'
This is fixed by removing unnecessary annotations:
2. Warning from SDL_assert.c:
src/SDL_assert.c: In function 'SDL_ExitProcess':
src/SDL_assert.c:138:1: warning: 'noreturn' function does return
Indeed ExitProcess() is prototyped with DECLSPEC_NORETURN, but
TerminateProcess() is not. This can be rectified by adding an
exit() call in there. Do NOTE, however, that requires building
with a libc:
3. Warning from SDL_windowsmessagebox.c:
src/video/windows/SDL_windowsmessagebox.c: In function 'WIN_ShowMessageBox':
src/video/windows/SDL_windowsmessagebox.c:513:9: warning: 'nCancelButton' may be used uninitialized in this function
My lazy solution was manually initializing nCancelButton to 0.
|
|
cef1c1c2
|
2018-03-02T14:10:25
|
|
windows: Restore patches for Task Dialogs and TerminateProcess().
2.0.8 has shipped, these can live in revision control now!
|
|
3537c3e7
|
2018-02-28T10:39:41
|
|
Back out Task Dialog and TerminateProcess patches for 2.0.8.
These can return to revision control once we ship.
|
|
6a1cfcce
|
2018-02-28T02:14:15
|
|
windows: dos2unix'd messagebox code, and (hopefully) fixed on MingW.
|
|
a749035f
|
2018-02-28T01:54:22
|
|
windows: Message boxes use Task Dialogs if possible (thanks, Jack!).
This lets the message box have an icon. Unless the app has opted-in to using
the v6 common controls, though, this will fall back to the usual SDL message
boxes.
|
|
5abd7d16
|
2018-02-13T22:58:20
|
|
Don't attempt WM_NCCALCSIZE adjustment when in fullscreen window transition
|
|
40b27fd5
|
2018-02-12T17:00:00
|
|
revert the recent typecast assignment changes (see bug #4079)
also change the void* typedefs for the two vulkan function
pointers added in vulkan_internal.h into generic function
pointer typedefs.
|
|
873141ac
|
2018-02-11T15:29:36
|
|
ISO C correct fix for casting void* to function pointer
|
|
882215e1
|
2018-02-11T18:16:01
|
|
vulkan: Fix assignment of vkGetInstanceProcAddr on Windows.
"*(void**)pfn = LoadAddress()" would cast the NULL pointer in pfn to a
void**, and then dereference it, which wasn't what we wanted. Replaced with
a clearer cast operation.
|
|
7b50aee9
|
2018-02-08T18:07:14
|
|
Fixed min/max window size handling for borderless resizable windows
|
|
90e72bf4
|
2018-01-30T18:08:34
|
|
Fixed ISO C99 compatibility
SDL now builds with gcc 7.2 with the following command line options:
-Wall -pedantic-errors -Wno-deprecated-declarations -Wno-overlength-strings --std=c99
|
|
2d7420f2
|
2018-01-25T11:12:20
|
|
Fixed bug 3985 - SDL_CreateWindow() has stopped changing screen mode when SDL_WINDOW_FULLSCREEN is used
Anthony
This worked in 2.0.5 as normal, but stopped working in 2.0.7. The monitor's resolution doesn't change, a window is created in full screen mode at the virtual desktop resolution instead.
|
|
0cba6847
|
2018-01-15T10:29:53
|
|
Fixed bug 4043 - SDL_windowswindow.c incorrect icon height
Needed to allocate space for the mask in the ICONIMAGE structure
|
|
a0c4eb2a
|
2018-01-10T18:00:51
|
|
Restored borderless window behavior where DOTA created a borderless window the size of the desktop and expected it to behave like a fullscreen desktop window.
A future SDL release will change the borderless window to act more like a normal window that happens to have no chrome, to support windows that draw their own chrome. In the meantime, those applications should set the "SDL_BORDERLESS_WINDOWED_STYLE" hint.
|
|
7c60bec4
|
2018-01-03T10:58:58
|
|
Fixed bug 4018 - Implement SDL_GetWindowBordersSize() under Windows/Win32/WinAPI
Ismael Ferreras Morezuelas (Swyter)
As a new year gift I have implemented the Windows version of SDL_GetWindowBordersSize(). I needed it for auto-selecting a cozy window size for the game I'm currently working on and noticed that it only worked under X11, so I thought it could be a good excuse to contribute back more stuff. The Mercurial patch is attached as a .diff file. Let me know what you think.
Happy 2018 to all the SDL2 devs and users!
--
PS: Keep in mind that Windows 10 includes the 8px invisible grip borders as part of the frame. There's a way of detecting if Aero/DWM is being used and ask only for the visible rect, but I believe that GetWindowRect() is doing that for a reason and working as intended, so I haven't changed it. (See [2])
References:
[1]: http://www.firststeps.ru/mfc/winapi/r.php?72
[2]: https://stackoverflow.com/a/34143777/674685
[3]: https://stackoverflow.com/a/431548/674685
[4]: https://wiki.libsdl.org/SDL_GetWindowBordersSize
|
|
e3cc5b2c
|
2018-01-03T10:03:25
|
|
Updated copyright for 2018
|
|
7c667a6f
|
2018-01-01T19:16:51
|
|
windows: Remove references to GetVersionExA (thanks, Andrew Pilley!).
"GetVersionExA is deprecated in windows 8.1 and above's SDK, causing a warning
when building against the win10 SDK. Attached patch cleans up the usage for a
warning-free build.
GetVersionExA was being used to test to see if SDL was running on win9x or
winnt. A quick chat with Ryan on twitter suggested that SDL doesn't
officially support win9x anymore, so the call to this can be outright removed.
As an aside, replacing the call to GetVersionExA with VerifyVersionInfoA (the
recommended path) would have been pointless, as VerifyVersionInfoA only
supports VER_PLATFORM_WIN32_NT and doesn't officially support any other value
for dwPlatformId currently. (And it's probable that win9x SDKs didn't have
VerifyVersionInfo* in them anyway.)"
Fixes Bugzilla #4019.
|
|
1b16618b
|
2017-12-11T11:47:52
|
|
Fixed Windows gcc build
|
|
ab06f570
|
2017-12-10T09:17:33
|
|
Workaround for bug 3931 - spurious SDL_MOUSEMOTION events with SDL_HINT_MOUSE_RELATIVE_MODE_WARP 1 since Windows 10 Fall Creators update
Elis?e Maurer
The attached minimal program sets the SDL_HINT_MOUSE_RELATIVE_MODE_WARP to 1, enables relative mouse mode then logs all SDL_MOUSEMOTION xrel values as they happen.
When moving the mouse exclusively to the right:
* On a Windows 10 installation before Fall Creators update (for instance, Version 10.0.15063 Build 15063), only positive values are reported, as expected
* On a Windows 10 installation after Fall Creators update (for instance, Version 10.0.16299 Update 16299), a mix of positive and negative values are reported.
3 different people have reproduced this bug and have confirmed it started to happen after the Fall Creators update was installed. It happens with SDL 2.0.7 as well as latest default branch as of today.
It seems like some obscure (maybe unintended) Windows behavior change? Haven't been able to pin it down more yet.
(To force-upgrade a Windows installation to the Fall Creators update, you can use the update assistant at https://www.microsoft.com/en-us/software-download/windows10)
Eric Wasylishen
Broken GetCursorPos / SetCursorPos based games on Win 10 fall creators are not limited to SDL.. I just tested winquake.exe (original 1997 exe) and it now has "jumps" in the mouse input if you try to look around in a circle. It uses GetCursorPos/SetCursorPos by default. Switching WinQuake to use directinput (-dinput flag) seems to get rid of the jumps.
Daniel Gibson
A friend tested on Win10 1607 (which is before the Fall Creators Update) and the the bug doesn't occur there, so the regression that SetCursorPos() doesn't reliably generate mouse events was indeed introduced with that update.
I even reproduced it in a minimal WinAPI-only application (https://gist.github.com/DanielGibson/b5b033c67b9137f0280af9fc53352c68), the weird thing is that if you don't do anything each "frame" (i.e. the mainloop only polls the events and does nothing else), there are a lot of mouse events with the coordinates you passed to SetCursorPos(), but when sleeping for 10ms in each iteration of the mainloop, those events basically don't happen anymore. Which is bad, because in games the each iteration of the mainloop usually takes 16ms..
I have a patch now that I find acceptable.
It checks for the windows version with RtlGetVersion() (https://msdn.microsoft.com/en-us/library/windows/hardware/ff561910.aspx) and only if it's >= Win10 build 16299, enables the workaround.
All code is in video/windows/SDL_windowsevents.c
and the workaround is, that for each WM_MOUSEMOVE event, "if(isWin10FCUorNewer && mouseID != SDL_TOUCH_MOUSEID && mouse->relative_mode_warp)", an addition mouse move event is generated with the coordinates of the center of the screen
(SDL_SendMouseMotion(data->window, mouseID, 0, center_x, center_y);) - which is exactly what would happen if windows generated those reliably itself.
This will cause SDL_PrivateSendMouseMotion() to set mouse->last_x = center_x; and mouse->last_y = center_y; so the next mouse relative mouse event will be calculated correctly.
If Microsoft ever fixes this bug, the IsWin10FCUorNewer() function would have to
be adjusted to also check for a maximum version, so the workaround is then disabled again.
|
|
25df5a5a
|
2017-11-28T18:31:18
|
|
Non-resizable windows need to have their window rect set to the client rect
|
|
1bfe6d60
|
2017-10-06T21:43:59
|
|
Fixed restoring window size when coming out of fullscreen desktop mode.
Use the style of the window as it will be, not as it currently is at the
time of the AdjustWindowRect call.
|
|
54685787
|
2017-09-26T15:07:35
|
|
Fixed bug 3847 - Hit Test x coordinate wrong on secondary monitor
Robert Turner
SDL_windowsevents.c contains code to retrieve the x and y coordinate for a requested hit test. It does this as follows:
POINT winpoint = { (int) LOWORD(lParam), (int) HIWORD(lParam) };
LOWORD(lParam) does not correctly mask off high bits that are set if the point is on a second (or third, etc.) monitor. This effectively offsets the x-coordinate by a large value.
MSDN documentation suggests that LOWORD() and HIWORD() are the wrong macros for the task, instead suggesting we should be doing something like the following:
POINT winpoint = { GET_X_LPARAM(lParam), GET_Y_LPARAM(lParam) };
Testing this change on my Windows 10 machine with 2 monitors gives the correct results.
|
|
58d1c54d
|
2017-09-22T17:32:05
|
|
Fixed spacing
|
|
499f928c
|
2017-09-22T07:15:41
|
|
borderless windows will have WM_NCCALCSIZE return 0 for the non-client area. When this happens, it looks like windows will send a resize message expanding the window client area to the previous window + chrome size, so shouldn't need to adjust the window size for the set styles.
|
|
3176a7f5
|
2017-09-22T07:11:36
|
|
sdl
- Fixing rendering borderless window. Need to force windows to send a WM_NCCALCSIZE then return 0 for non-client area size.
- Adding WS_CAPTION | WS_SYSMENU | WS_MINIMIZEBOX to borderless windows, for reasons noted in comments.
- Fix SetupWindowData() setting SDL_WINDOW_BORDERLESS. This was being cleared at window creation, causing hanlding for the first WM_NCCALCSIZE message to fail
|
|
fcd9c190
|
2017-09-09T09:31:12
|
|
Fixed window size when leaving fullscreen mode (thanks Eric!)
|
|
e8059221
|
2017-09-08T18:26:25
|
|
Fixed bug 3806 - Fixes for MSVC compiler warnings
Simon Hug
These are the remaining compiler warnings I see in the current tip cb049cae7c3c.
- SDL_test_log.c defines _CRT_SECURE_NO_WARNINGS without checking if it was already set.
- SDL_windowskeyboard.c converts integers to pointers without going over the (U)INT_PTR types. That bothers MSVC.
|
|
fa0eeff7
|
2017-09-06T07:29:34
|
|
sdl:
Cleans up AdjustWindowEx calls
|
|
20c5bc91
|
2017-09-06T05:23:26
|
|
You can have a borderless resizable window
|
|
130138fa
|
2017-08-28T22:44:48
|
|
Fixed bug 3785 - fix windows build after revision 11382
Ozkan Sezer
fix windows build after revision 11382: commit 2026e42e377a renamed
_SDL_msctf_h to SDL_msctf_h_ . SDL_windowskeyboard.c relies on that
macro, so update it accordingly.
|
|
50efbda7
|
2017-08-28T00:43:14
|
|
Fixed mingw Windows build, since SDL_vulkan_internal.h includes windows.h
|
|
0d011ec6
|
2017-08-28T00:22:23
|
|
Renaming of guard header names to quiet -Wreserved-id-macro
|
|
ce2b1644
|
2017-08-28T00:11:38
|
|
Be clear that disabling Vulkan surface support disables the entire SDL Vulkan integration
|
|
9da4717d
|
2017-08-27T22:36:03
|
|
Fixed Windows warning
|
|
25e3a1ec
|
2017-08-27T22:15:57
|
|
vulkan: Initial Vulkan support!
This work was done by Jacob Lifshay and Mark Callow; I'm just merging it
into revision control.
|
|
73f866cf
|
2017-08-25T15:16:39
|
|
windows: Attempt to make Visual Studio not hardcode a call to memset().
|
|
685890a2
|
2017-08-24T22:57:42
|
|
Fix KHR_no_error support
|
|
d8fc70ea
|
2017-08-24T21:30:53
|
|
opengl: add support for GL_KHR_no_error.
This is completely untested!
Fixes Bugzilla #3721.
|
|
01e0d8fc
|
2017-08-19T15:02:03
|
|
opengl: Add support for [GLX|WGL]_ARB_create_context_robustness.
This patch was originally written by Marc Di Luzio for glX and enhanced by
Maximilian Malek for WGL, etc. Thanks to both of you!
Fixes Bugzilla #3643.
Fixes Bugzilla #3735.
|
|
e83764a5
|
2017-08-14T23:45:06
|
|
Fixed bug 2137 - SDL Message Boxes don't cope with fixed width fonts (in windows at least)
Pegasus Epsilon
With the system dialog font set to Arial or Tahoma or another variable-width font, everything works just as expected. When using a fixed-width font, like Courier or DejaVu Sans Mono, the text gets cut off. Example screenshots attached.
|
|
a4cfa936
|
2017-08-14T21:28:04
|
|
Fixed bug 2293 - Precise scrolling events
Martijn Courteaux
I implemented precise scrolling events. I have been through all the folders in /src/video/[platform] to implement where possible. This works on OS X, but I can't speak for others. Build farm will figure that out, I guess. I think this patch should introduce precise scrolling on OS X, Wayland, Mir, Windows, Android, Nacl, Windows RT.
The way I provide precise scrolling events is by adding two float fields to the SDL_MouseWheelScrollEvent datastructure, called "preciseX" and "preciseY". The old integer fields "x" and "y" are still present. The idea is that every platform specific code normalises the scroll amounts and forwards them to the SDL_SendMouseWheel function. It is this function that will now accumulate these (using a static variable, as I have seen how it was implemented in the Windows specific code) and once we hit a unit size, set the traditional integer "x" and "y" fields.
I believe this is pretty solid way of doing it, although I'm not the expert here.
There is also a fix in the patch for a typo recently introduced, that might need to be taken away by the time anybody merges this in. There is also a file in Nacl which I have stripped a horrible amount of trailing whitespaces. (Leave that part out if you want).
|
|
de91b124
|
2017-08-14T06:28:21
|
|
Fixed bug 3745 - specify SDLCALL as the calling convention for API callbacks
Patches contributed by Ozkan Sezer
|
|
78865eff
|
2017-08-13T20:38:06
|
|
Fixed compiler warning
|
|
c87e1d52
|
2017-08-13T14:15:52
|
|
Fixed bug 2841 - Hint to set resource id for window icon
Alexey
Seems to be a missing functionality. I want to set an icon from RC file. I cant pass MAKEINTRESOURCE(X) string to SDL_RegisterApp() cause string returned by MAKEINTRESOURCE string is not actually a string and SDL_strlen will crash. Moreover LoadImage seems to be loading wrong icon size. LoadIcon seems to be fine.
|
|
45cec28b
|
2017-08-12T16:44:00
|
|
Fixed bug 3058 - Slight mistake in GetWindowStyle in SDL_windowswindow.c
Coriiander
There's a slight mistake in the function "GetWindowStyle" found in file "SDL_windowswindow.c".
When a window is marked to be resizable, the resizable style is being added regardless of whether the window has a border or not. While for some arcane, hidden semantics this can be ok, it's still inconsistent in this case.
|
|
47c2c7d5
|
2017-08-12T12:56:28
|
|
Cleaned up WindowsScanCodeToSDLScanCode() so VKeytoScancode() always takes precedence for the keys it handles and the rest of the logic is easier to read.
|
|
b425050b
|
2017-08-12T00:04:46
|
|
Fixed compiler warnings on Visual Studio 2013
|
|
79a846d4
|
2017-08-11T19:42:39
|
|
Fixed bug 3334 - SDL_ShowMessageBox uses wrong index and accesses un-allocated memory
romain.lacroix
For the windows implementation of SDL_ShowMessageBox() : ./src/video/windows/SDL_windowsmessagebox.c:345 WIN_ShowMessageBox()
The implementation in 2.0.4 uses "button index" for parameter "id" of function AddDialogButton().
It then expects the value provided in param wParam of function MessageBoxDialogProc() to be a valid index of a button.
It uses this value to index in the array of buttons when DialogBoxIndirect() returns (line 474 : *buttonid = buttons[which].buttonid;)
However, when dismissing this box with Escape, the return value of DialogBoxIndirect will be SDL_MESSAGEBOX_BUTTON_ESCAPEKEY_DEFAULT (=2) which is not always a valid index of array buttons.
When the array buttons has a length less or equal than 2, the memory access is invalid; I can see that the value written to *buttonId is uninitialized memory (random value).
The fix I propose : use value "buttonid" (field of button) for parameter "id" of AddDialogButton(), then copy return value of DialogBoxIndirect() in *buttonid. This way, we will not use an out-of-bounds index in array buttons.
|
|
96305832
|
2017-08-11T10:21:19
|
|
Fixed bug 3702 - Clear error messages of SDL_LoadObject for optional libraries
Simon Hug
Some code in SDL loads libraries with SDL_LoadObject to get more information or use newer APIs. SDL_LoadObject may fail, set an error message and SDL will continue with some fallback code. Since SDL will overwrite the error or exit the function with a return value that indicates success, the error form SDL_LoadObject for the optional stuff might as well be cleared right away.
|
|
6e1b11ba
|
2017-08-11T10:18:45
|
|
Fixed bug 3714 - Windows: SDL_WINDOW_FULLSCREEN_DESKTOP broken on 3 monitor setup w/ DPI scaling
Eric Wasylishen 2017-07-26 18:42:58 UTC
I set up an (admittedly exotic) 3-monitor setup, and when I enter fullscreen-desktop on the middle display (#2), the SDL window is off center. (covers half of monitor #2 and most of monitor #3).
The displays are arranged from left to right:
Display #1 (main): 2880x1800, 200% scaling
Display #2: 1920x1200, 150% scaling
Display #3: 1920x1080, 100% scaling
SDL display bounds:
INFO: Bounds: 1440x900 at 0,0
INFO: Bounds: 1281x801 at 1921,0 (these are incorrect)
INFO: Bounds: 1920x1080 at 4800,0
Correct bounds reported by calling EnumDisplayMonitors and printing the LPRECT param of the callback:
1440x900 at (0, 0)
1280x800 at (2880, 0)
1920x1080 at (4800, 0)
It seems like you need 3 displays to reproduce this, and the left two need DPI scaling, and the 3rd display needs to have a different scale factor than the others.
Related: https://bugzilla.libsdl.org/show_bug.cgi?id=3709
SDL: current hg (11235:6a587b9e0ec8)
Windows 10, Version 10.0.15063 Build 15063
Tested with testdraw2 and testgl2, and pressing alt+enter to enter fullscreen desktop.
This patch reworks SDL_windowsmodes.c to use EnumDisplayMonitors instead of EnumDisplayDevices, so we always have an HMONITOR for each SDL display.
With access to an HMONITOR, we can get the monitor bounds in virtual screen coordinates the proper way, by calling GetMonitorInfo. (whereas the original code was doing some calculations - e.g. "data->DeviceMode.dmPosition.x * data->ScaleX" - to try to get virtual screen coordinates. These worked in simple cases, but failed in more complex cases like this bug)
The one potential problem with my patch is, the ChangeDisplaySettingsEx docs say that you're supposed to get the display name from EnumDisplayDevices, but I'm getting the display name from GetMonitorInfo now.
|