According to documentation in header and wiki the index should be returned.
This change may break existing programs which assume only 0 means a success.
q66
after updating SDL2 to the latest RC I'm unable to build my game engine under mingw crosscompiling environment for Windows (32bit, hosted on freebsd 64bit).
The error is in SDL_thread.h with messages like this: http://codepad.org/jEQXd3Yq
The problem is, while _beginthreadex return type is correctly mapped to uintptr_t (as specified by Microsoft), the return type under mingw is unsigned long int (same size, different signature), resulting in the error above.
The reason it didn't error before is this: http://codepad.org/8FAbKAxz
You can see the _beginthreadex case is only used without HAVE_LIBC defined; at one point though, SDL_config_windows.h was changed like this:
-/* Enabled for SDL 1.2 (binary compatibility) */
-#define HAVE_LIBC 1
+/* This is disabled by default to avoid C runtime dependencies and manifest requirements */
resulting in these errors.
Vern Jensen
The problem is that in certain situations I'm getting THREE keyUp/keyDown events when I push certain keys.
In my event code I added:
case SDL_KEYUP:
printf("SDL KeyScanCode for KEYUP event: %d\n", event->key.keysym.scancode );
…
and
case SDL_KEYDOWN:
printf("SDL KeyScanCode for KEYDOWN event: %d\n", event->key.keysym.scancode );
…
The result of one test run where I push 2 keys and then release them is this:
SDL KeyScanCode for KEYDOWN event: 92 // Pushed keypad 4
SDL KeyScanCode for KEYDOWN event: 83 // Pushed left shift
SDL KeyScanCode for KEYUP event: 83
SDL KeyScanCode for KEYDOWN event: 225
SDL KeyScanCode for KEYUP event: 92 // Released keypad 4
SDL KeyScanCode for KEYDOWN event: 83
SDL KeyScanCode for KEYUP event: 83
SDL KeyScanCode for KEYUP event: 225 // Released left shift
There *should* be only a total of 4 events above… 2 for each key being pushed, and 2 for each being released. But instead some bogus events for numlock being pushed/released are sent from SDL. These events did not occur. I did not push numlock. The value above for numlock is 83. Comments above show when I pushed each key. As you can see, when I push left shift, THREE events are instantly sent to my application, keyDown and then keyUp for numlock, and then the valid event for left shift (the key that was actually pushed).
You could replace keypad 4 with pretty much any keyPad key and it'll still happen. You can also replace it with any arrow key and it'll happen. However, when trying it with normal letter keys on the main keyboard it didn't.
It happens with other modifier keys too, not just left shift.
The order in which the keys are pressed matter. For instance, if I do:
1) keypad 4
2) left shift
3) release left shift
4) release keypad 4
Then at step 2, I get the 3 events above (when there should be only one), but steps 3 and 4 work properly… I don't get extra keyUp/keyDown events for steps 3 or 4. Thereas if the order of steps 3 and 4 are reversed, I get the bogus extra events for numlock.
Also, the problem can occur even when pushing just a single key by itself. If I push left shift, then keypad 4, then release left shift, then release keypad 4, then the following push of left shift will cause the bug. If I continue pushing and releasing left shift though, it won't happen again until I again involve keypad keys.
---
Sam Lantinga
According to the Apple documentation, NSNumericPadKeyMask is set for any arrow or numeric keypad event. Indeed this is what's happening.
I verified that we get the correct events for the numlock key and the mod state gets set correcly, so it should be safe to remove this bogus code.
David Gow
As discussed on the list, the autotools build backend uses libtool's "release" option, giving us the SONAME libSDL2-2.0.so.0, whereas CMake doesn't, giving us libSDL2.so.0
While libSDL2.so.0 has some small advantages (being simpler and matching the names on some other OSes better), many products have already been developed expecting libSDL2-2.0.so.0, which better matches SDL 1.2's SONAME. It seems clear, therefore, that most developers prefer this name.
This patch emulates libtool's functionality, making libSDL2-2.0.so.0 the name of the shared library, while leaving libSDL2.a as the filename of the static library. Unlike with libtool, no libSDL2.so symlink is yet made. I also haven't tested this on anything but Linux, so it might break other platforms. :/
Edgar Simo 2012-05-06 02:33:39 EDT
I recall that driver being buggy back in the day, but looking over the code there's a number of things being done wrong which I've fixed and it should now properly error out instead of crashing. Also make sure you initialize the haptic subsystem before using haptic commands (which I now more explicitly try to enforce).
Sebastian
Setting a window icon works just fine until a renderer is added to the window.
After adding the renderer the icon disappears.
Reproduce by:
- Take the example code from the wiki: http://wiki.libsdl.org/moin.fcg/SDL_SetWindowIcon
- Add the following two lines after SDL_FreeSurface(surface);
SDL_Delay(1000);
SDL_Renderer* ren = SDL_CreateRenderer(window, -1, SDL_RENDERER_ACCELERATED);
-compile and run
You will see the window icon correctly at first. After the Delay the Icon will disappear.
driedfruit
In X11_HideWindow, we call XUnmapWindow to unmap. According to ICCCN2.0, this should never happen, and XWithdrawWindow should be called instead.
http://www.tronche.com/gui/x/icccm/sec-4.html#s-4.1.4
"The reason for requiring the client to send a synthetic UnmapNotify event is to ensure that the window manager gets some notification of the client's desire to change state, ***even though the window may already be unmapped when the desire is expressed***."
Additionally, this can be observed at http://cgit.freedesktop.org/xorg/lib/libX11/tree/src/Withdraw.c#n65
Failure to comply leads to "MapNotify" event never appearing on non-reparenting WMs after subsequent show-hide-show requests. (I'm currently observing this behavior, thus my bug report).
My recent change broke the sdlcheck.cmake by not escaping some quotes properly.
Thanks to Marcus von Appen for pointing it out and providing the patch.
Lee Salzman
I messed up in the patch I sent you regarding gobbling up the GLX error codes signaled when trying to create a context. After reading the spec I realized those error codes are relative to a base error that needs to be queried when setting up the GLX extension...
So I have made a patch that fixes it for a user I had who was still getting the bug with my old patch.
Without this patch my previous one won't work, so it is recommended to merge this...
This #errors if you're using an SDK or deployment target that is less
than 10.6 and 10.5, respectively, and cleans up uses of
MAC_OS_X_VERSION_MIN_REQUIRED and MAC_OS_X_VERSION_MAX_ALLOWED according
to those requirements.
That is, if you copy from the Windows clipboard and then launch Dota and then repeatedly paste to a terminal window then the text will disappear when Dota hits the timeout. If you then select on the Linux side you can repeatedly paste. If you select again on Windows then the text will get cleared again.
Note that Dota only looks at the clipboard when it has focus.
CR: Saml
C++ is a bit of a minefield on Android. Much functionality still doesn't work, and Android can't decide on which C++ standard library to use, so it provides 3 different ones, all of which are incompatible with each other. (It looks like clang is coming too which will add a new compiler and a 4th standard library.)
As middleware, SDL might be distributed as a binary and intermixed with other projects already using C++. If C++ is intermixed in a bad way, bad things will happen. Removing dependencies on C++ will avoid this problem and downstream users won't have to worry/care.
Ryan C. Gordon
If you have the X11 SDK installed on Mac OS X, you'll build with X11 support, but the Makefile doesn't build anything but the Cocoa testnative code for Mac OS X, which is fine, but then testnative fails to link because testnative.h enables the X11 support based on the SDL config header.
Building the testnativex11.c code on Mac OS X doesn't work because you need to explicitly link with "-L/usr/X11/lib -lX11" if this code is enabled, but you can't link with that by default because the X11 SDK might be missing.
So this needs a little configure magic to do the right thing (or forcibly disabling X11 support on Mac OS X in testnative.h).
Edgar Simo
So basically the issue is that:
AC_PATH_PROG(SDL_CONFIG, sdl2-config, no, [$PATH])
in sdl2.m4 shares the same variable (SDL_CONFIG) as sdl.m4:
AC_PATH_PROG(SDL_CONFIG, sdl-config, no, [$PATH])
What happens is if you run the AM_PATH_SDL2 and then AM_PATH_SDL to say fall back on SDL if SDL2 isn't found, the AM_PATH_PROG command gets cached (ac_cv_path_SDL_CONFIG) so that unless you unset this cache variable, the result for AM_PATH_SDL will be EXACTLY the same as for AM_PATH_SDL2.
To fix I would recommend renaming SDL_CONFIG to SDL2_CONFIG in sdl2.m4, replacing all instances so it won't cache to the same variable.
Otherwise, if we destroyed a different renderer, next time this one draws,
it'll clear errors forever (GL_INVALID_OPERATION for having no current
context, at least on Windows), hanging up the program in an infinite loop.
Fixes Bugzilla #1775.
