Rainer Deyke
If 'SDL_OpenAudio' is called with 'obtained == NULL', 'prepare_audiospec' performs a bad 'memcpy' with the destination and source pointing to the same block of memory. The problem appears to be on in 'SDL_OpenAudio', which calls open_audio_device with 'obtained = desired' when 'obtained == NULL'. 'open_audio_device' cannot deal with 'desired' and 'obtained' pointing to the same block of memory but can deal with 'obtained == NULL'
Testing:
* For each theme in Windows 7, Windows 7 Basic, and Windows 7 Classic:
- Ran testsprite2
- Pressed Ctrl-G to grab the mouse
- Alt-tabbed away, verified mouse is no longer grabbed
- Alt-tabbed back, verified that mouse was grabbed
- Alt-tabbed away
- Clicked in the window, verified mouse was grabbed
- Alt-tabbed away
- Grabbed the title bar and dragged the window around successfully, verified that mouse was grabbed when move modal loop completed
- Alt-tabbed away
- Clicked the minimize button on the title bar, the window was successfully minimized
- Clicked on the icon in the task bar, the window was restored and the mouse grabbed again
- Alt-tabbed away
- Clicked the close button on the title bar, the window was successfully closed
I added -Wshadow and then turned it off again because of massive variable shadowing in the blit macros.
Feel free to go through that code and fix these if you want. Just uncomment CheckWarnShadow in configure.in if you want to try this.
bill
In SDL_wave.c, BEXT wave files with "bext" instead of "fmt " are choked on
if (chunk.magic != FMT) {
SDL_SetError("Complex WAVE files not supported");
was_error = 1;
goto done;
}
BEXT files http://en.wikipedia.org/wiki/Broadcast_Wave_Format actually playback the same as regular waves. All they have is (A LOT OF) extra header info.
To open them, just SKIP the "bext" chunk, and the "fmt " chunk will be a couple of hundred bytes later.
The "fmt " chunk is also bloated, but if you skip past the extra information to the "data" chunk, there is nothing different about a BEXT wave file than a "normal" one.
You can then load the data and proceed as normal.
callow.mark
Compiling with SDL_VIDEO_RENDER_OGL=0, SDL_VIDEO_OPENGL=0, SDL_VIDEO_OPENGL_WGL=0, SDL_VIDEO_RENDER_OGL_ES2=1, SDL_VIDEO_OPENGL_ES2=1 and SDL_VIDEO_OPENGL_EGL=1 set in SDL_config_windows.h fails.
A patch is attached. See bug #2570 for reasons you might want to compile this way.
Zachary L
SDL_hapticlist and SDL_hapticlist_tail are not set correctly when quitting the subsystem. This matters because they are represented as global variables. In the case you quit and reinitialize the subsystems, problems with dangling pointers arise.
For instance, SDL_hapticlist_tail will not be null on second initialization and because of the check on line 298, it will fail to set SDL_hapticlist appropriately. This can cause a few things to go wrong, like feeding SDL_strcmp a null fname which can cause a segfault.
Alex Szpakowski
Now that SDL for iOS requires at least iOS 5.1 at runtime, there are several old codepaths in the UIKit backend which can be removed. I've attached a patch which does so.
Alvin
The new OpenGL ES 2.0 YUV Texture support does not correctly display padded, non-contiguous YUV data.
I am using SDL2 95bd3d33482e (as provided by 'hg id --id') from Mercurial.
The YUV data I am using is provided by the FFMPEG family of libraries. According to FFMPEG's documentation, "The linesize [pitch] may be larger than the size of usable data -- there may be extra padding present for performance reasons."
The dimensions of the video file that I am using are 480x360. What I get from FFMPEG is a Ypitch of 512, and Upitch and Vpitch are both 256.
When I pack new Y, U and V buffers with only the "usable" data (Ypitch is 480 and Upitch and Vpitch are both 240), and use those new buffers, the image is display correctly.
It appears that the Ypitch, Upitch and Vpitch parameters are not being used by SDL_UpdateYUVTexture().
I use SDL_PIXELFORMAT_YV12 for my YUV texture, however, the same results are seen when I use SDL_PIXELFORMAT_IYUV.
Not sure if this is related or not, but when I render the YUV texture (padded and unpadded) to a RGB24 texture, the resulting image is greyscale (or could by just the Y channel).
The URL field for this bug entry is set to my email (SDL mailing list archive) which includes an example image of what I see when rendering padded, non-contiguous YUV data.
sfalexrog
On systems with vsnprintf call SDL_SetError fails when passed a NULL as an argument. SDL's implementation checks for NULL (as seen in the commit: https://hg.libsdl.org/SDL/rev/835403a6aec8), but system implementation may crash.
Author: Sam Clegg <sbc@chromium.org>
Date: Fri Jun 20 12:52:11 2014
Fix win32 build which was failing due to missing PRIs64.
This change adds definitions for the C99 PRIs16 and PRIu64
which are missing from <stdint.h> on at last win32 and
possibly other platforms.
These already existed in testgesture.c so I removed them
from there also.
Add V=1 to the make command line will show the full commands but by default
we just show the tool-type and the output file. This is generally much easier
on the eye and makes warnings and errors more clearly visible.
Sylvain
If you play with the TouchScreen with +3 fingers randomly / pressing simultaneously all fingers.
You triggers FINGER DOWN events, but not always all the associated FINGER UP events.
So, after a while SDL_GetNumFingers() can report a wrong number of fingers pressed !
The explanation is hidden there : http://developer.android.com/reference/android/view/MotionEvent.html
Each pointer has a unique id that is assigned when it first goes down (indicated by ACTION_DOWN or ACTION_POINTER_DOWN).
A pointer id remains valid until the pointer eventually goes up (indicated by ACTION_UP or ACTION_POINTER_UP) or when the gesture is canceled (indicated by ACTION_CANCEL).
in ACTION_CANCEL :
The current gesture has been aborted. You will not receive any more points in it. You should treat this as an up event, but not perform any action that you normally would.
Constant Value: 3 (0x00000003)
Melker Narikka
Local files that are dropped onto a window under X11
are not going through a URI decoding step, resulting in the following
in my test application:
Dropped file /home/meklu/Pictures/Screenshot%20from%202013-10-30%2014:04:50.png
Couldn't load /home/meklu/Pictures/Screenshot%20from%202013-10-30%2014:04:50.png
Expected result:
Dropped file /home/meklu/Pictures/Screenshot from 2013-10-30 14:04:50.png
Loaded /home/meklu/Pictures/Screenshot from 2013-10-30 14:04:50.png successfully
I've attached a patch that fixes the issue by doing URI decoding in-place on
the file string buffer.
Ronie Salgado
The GL Renderer current context tracking fails when one window is used with an SDL renderer but another separate window is used with a user handled OpenGL context.
Attached is a small program that reproduces this bug, at least in some Linux machines where an OpenGL renderer is provided by default.
Expected Output:
-"First window" should be blue.
-"Second window" should be green.
Gotten Output:
- "First window" black.
- "Second window" blue.
What happened:
The renderer created for the "first window" ends rendering into the "second window" OpenGL context.
Bug location:
SDL_render_gl.c - line 286 on hg:
static SDL_GLContext SDL_CurrentContext = NULL;
When making SDL_GL_MakeCurrent from the user perspective, that variable or the GL renderer is not notified about the OpenGL context change.
Solution proposal:
- Move the current GL context cache into another place global.
J?rgen Tjern?
If you #define NO_SDL_GLEXT before including SDL_opengl.h, it still includes the platform-provided glext.h. The comments indicate that this define is intended to be used when you provide your own glext.h (quote from SDL_opengl.h: "Define this if you have your own version of glext.h and want to disable the version included in SDL_opengl.h.")
This is a problem because glext.h depends on the contents of gl.h, and it's practical to let SDL_opengl.h pick the right #include for gl.h for our platform.
Brad Smith
Attached is patch from the OpenBSD ports tree to add 24-bit support to the sndio backend and to make use of the sio_open() option SIO_DEVANY.
Diego
The Xcode Instruments Leak tool reports a leak from IODisplayCreateInfoDictionary in Cocoa_GetDisplayName.
This happened after upgrading to Xcode 5.
Frank Praznik
Add a gamepad mapping entry for Bluetooth DualShock 4 controllers on Linux.
The button mapping is the same as the USB controller, but the GUID is
different.
Stefan P?schel
if the variable NDK_MODULE_PATH is set to a relative path (like "../"),
compiling of a static SDL lib fails with an error similar to this:
make: *** No rule to make target
`..//android_libs/SDL/..//android_libs/SDL/src/main/android/SDL_android_main.c',
needed by
`obj/local/armeabi/objs/SDL2_static/__//android_libs/SDL/src/main/android/SDL_android_main.o'.
Stop.
Regarding the shared lib, this is already prevented by a "subst" command
in the /Android.mk, which removes all occurences of "$(LOCAL_PATH)/".
The attached patch does the same with the additional
"SDL_android_main.c", which is included for build the static SDL lib.
Added missing files to SDL2 project
Added missing Visual Studio 2008 tests to the solution
Added output paths which match the 2010+ projects
Added SDL project references instead of old style project dependencies
Removed post-build copy step and added data files to projects
Sam Lantinga
Gabriel Jacobo
Alex Baines
Ryan C. Gordon
Sam Clegg
Wander Lairson Costa