* Normalized touch coordinates as floats in the 0...1 range
* Removed unused touchpad concepts from the API
* Added API functions to get active touch devices and current finger state
- more scancode goodness, removing now dead wparam translation code
- add scancode for SDL_SCANCODE_NONUSBACKSLASH
- don't translate sdl key values for numeric and grave key
CR: SamL
Marco Schmidt
After sizing my main window (the only window in my application) through
grabbing the window border with the mouse the window collapses instantly to a
size of 0 x 124. In my application I can not resize the window to a normal size
again.
I tried to reproduce the problem - and here a the minimal steps I found.
I'm running WIN8 x64, VS2012Pro, HG SDL-2.0 tip, WIN32-Build.
Minimal steps to reproduce my problem:
- open solution SDL_VS2012
- make testdraw2 the start project
- pass command line option --resize to the debuggee testdraw2
- starting the application testdraw2
- try to resize the window
- the application window resizes to a minimal size 0 x 124.
- the application crashes to divide by zero .... (this is only the aftermath
but a unhandled error condition)
- Added new SDL_HINT_ALLOW_TOPMOST hint, when set to "0" then never set the topmost bit on a window. Useful when debugging fullscreen issues.
- fixed crash in windows joystick scanning if we failed to load the xinput dll
- added support for SDL_WINDOW_FULLSCREEN_DESKTOP under windows
- synthesize relative mouse movements if directinput fails to send relative moves, happens under virtual box.
From Rick Johnson:
Here's the call pattern:
Create the window hidden
The game tells it to adjust the window position
Make the window visible.
A problem arises from the SetWindowsPos() - the default behavior of that would cause a WM_ACTIVATE message to be passed, of which SDL interprets that as the window now becoming visible and sets the flags. The window is not visible though. Now, when you try to call ShowWindow() - SDL sees those flags as indicating that the window is visible and early returns.
My proposed fix was that if we are calling set windows position and we aren't visible, add on the flag SWP_NOACTIVATE, which tells windows to not send down the WM_ACTIVATE flag.
Philipp Wiesemann 2012-09-30 05:56:09 PDT
I attached a patch which tries to implement the dropfile support for Microsoft
Windows. If applied SDL_DROPFILE events should be sent for single or multiple
files which are dropped on window.
The handling on Windows side is always activated (cursor will change and so on)
because there is no connection between SDL_EventState() and the window setup. I
assumed this additional overhead would be small and can be ignored.
It's a long-dead platform, and we don't have any way to build for, test, or
maintain it, so there's no sense in doing acrobatics to support it.
If you need Windows CE support, use SDL 1.2. If you need Windows Phone support,
send SDL 2.0 patches for the newer Windows Mobile platform.
Matthias Bentrup 2012-08-09 12:53:17 PDT
With OpenGL 4.3 the ARB added a new context flag for context reset isolation
and renamed the existing ES2 profile bit to ES profile bit, as it can be used
to request GLES 3 compatible contexts, too.
This patch adds these changes to SDL on Linux and Windows.
Also SDL lacks the ability to create shared contexts. This patch also adds a
new GL attribute to enable context sharing. As casting a GL context to int is
not portable, I added only a boolean attribute
SDL_GL_SHARE_WITH_CURRENT_CONTEXT, which makes the new context share resources
with the context current on the creating thread.
This required a small public API change: SDL_GL_SetSwapInterval() now accepts
negative values, and SDL_GL_GetSwapInterval() doesn't report errors anymore
(if it can't work, it'll return zero as a reasonable default).
If you need to test for errors, such as a lack of swap_control_tear support,
check the results of SDL_GL_SetSwapInterval() when you set your desired
value.
Here is my first rough attempt. "testrelative" feels right to me, but I'd like it someone else tested this, especially compared to Linux/OSX. The "Ctrl+r" to switch between relative and normal mouse movements seems to work flawlessly. With relative mouse movement, the only way to change focus is via keyboard. I'm not sure if that is the correct approach, but that would seem to be the most useful mode for games. Still, if my assumption is wrong, I can fix that no problem.
Matthias Bentrup 2011-10-30 03:58:24 PDT
I've updated the context creation patch to include the bugfixes by Martin
Schreiber and also included a profile bit to request a ES2 compatible profile.
The wgl context creation may use 2 call to wglChoosePixelFormat if no
acceleration attribute is selected, this should work around a bug with buggy
AMD drivers (see #1254).
