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).
The top level code handles SDL_WINDOWPOS_CENTERED now, and the Cocoa SetWindowPosition call will clear the moveHack before adjusting the window position.
Jesse Anders 2011-03-05 23:30:09 PST
It seems that in Windows XP, setting SDL_GL_ACCELERATED_VISUAL to 1 actually
disables hardware acceleration and puts OpenGL in software mode.
In the source code, the corresponding WGL attribute is first set here:
*iAttr++ = WGL_ACCELERATION_ARB;
*iAttr++ = WGL_FULL_ACCELERATION_ARB;
Later, this code:
if (_this->gl_config.accelerated >= 0) {
*iAttr++ = WGL_ACCELERATION_ARB;
*iAttr++ =
(_this->gl_config.accelerated ? WGL_GENERIC_ACCELERATION_ARB :
WGL_NO_ACCELERATION_ARB);
}
Sets it again if SDL_GL_ACCELERATED_VISUAL has a value other than the default.
More importantly, the documentation I found states that
WGL_GENERIC_ACCELERATION_ARB asks for an MDC driver, which, although I don't
know much about this topic, doesn't seem like the correct choice here. As
mentioned previously, the end effect is that requesting hardware acceleration
in Windows XP actually forces the renderer into software mode (on my system at
least), which I'm guessing isn't the desired behavior.
The render viewport is automatically re-centered when the window changes size, so applications that don't care will not have to handle recalculating their rendering coordinates.
Fixed API for drawing and filling multiple rectangles - the parameter should be an array of rects, not an array of pointers to rects.
Fixed API for updating window rects for consistency with other APIs - the order is pointer to array followed by count in array.
