Previously, the padding was silence, which was a problem when streaming since
you would sample a little bit of this silence between each buffer.
We still need a means to get padding data for the right hand side, but this
patch makes the resampler output more correct.
Note that apps submitted to the iOS App Store *must* use a modern iOS SDK (currently iOS 10 is probably the minimum), however the SDK used to build is separate from the minimum iOS version an app supports at runtime.
Anthony
This is what's making the software renderer crash with rotated destination rectangles of w or h = 0:
SDL_SetHint(SDL_HINT_RENDER_SCALE_QUALITY, "2");
This time it's using real math from a real whitepaper instead of my previous
amateur, fast-but-low-quality attempt. The new resampler does "bandlimited
interpolation," as described here: https://ccrma.stanford.edu/~jos/resample/
The output appears to sound cleaner, especially at high frequencies, and of
course works with non-power-of-two rate conversions.
There are some obvious optimizations to be done to this still, and there is
other fallout: this doesn't resample a buffer in-place, the 2-channels-Sint16
fast path is gone because this resampler does a _lot_ of floating point math.
There is a nasty hack to make it work with SDL_AudioCVT.
It's possible these issues are solvable, but they aren't solved as of yet.
Still, I hope this effort is slouching in the right direction.
Ozkan Sezer
The patch below changes HAVE_COPYSIGN macro in SDL_config_windows.h to
HAVE__COPYSIGN, so that _copysign() can be used in SDL_stdlib.h which
is available in many more windows-targeting toolchains such as MinGW,
MSVC >= 6, etc, and not just MSVC >= 2013. SDL_stdlib.c already has a
specific check for HAVE__COPYSIGN, so I believe this is reasonable.
This would cause playback problems in certain situations, such as on the
Raspberry Pi. The device that the wait was added for seems to not benefit from
it in modern times, and standard desktop Linux seems to do the right thing
when a USB device is unplugged now, without this patch.
Fixes Bugzilla #3599.
Andreas Falkenhahn
My app opens a 640x480 window. When I click on the window's maximize button, the window correctly fills the entire screen and loses its borders. But clicking on the restore button now doesn't restore the window to its original 640x480 size. Instead, the window size is identical to the screen size now. The only difference to the previous state is that the window now has borders again but it isn't restored to 640x480.
bastien.bouclet
The window is now resized to its specified size, but it moves to the top left corner of the screen. That is unexpected because neither the user nor the program moved it there. Test program attached (the same one as before).
Simon Hug
When RWops seeks with fseek or fseeko it uses the types long or off_t which can be 32 bits on some platforms. stdio_seek does not check if the 64-bit integer for the offset fits into a 32-bit integer. Offsets equal or larger than 2 GiB will have implementation-defined behavior and failure states would be very confusing to debug.
The attached patch adds range checking by using the macros from limits.h for long type and some bit shifting for off_t because POSIX couldn't be bothered to specify min and max macros.
It also defines HAVE_FSEEKI64 in SDL_config_windows.h so that the Windows function gets picked up automatically with the default config.
And there's an additional error message for when ftell fails.
Andreas Falkenhahn
When compiling SDL for the Raspberry Pi, I have to use the --host parameter to enable compilation of the native Raspberry Pi video driver, like so:
--host=arm-raspberry-linux-gnueabihf
It took me a while to figure out that this was necessary in order to have the native Raspberry Pi video driver compiled in. I think it would be better if there was an option like --enable-video-rpi that could be passed to configure and that would also show up when saying configure --help. Currently, it?s rather difficult to figure out that you have to use the --host parameter with arm-raspberry-linux-gnueabihf in order to get Raspberry Pi video support. It?s also somewhat inconsistent because most other video drivers can in fact be enabled/disabled through specific configure parameters but there is no such parameter for the native Raspberry Pi video driver.
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.
Now we try the new (hardware-specific) pathnames first, and if those fail to
load, we'll try the more generic names that earlier versions of Raspbian used.
Fixes Bugzilla #3800.
Ozkan Sezer
HAVE_LIBSAMPLERATE_H is depending on HAVE_LIBC in current config.h.in:
it shouldn't be. HAVE_LIBUDEV_H, HAVE_DBUS_DBUS_H, HAVE_IBUS_IBUS_H,
HAVE_FCITX_FRONTEND_H, and HAVE_ALTIVEC_H have the same situation too.
I suggest something like the following, which moves them out of the
HAVE_LIBC confinement and also moves the windows dx header stuff along
side them. (Not ideal, but a bit cleaner I think.)
Ozkan Sezer
Cmake checks for float.h, but configure does not: the attached patch
adds float.h to checked headers in configury, and it adds the missing
HAVE_FLOAT_H macro to SDL_config.h.cmake and SDL_config.h.in.
In SDL_config_macosx.h and SDL_config_windows.h, defined HAVE_FLOAT_H
as 1, where I know that it's true.
Mart?n Golini
I'm having a very slow initialization of the video subsystem that locks the window creation for about 500 ms ( tested in at least 4 different systems ). What i found is that X11_InitModes_XRandR is using XRRGetScreenResources, that explicitly ask to poll the hardware for changes. This is not really necessary since if the data is already available you can use XRRGetScreenResourcesCurrent.
I attached a tentative patch that fix this issue. With the patch there's no lock when the subsystem is initialized and the window creation is instant in my applications. The patch only uses XRRGetScreenResourcesCurrent in X11_InitModes_XRandR but it could be potentially used in X11_GetDisplayModes and X11_SetDisplayMode.
bastien.bouclet
When creating two surfaces and blitting them onto the other, SDL's internal reference counting fails, and one of the surfaces is not freed when calling SDL_FreeSurface.
Example code :
SDL_Surface *s1 = SDL_CreateRGBSurfaceWithFormat(0, 640, 480, 32, SDL_PIXELFORMAT_ARGB8888);
SDL_Surface *s2 = SDL_CreateRGBSurfaceWithFormat(0, 640, 480, 32, SDL_PIXELFORMAT_ARGB8888);
SDL_BlitSurface(s1, NULL, s2, NULL);
SDL_BlitSurface(s2, NULL, s1, NULL);
SDL_FreeSurface(s2);
SDL_FreeSurface(s1);
With this example, s1 is not freed after calling SDL_FreeSurface, its refcount attribute is still positive.
This also seems to fix the follow-up issue in bug #3719, whereby the initial fix caused the SDL window to move, after transitioning from fullscreen to windowed-mode
This is necessary because the Raspberry Pi is a strange beast, that believes
it has OpenGL support (through glX?) but generally has GLES2 support.
So when using the raspberry video target, we need to force this to default
to a GLES2 context, or by default SDL_CreateWindow() will fail, deep down
when it tries to load the proper GL library.
Fixes testsprite2 (and basically everything else that wasn't testgles2) when
run on a Raspberry Pi without a X server.
Please note that other targets might also need this filled in, the Raspberry
Pi is just the most prominent and readily-available System-On-A-Chip style
thing on my desk. :)
Romain Tisserand
Using KMS/DRM driver from WIP SDL2.0.6 on Linux/ARM SoC RockChip RK3328 (ARM Mali 450 MP2 GPU).
The current code is using GBM_BO_FORMAT_XRGB8888 as GBM buffer format specifier.
The Mali driver (it has been confirmed some other vendor implementations too) expects GBM_FORMAT_XRGB8888.
The Mesa implementation is actually handling both values as the same, but it's not implemented like this into every gbm.h vendor header.
https://github.com/ideak/mesa/blob/master/src/gbm/backends/dri/gbm_dri.c
So with stock SDL2 on my card (Mali vendor implementation), it does not work, eglCreateWindowSurface fails, and gbm_is_format_supported fails too (with the BO variant).
It runs fine with GBM_FORMAT_XRGB8888.
Here is a link of the gbm.h from Mali user-space driver :
https://github.com/rockchip-linux/libmali/blob/rockchip/include/gbm.h
This is necessary because we need to see if GLES compat extensions exist.
All of this code (including ShouldUseTextureFramebuffer()) should be
revisited after 2.0.6 ships; ideally we don't make throwaway contexts if
we can avoid it...but maybe we can't. I hear Vulkan is pretty cool.
Fixes Bugzilla #3725.
Sylvain
Some API 16 methods are used (InputDevice: getDescriptor(), getVibrator()), so we need to compile at least with SDK API 16. Hence default.properties and project.properties have been modified to use android-16.
There are also some modification to SDLActivity.java not to use getVibrator() if we run under API 16. And not to check to presence of hasVibrator() if we are under API 11.
-some hard-coded constant can be expandend.
- rename a local variable (hasVibrator to hasVibratorService)
benjamin.feng
Probable underlying cause: https://bugzilla.libsdl.org/show_bug.cgi?id=3124#c5
"If you download and build the HID Calibrator sample you can see that these are totally legitimate HID devices (except for inverting the Y-axis of joysticks, which is contrary to the HID specification but does make them more compatible with games compiled expecting XBOX controllers)."
Sylvain
Since https://hg.libsdl.org/SDL/rev/6546daa45a02
SDL_android_main.c is empty and then produce a warning
nativeInit does not exist and dont need to be mark undefined
Colin Barrett
Using the pre-built x86 devel libs from here:
https://www.libsdl.org/release/SDL2-devel-2.0.5-VC.zip
If I have:
SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_ES);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 2);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 0);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_FLAGS, SDL_GL_CONTEXT_DEBUG_FLAG);
and I'm using ANGLE/(a GL driver that doesn't provide an ES2 context) such that SDL_EGL_CreateContext is called by SDL_GL_CreateContext, I get the error "Could not create EGL context (context attributes are not supported)" and no context is created.
Looking at the code in SDL_EGL_CreateContext - if gl_config.flags is non-zero, it looks like the code in the section guarded with "#ifdef EGL_KHR_create_context" should be executed - but it apparently isn't.
Is it possible this section hasn't been compiled into the pre-built libraries? If I build SDL2.dll myself using the Visual C++ solution (VS2015 Community Update 3) then the call succeeds as I expect
bastien.bouclet
When exiting a "fullscreen space" on OS X, windows don't go to their defined "windowed mode size", but go back to their previous size.
Steps to reproduce:
1. Create a windowed mode SDL window
2. Toggle it to fullscreen with the SDL_WINDOW_FULLSCREEN_DESKTOP flag
3. While in fullscreen, change the windowed mode size using SDL_SetWindowSize
4. Toggle the window back to windowed mode
Expected result:
- The window has the size specified during step 3.
Actual result:
- The window has the size specified when creating the window in step 1.
Attached is a minimal reproduction test case.
The attached test case works as expected on X11 and Windows.
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.
Ozkan Sezer
Since the Vulkan merge, building against a Mac OS X SDM older than
10.11 fails in SDL_cocoametalview.m because Metal.framework is not
present. There is no conditional compiling in SDL_cocoametalview.m
either, so --disable-video-vulkan doesn't help with anything. (The
configury doesn't check darwin for x86_64 either, but it's another
story.)
I cross-build against 10.8 SDK on linux using clang-3.4.2 and this
is a problem for me. Will this be fixed?
Simon Hug
This issue actually raises the question if this API change (requirement of initialized audio subsystem) is breaking backwards compatibility. I don't see the documentation saying it is needed in 2.0.5.
"Major changes, roughly in order of appearance:
- Use float math everywhere, instead of promoting to double and casting back
all the time.
- Conserve sound energy when downmixing any channel into two other channels.
- Add a QuadToStereo filter. (The previous technique of reusing StereoToMono
never worked, since it assumed an incorrect channel layout for 4.0.)
- Add a 71to51 filter. This removes just under half of the cases the previous
code would silently break in.
- Add a QuadTo51 filter. More silent breakage fixed.
- Add a 51to71 filter, removing another almost-half of the silently broken
cases.
- Add 8 to the list of values SDL_SupportedChannelCount will accept.
- Change SDL_BuildAudioCVT's channel-related logic to handle every case, and
to actually fail if it fails instead of silently corrupting sound data and/or
crashing down the road."
(Note that SDL doesn't otherwise support 7.1 audio yet, but hopefully it will
soon and the 7.1 converters are an important piece of that. --ryan.)
Fixes Bugzilla #3727.
David Brady
When I attempted to make a mapping file for Android gamepads, I quickly discovered that most of the ones that I have here show up as the same device (Broadcom Bluetooth HID), meaning that it was impossible to make mappings on Android, since every device looked the same.
This patch will check for the existence of the getDescriptor function added in Jelly Bean, and use it if it's there. The Android Dashboard says that the majority of Android phones should support this function, and doing it this way will not force us to bump up our API version.
chw
Control key sequences from hardware keyboards (wireless/USB/bluetooth) get not properly reported on Android devices.
The attached patch uses the idea from http://stackoverflow.com/questions/12337117/capture-all-ctrl-under-android to make control key sequences appear as normal SDL_KEYDOWN events instead of cooked text input.
Clayton Craft
The default path used by directfb for libGL is different than the default path used by x11 in SDL2:
./src/video/directfb/SDL_DirectFB_opengl.c:
path = "libGL.so";
./src/video/x11/SDL_x11opengl.c:
#define DEFAULT_OPENGL "libGL.so.1"
On at least one distro (Alpine Linux), libGL.so is not created (or more accurately the symlink to libGL.so.1 is not created). For consistency, the 'path' variable in SDL_DirectFB_opengl.c should patch the DEFAULT_OPENGL in SDL_x11opengl.c ("libGL.so.1")
Ozkan Sezer
Revision 288 (http://hg.libsdl.org/SDL/rev/2f5a6062db86) excluded the
Watcom compiler from forcing 4 byte structure packing in begin_code.h.
However, it missed updating close_code.h, which now has an unbalanced
#pragma pack(pop) if the compiler is Watcom. The issue seems to have
crawled into SDL2, too.
Error message was:
[mvk-info] MoltenVK version 0.18.2. Vulkan version 1.0.51.
[***MoltenVK ERROR***] VK_ERROR_INITIALIZATION_FAILED: On-screen rendering requires a view that is backed by a layer of type CAMetalLayer.
2017-08-28 02:17:29.579 testvulkan[95627:1716939] ERROR: SDL_Vulkan_CreateSurface(): vkCreateMacOSSurfaceMVK failed: VK_ERROR_INITIALIZATION_FAILED
David Ludwig
I've created a new set of patches. I am happy to create more, if it would help.
One version only copies 'size'.
A second version copies both 'size' and 'silence'. When looking over the documentation for SDL_OpenAudio in SDL_audio.h, it mentioned that both 'size' and 'silence' were things that SDL_OpenAudio would calculate.
Regarding *both* patches, I did notice that SDL 1.2 appears to have always modified desired's size and silence fields. The SDL wiki, at https://wiki.libsdl.org/SDL_OpenAudio#Remarks , does note:
Carlos
We would like to add a switch (define) that allows us to compile Angle statically with SDL. That is, getting rid of the OpenGL DLL. Usually you need OpenGL to be loaded dynamically as DLL because implementation is provided by the system but no need with Angle.
Only 2 files need modification and it shouldn't affect current behaivor:
include/SDL_egl.h and src/video/SDL_egl.c, as in here
https://github.com/native-toolkit/sdl/pull/10/files
The flag name could be SDL_VIDEO_STATIC_ANGLE (instead of NATIVE_TOOLKIT_STATIC_ANGLE) as discussed here https://github.com/native-toolkit/sdl/pull/10
We have tested this with both Windows and UWP, using NME engine (https://github.com/haxenme/nme).
Releated issue: https://bugzilla.libsdl.org/show_bug.cgi?id=1820
Sylvain
Hi! here's a patch for that with two class loaded regarding API level.
Test both case : before API 11 and after.
I also remove now unused GetSystemServiceFromUIThread() and minor clean-up (haptic warning prototype).
Sylvain
Small patch for this issue. I tested it and it seems to work.
- it can send several backspaces (instead of only 1).
- it calls directly "sendKeyEvent()" instead of "super.sendKeyEvent()".
otherwise, it would go through the android internals, calling again "onKey()".
and then the "backspace" would arrive after the next "commitText()".
sfalexrog
Android haptic code was not added to CMakeLists.txt, leading to build failures when targeting Android platform.
Attached patch adds Android haptic driver to source sets and adds configuration parameter to SDL_config.h.cmake.
Tom Seddon
0f0ad62237 (git head at the time of writing); Visual Studio 2015, toolset v140, Platform 10.0.14393.0, building for x64
Windows non-MinGW cmake build sets defines implying wcslcpy and wcslcat are available, but Windows doesn't have these functions.
Ryan C. Gordon
That's weird, these are the exact two functions that Emscripten incorrectly believed it had until we upgraded the buildbot's emsdk install.
Not sure what's up with this, but it's possibly not a MingW-specific thing!
This fixes a strange corner case (notes appended below), and should be
safe to do anyhow.
Fixes Bugzilla #3674.
"I did more tests.
It appears the bug only happens if there is
another window on the screen that has "always
on top" property. For me it is xawtv - it is
always opened in a screen corner. Closing
xawtv or removing "always on top" property
from it makes the problem to go away.
Plus, it doesn't appear like the buttons are
not delivered at all. It appears that instead
the button presses are delivered on some mouse
positions, but not delivered when you move the
mouse to other part of the window... So this is
really weird and is likely somewhere deep in the
Xorg.
Maybe somehow it happens that the cursor is
actually above the xawtv window, but, because
my app uses grab, it is not visible there, and
in that case the events are not delivered to
my app?
But with my patch the button events are
always delivered flawlessly, it seems.
Hmm, and that indeed seems to explain my problem:
if the mask is set properly and my app uses
grab, then, even if the mouse is above some
other window, the events would still be delivered
to the grabbing app, which is what actually wanted
because my app uses relative mouse mode, so it
doesn't know the pointer can cross some other window
(my app draws the pointer itself).
So my current theory is that my patch only enforces
the mouse grab, which otherwise can be tricked by
some other window preventing the button events
delivery (but motion events are still delivered
via xinput2, which makes it all look very obscure)."
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.
macOS currently needs this if you build with X11 support. iOS doesn't
(currently), but it doesn't hurt to compile it in case we do something
Unixy on that platform later on.
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.
Charles Huber
The event timestamp members should be documented to indicate their meaning and units.
Currently the timestamps are populated using SDL_GetTicks() in SDL_PushEvent() in SDL_events.c.
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).
manuel.montezelo
Original bug report (note that it was against 2.0.0, it might have been fixed in between): http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733015
--------------------------------------------------------
Package: libsdl2-2.0-0
Version: 2.0.0+dfsg1-3
Severity: normal
Tags: patch
I have occasional crashes here caused by the X11 backend of SDL2. It seems to
be caused by the X11_Pending function trying to add a high number (> 1024)
file descriptor to a fd_set before doing a select on it to avoid busy waiting
on X11 events. This causes a buffer overflow because the file descriptor is
larger (or equal) than the limit FD_SETSIZE.
Attached is a possible workaround patch.
Please also keep in mind that fd_set are also used in following files which
may have similar problems.
src/audio/bsd/SDL_bsdaudio.c
src/audio/paudio/SDL_paudio.c
src/audio/qsa/SDL_qsa_audio.c
src/audio/sun/SDL_sunaudio.c
src/joystick/linux/SDL_sysjoystick.c
--------------------------------------------------------
On Tuesday 24 December 2013 00:43:13 Sven Eckelmann wrote:
> I have occasional crashes here caused by the X11 backend of SDL2. It seems
> to be caused by the X11_Pending function trying to add a high number (>
> 1024) file descriptor to a fd_set before doing a select on it to avoid busy
> waiting on X11 events. This causes a buffer overflow because the file
> descriptor is larger (or equal) than the limit FD_SETSIZE.
I personally experienced this problem while hacking on the python bindings
package for SDL2 [1] (while doing make runtest). But it easier to reproduce in
a smaller, synthetic testcase.
Martin Gerhardy
just for easier debugging issues in the own code...
SDL_CreateRenderer should maybe also use this macro
Ryan C. Gordon
I'll go one better: it should have an SDL_assert().
Marcus von Appen
The LT_LDFLAGS in Makefile.in contain the $(DESTDIR) in -rpath, which instructs libtool to take a wrong path into account for linking.
The issue arises, if DESTDIR is passed at build time and installation time.
-rpath only should use $(libdir) for both SDL 1.2 and SDL 2.x.
Leonardo
Structure SDL_gestureTouch gets reallocated for every new added gesture but its never freed.
Proposed patch add the function SDL_GestureQuit() that takes care of doing that and gets called when TouchQuit is called.
Gabriel Jacobo
Thanks for the patch. I think it needs a bit of extra work though, looking at the code in SDL_gesture.c , I see that SDL_numGestureTouches only goes up, I think the right fix here involves adding SDL_GestureDelTouch (hooked into SDL_DelTouch) as well as SDL_GestureQuit (as you posted in your patch).
Rainer Deyke
I've written a small patch that adds a small SDL_DuplicateSurface function to SDL. I've written the function as part of a larger (as yet unfinished) patch, but I think this function is useful enough that it merits inclusion in SDL on its own.
Alvin
I'm interested in this bug as well. I have experienced it when trying to embed an SDL_Window into a FLTK application. To do this, I create a FLTK window (window inside a window - think video player) and then use SDL_CreateWindowFrom() on the inner most window's Xlib Window*. After which, I create a renderer.
In my situation I am using the FLTK GUI toolkit.
What I have experienced is that the SDL_CreateRender() will recreate the window in order to properly setup OpenGL capability. As part of this process, the window is hidden and a call is executed that waits indefinitely for an acknowledgement that the window was indeed unmapped. This is where my program hangs.
Please correct me if I am wrong, but should SDL2 not make Xlib calls that effect the Xlib Window in this situation (e.g. When SDL_CreateWindowFrom() is used)? The toolkit being used typically assumes responsibility and, I presume, tracks all Xlib Windows it creates.
On line src/video/SDL_video.c:1372 the comment associated with setting SDL_WINDOW_FOREIGN reads:
/* Can't destroy and re-create foreign windows, hrm */
Since I do not know the reason for hiding the window in the first place, the attached patch simply does not wait for a response when X11_XWithdrawWindow() and X11_XMapRaised() are issued by X11_HideWindow() and X11_ShowWindow(), respectively. I presume that the GUI toolkit (GTK, FLTK, etc.) has or will consume the acknowledging event as it is managing the Xlib Window (or it thinks it is).
I have tested the patch against hg 5c645d037de2 and I have successfully tested:
* Embedding the SDL_Window inside a FLTK application.
* Calling SDL_SetWindowSize() when FLTK resizes the window (e.g. dragging cursor on the edge of the window).
* Filling the renderer's default target blue and drawing a red fill square at the centre (exciting, I know!)
* Calling SDL_Quit() when the application terminates
I do not receive any Xlib erorr messages (BadWindow, etc.) in any of those situations.
Ozkan Sezer
Attached three patches, so these minor os/2 bits get registered mainstream:
1. SDL_syswm.h: add SDL_SYSWM_OS2 to SDL_SYSWM_TYPE enum
2. SDL_platform.h: recognize __EMX__ too as __OS2__
3. begin_code.h: set SDLCALL as _System for OS/2.
UX-admin
I am compiling with the Sun Studio 12 u2 compiler. There are multiple issues with the build, but this particular issue appears to be that it is illegal to declare a union of a struct of floats and a float. While GCC 4.8.1 does not flag this as an error, Sun Studio is much more standards compliant and strict, halting further compilation with an error.
afwlehmann
Sorry for re-opening, but it turns out that the current interval is indeed not updated. I've just checked the source code of the 2.0.3 release again:
163 if (current->canceled) {
164 interval = 0;
165 } else {
166 interval = current->callback(current->interval, current->param);
167 }
168
169 if (interval > 0) {
170 /* Reschedule this timer */
171 current->interval = interval; // <-- this line is missing
172 current->scheduled = tick + interval;
173 SDL_AddTimerInternal(data, current);
174 } else {
According to the documentation: "The callback function is passed the current timer interval and the user supplied parameter from the SDL_AddTimer() call and returns the next timer interval. If the returned value from the callback is 0, the timer is canceled."
If I understand the text correctly, then the current interval should in fact be updated according to the returned value. Otherwise there would be a discrepancy between the next time for which the timer is actually re-scheduled and the value that's passed to the callback once the timer fires again.
This could be fixed by adding line #171.
Ozkan Sezer
The attached patch makes testautomation_sdltest.c more compatible wrt
LLONG_{MIN|MAX} macros and makes it to compile on older systems (e.g.
glibc-2.8) too, by replacing LLONG_{MIN|MAX} with INT64_{MIN|MAX}.
c.f.: bug #3494, where the same issue was described for SDL_test_fuzzer.c
Ozkan Sezer
An array defined like int xPositions[] = {-1, 0, 1, w-1, w, w+1 };
errors with Open Watcom: it strictly wants constants. Small patch
like below makes things more compatible.
Sylvain
This still happens with the current trunk version. (software renderer of testdrawchessboard.c)
When there is a rotation, the window size changed and the internal surface is marked as "surface_valid == SDL_FALSE".
And all further call fails.
SDL_video.c :
2478 void
2479 SDL_OnWindowResized(SDL_Window * window)
2480 {
2481 window->surface_valid = SDL_FALSE;
2482 SDL_SendWindowEvent(window, SDL_WINDOWEVENT_SIZE_CHANGED, window->w, window->h);
2483 }
some error set to :
2233 return SDL_SetError("Window surface is invalid, please call SDL_GetWindowSurface() to get a new surface");
So, this seems to be the behavior of the API ...
In the loop() function of testdrawchessboard.c, we can recreate the surface/renderer :
65 if (e.type == SDL_WINDOWEVENT)
66 {
67 if (e.window.event == SDL_WINDOWEVENT_SIZE_CHANGED)
68 {
69 surface = SDL_GetWindowSurface(window);
70 renderer = SDL_CreateSoftwareRenderer(surface);
71 }
72 /* Clear the rendering surface with the specified color */
73 SDL_SetRenderDrawColor(renderer, 0xFF, 0xFF, 0xFF, 0xFF);
74 SDL_RenderClear(renderer);
75 }
And it displays correctly.
Ozkan Sezer
The attached patch removes SDLCALL attribute from SDL_BlitFunc() funcptr.
As far as I can see, *SDL_BlitFunc() is completely internal to SDL with
no specific calling convention requirements. The actual functions assigned
to SDL_BlitFunc seem to not have any calling conventions specified. So,
easy solution is simply removing the strict calling convention from the
type.
Sylvain
Here's a patch.
It tries to get the hint first. Resizable will allow any orientation. Otherwise it uses width/height window.
setOrientation method is splitted in static and non-static, so that it can be overloaded in a user subclass.
Some artefact observed :
surfaceChanged() can be called twice at the beginning. When the phone starts in portrait and run a landscape application.
Clayton Craft
linux_input module is disabled by default, despite the comments in source code that it is otherwise:
src/video/directfb/SDL_DirectFB_video.c:
devdata->use_linux_input = readBoolEnv(DFBENV_USE_LINUX_INPUT, 0); /* default: on */
src/video/directfb/SDL_DirectFB_video.h:
#define DFBENV_USE_LINUX_INPUT "SDL_DIRECTFB_LINUX_INPUT" /* Default: on */
When using the directfb driver, the linux_input module is suppressed unless the SDL app is started with "SDL_DIRECTFB_LINUX_INPUT=1" set in the environment. I recall seeing at one point that the directfb folks recommended using linux_input over the other input drivers, but I am having trouble locating this recommendation. In any case, I believe that this should really be defaulted to 'on' since it's vastly superior to the other dfb input drivers!
Jimb Esser
Note: This is using DirectInput, I have to disable XInput as that causes all but the first 4 controllers to be completely ignored by SDL (I can find no way to reconcile XInput devices with DirectInput devices, otherwise I would make a patch that accepts the fifth and later controllers with DirectInput...). XInput does not seem to have the problem below, only DirectInput.
I plug in 3 identical wireless Xbox 360 controllers, call them J1, J2, J3. Direct Input shows them as having GUIDs G1, G2, G3. I unplug J1, then J2 and J3 show up as having GUIDs G1 and G2! Not so "unique"... I start my SDL app when just J2 and J3 are plugged in, and open J2 and J3. Then I plug in a new controller, SDL sees that now G3 exists, assigns that a new SDL joystick instance ID, which I request to be opened, but G3 at this point is J3, which I already had opened! So I end up with two instances of J3 opened, and none of J1. "Re-"opening G1 would get the actual handle to the newly attached controller, but there's no current way to know this. This is clearly a bug or poor design in DirectInput or my wireless receiver drivers, but is a showstopping bug for my 8-20 player games (as soon as any one controller runs out of battery or goes to sleep and gets turned back on, suddenly things are busted requiring a restart (or, at least, a reinitialization of all controllers - the game can't go on)).
The solution I found is to use HID paths instead of GUIDs to uniquely identify joysticks. GUIDs are still needed to open a controller, however I have added code to re-find the GUIDs for all joysticks whenever a new joystick is attached or removed. This does now require opening of all joysticks (instead of just enumerating them), though if your app, like mine, is opening all of them anyway so that any can press a button to join, that doesn't change much (although perhaps they joysticks should be kept open in this case, instead of closed and re-opened). If your app only ever opens one joystick, this will do more work at startup than it did previously.
Jonas Kulla
This eliminates the need to manually compile in SDL_main_android.c.
Instead, add "-lSDL2main -Wl,-u,SDL_main_dummy" when linking.
I don't know how the nkd-build process works, but unless it was
for some reason linking libSDL2main.a it should be unaffected.
Mark Callow
README-android says to copy or link the SDL source tree to the jni folder in your Android project. It is not desirable to have to compile SDL with every application; furthermore the Android NDK has support for prebuilt libraries.
Attached is script (to be put in build-scripts) that builds the Android version of the libraries. The script builds both the existing SDL2 module and a new SDL2_main module. This is a static library containing the code from src/main/android/SDL_android_main.c. Also attached is a patch for Android.mk adding this module.
Note that when building an application's native .so using this prebuilt libSDL2main, you must use a link option, such as --whole-archive, that forces inclusion of the code in the .so because the functions in SDL_android_main are called only from Java.
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.
Edward Rudd
Device: Logitech Rumble Gamepad F510 in Xinput mode.
Upon opening the joystick the values of the axes are queried via PollAllValues are not actually set on the device all the time.
This can easily be seen in the testjoystick or testgamecontroller test programs,as the testjoystick shows all axes in the center until one 'tickles' the triggers., and the testgamecontroller will show the triggers as 'on' until on 'tickles' the triggers.
Upon further research the culprit is the SDL_HINT_JOYSTICK_ALLOW_BACKGROUND_EVENTS hint. In the default value events are ignored until there is an active window, Thus in cases where the joystick system is initialized and controllers opened before the initial window is created & focuses, the initial values will be incorrect.
Here is my current workaround in the game I'm working on porting..
SDL_SetHint(SDL_HINT_JOYSTICK_ALLOW_BACKGROUND_EVENTS, "1");
SDL_GameController* gamepad = SDL_GameControllerOpen(index);
SDL_SetHint(SDL_HINT_JOYSTICK_ALLOW_BACKGROUND_EVENTS, "0");
Edmund Horner
When a 16-bit "565 format" surface has a colour key set, it will blit with correct transparency. If, however, it has its colour key set then is converted to a 32-bit ARGB format surface, the colour key in the converted image will not necessarily be the same pixel value as the transparent pixels. It may not blit correctly, because the colour key does not match the right pixels.
In my case, with an image using 0xB54A for transparency, the colour key was converted to 180,170,82; but the corresponding pixels (with the same original value) were converted to 180,169,82. Blitting the converted image did not use transparency where expected.
I have attached a test case. The bug has been replicated on both x86_64 Linux (SDL 2.0.2), and 32-bit MS C++ 2010 on Windows (SDL 2.0.0).
malferit
Hello, I began a little program with SDL2 on Linux in C, and when I call SDL_Init(SDL_INIT_VIDEO) I get an error and this is printed in the console:
XDM authorization key matches an existing client!
I searched through Internet, and found that some people suggest to run 'xhost +' or to specify this in /etc/X11/xdm/xdm-config:
DisplayManager*authName: MIT-MAGIC-COOKIE-1
I don't think an end user needs to know that...
But what bothered me is that first I started this little program in Pascal using the Freepascal compiler and it works. In freepascal you only use some thin header bindings in Pascal and then it links with the dynamic SDL library, so I don't understood why it worked with Freepascal and not in C.
I run ldd to the two generated applications:
Application in C:
linux-gate.so.1 (0xffffe000)
libSDL2-2.0.so.0 => /usr/lib/libSDL2-2.0.so.0 (0xb76ac000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb766e000)
libc.so.6 => /lib/libc.so.6 (0xb74e2000)
libm.so.6 => /lib/libm.so.6 (0xb74a0000)
libdl.so.2 => /lib/libdl.so.2 (0xb749a000)
librt.so.1 => /lib/librt.so.1 (0xb7491000)
/lib/ld-linux.so.2 (0xb77b3000)
Application compiled with Freepascal:
linux-gate.so.1 (0xffffe000)
libSDL2-2.0.so.0 => /usr/lib/libSDL2-2.0.so.0 (0xb762a000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb74f3000)
libc.so.6 => /lib/libc.so.6 (0xb7367000)
libm.so.6 => /lib/libm.so.6 (0xb7325000)
libdl.so.2 => /lib/libdl.so.2 (0xb731f000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb7305000)
librt.so.1 => /lib/librt.so.1 (0xb72fc000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb72dc000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb72d9000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb72d3000)
/lib/ld-linux.so.2 (0xb7755000)
It seems that Freepascal is linking with libX11, libxcb, libXau and libXdmcp .
Linking my C application with libxcb solved the problem (linking with libXau and/or libXdmcp without libxcb didn't work). Linking with X11 links all the other libraries and works as well.
So I fill this bug report mainly to let you know about this. I don't know if it is a problem that can be solved on the libSDL side or not, but at least I hope it will help.
Hi, some tests:
1. Disabled XDM. Login in console and running 'startx'. The program works without having to link with X11.
2. Enabled XDM. Added 'DisplayManager*authName: MIT-MAGIC-COOKIE-1' to /etc/X11/xdm/xdm-config.The program works without having to link with X11.
3. Enabled XDM without 'DisplayManager*authName: MIT-MAGIC-COOKIE-1' in /etc/X11/xdm/xdm-config . I get the authentication error unless I link with X11.
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.
Witek Jachimczyk
I'm using SDL to develop a video viewer for MATLAB. The window is scrambled while using thightVNC with its default mode of RGB656.
SDL does not correctly recognize the pixel mode.
I found a solution for this problem. The solution involves modifying
SDL/src/video/SDL_pixels.c
Adding the following "if statement" under case 16: of SDL_MasksToPixelFormatEnum resolves the issue:
if (Rmask == 0x003F &&
Gmask == 0x07C0 &&
Bmask == 0xF800 &&
Amask == 0x0000) {
return SDL_PIXELFORMAT_RGB565;
}
I hope that this helps someone. I took me a while to figure it out.
Yann Dirson
When SDL_GL_GetProcAddress returns in error, the cause of the error is overwritten
in GL_GL_GetAttribute, reporting to the user "Failed getting OpenGL glGetString entry point", whereas the original "OpenGL library not loaded" never makes it
to the user.
Pushed a fix to:
f94cb13708
Note that the "OpenGL library not loaded" error looks like no root cause either,
and I'm still puzzled by the code path used: I'm forcing opengles2 renderer on
the x11 video driver on a rpi2, as in https://bugzilla.libsdl.org/3169, and although I now know that I must force the use of the RPI video driver instead
of the x11 one, I suspect even more accurate info can be given to user.
Daniel Gibson
AZERTY keyboard layouts (which are the default layouts in France and Belgium) don't have the number keys (1, 2, ..., 9, 0) in the first row of keys, but ?, &, ?", ', (, -, ?_, ??), = (with small differences between the France and Belgian variants). Numbers are reached via shift.
On Linux and OSX, SDL seems to use the corresponding ISO 8859-1 codes (231 for ?232 for ?tc) as SDL_Keycode (but no SDK_* constants exists for those values!), while on Windows SDL seems to map those keys to SDLK_1, SDLK_2 etc, like you'd get on QWERTY.
I don't know how other platforms behave.
So we have two problems:
1. At least on Linux and OSX invalid/undefined SDL_Keycodes are returned
2. Different platforms behave differently (Windows vs Linux/OSX)
It's unclear what behavior is desired: Should SDL_* constants for those keys be introduced (and Windows behavior changed accordingly)?
Or should all platforms behave like Windows here and use the existing SDLK_1, ..., SDLK_0 keycodes?
This bug on the mailing list:
https://forums.libsdl.org/viewtopic.php?t=11555 (my post about Linux/Windows)
https://forums.libsdl.org/viewtopic.php?t=11573 (Tim Walters discovered the same problem on OSX about 1.5 weeks later).
Sylvain
Let's you have a SDL_Surface that has ColorKey, but no Alpha Modulation.
When this surface is duplicated with SDL_ConvertSurface function, the result has ColorKey and Alpha Modulation (BLEND, and Opaque 255).
I think SDL_ConvertSurface should strictly keeps the input format.
example
=======
SDL_Surface *input; // ... Set up a surface with ColorKey and no AlphaMod
SDL_Surface *output = SDL_ConvertSurface(input, input->format, input->flags);
// "output" surface has a ColorKey but *also* AlphaMod (BLEND, and Opaque 255).
Rafal Muzylo
"if we're already using libtool, why aren't we using it ?"; they've been inspired by the fact, that at that mark, neither libSDL2_test.a nor libSDL2main.a were being built correctly (not sure if it's fully broken or just because I've tested the out-of-tree build)
Simon Hug
The bug is in the GL_ResetState and GLES_ResetState functions which get called after a new GL context is created. These functions set the cached current color to transparent black, but the GL specification says the initial color is opaque white.
The attached patch changes the values to 0xffffffff to reflect the initial state of the current color. Should the ResetState functions get called anywhere else in the future, this probably has to call the GL functions itself to ensure that the colors match.
Adam M.
The keysym.mod field does not reflect the state of the modified keys when processing key down events for the modifier keys themselves. The documentation says that it returns the current key modifiers, but they are not current for key down events involving modifier keys. I interpret "current" to mean "equal to SDL_GetModState() at the instant the event is processed/enqueued".
For example, if you depress the Shift key you get a key down event with .mod == 0. However, .mod should not be 0 because a shift key is down. If you then release the Shift key, you get a key up event with .mod == 0. Neither event reports the modifier key.
If you press Shift and then A, .mod is incorrect (== 0) when Shift is pressed, but is correct later when A is pressed (== KMOD_LSHIFT).
You might say this behavior is deliberate, i.e. keysym.mod is the value /before/ the event, not the current value as documented, but that explanation is incorrect because only key down events behave that way. Key up events correctly give the current value, not the value before the event.
Not only is it inconsistent with itself, I think it makes keyboard processing harder.
The problem is near line 740 in SDL_keyboard.c:
if (SDL_KEYDOWN == type) {
modstate = keyboard->modstate; // SHOULD THIS BE MOVED DOWN?
switch (keycode) {
case SDLK_NUMLOCKCLEAR:
keyboard->modstate ^= KMOD_NUM;
break;
case SDLK_CAPSLOCK:
keyboard->modstate ^= KMOD_CAPS;
break;
default:
keyboard->modstate |= modifier;
break;
}
} else {
keyboard->modstate &= ~modifier;
modstate = keyboard->modstate;
}
In the key down path, modstate (and thus keysym.mod) ends up being the modifier state /before/ the event, but in the key up path modstate ends up being the modifier state /after/ the event. Personally I think the "modstate = keyboard->modstate" line should just be moved after the entire if/else statement, so that keysym.mod always reflects the current state.
owen
I removed all the static variables from SDLActivity.java
Updated all the SDL_android.c jni calls as well
I added a new function to SDL_android.c/ h
void Android_JNI_SeparateEventsHint(const char* c);
This is called by SDL_androidtouch.c so that this TU doesn't need to call any JNI functions.
Philipp Wiesemann
There is another problem with the current implementation which maybe should be fixed first (to prevent some work). It was written as if it would get the number of a button from the Java side but actually it gets the state of all buttons. That is why it should not work if more than one button is pressed at once.
Ian Abbott
I just spotted what I think is a bug in "src/thread/pthread/SDL_sysmutex.c" in the SDL_TryLockMutex function when FAKE_RECURSIVE_MUTEX is defined (for an implementation of Pthreads with no recursive mutex support). It calls pthread_mutex_lock instead of pthread_mutex_trylock, so it will block until the mutex is available instead of returning SDL_MUTEX_TIMEDOUT if it cannot lock the mutex immediately.
Coriiander
Here is a minor correction for a non-breaking mistake in SDL_setenv for __WIN32__ platform. See below for details.
FILE:
"SDL/src/stdlib/SDL_getenv.c"
FUNCTION: (__WIN32__ platform)
int SDL_setenv(const char *name, const char *value, int overwrite)
CODE:
if (!overwrite) {
char ch = 0;
const size_t len = GetEnvironmentVariableA(name, &ch, sizeof (ch));
if (len > 0) {
return 0; /* asked not to overwrite existing value. */
}
}
WHAT'S WRONG:
The 3th argument to GetEnvironmentVariable (being DWORD nSize) must be the number of characters, not the number of bytes. SDL currently passes "the size of 1 char", rather "1". While it is non-breaking (1=1 after all), it is incorrect. Furthermore there is no need to specify the 2nd and 3th arguments at all.
CORRECTION 1: (corrected argument_
if (!overwrite) {
char ch = 0;
const size_t len = GetEnvironmentVariableA(name, &ch, 1);
if (len > 0) {
return 0; /* asked not to overwrite existing value. */
}
}
CORRECTION 2: (stripped of unneeded code)
if (!overwrite) {
if (GetEnvironmentVariableA(name, NULL, 0) > 0) {
return 0; /* asked not to overwrite existing value. */
}
}
Juha Niemim?
On AmigaOS 4 platform with Newlib 'C' library, there is a problem with failing fseeko64. This seemed to be caused by using fopen instead of fopen64.
Littlefighter19
When trying to mirror something on the PSP, I've stumbled upon the problem,
that using SDL_RenderCopyEx with SDL_FLIP_HORIZONTAL flips the image vertically, vise-versa SDL_FLIP_VERTICAL flips the image horizontally.
Proposed patch would be swapping the check in line 944 with the one in line 948 in SDL_render_psp.c
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.
Simon Hug
The RGBA_FROM_PIXEL macro in src/video/blit.h [1] is not designed to work with more than 8 bits per channel and the ARGB2101010 format makes it read outside of the array bounds causing access violations. This can happen during blitting with the BlitNtoNPixelAlpha and SDL_Blit_Slow functions.
When SDL_InitFormat tries to calculate the loss of the channels [2], the Uint8 will wrap around and it will end up at 254 for the 10-bit channels. Clearly way over the 9 entries of the SDL_expand_byte array. (Not that a signed integer would help.) Then the macro tries to access the lookup table with the channel value which could be up to 1023. If the previous indirection didn't cause an access violation this one will.
I guess it's not worth modifying this macro for a format that only a few will use. It will only make the other blitters slower. I don't have good ideas to solve this issue.
Attached is a test case that does three blits. A copy one that work and the two that use the functions mentioned above.
[1] https://hg.libsdl.org/SDL/file/cd1994d4f3c6/src/video/SDL_blit.h#l303
[2] https://hg.libsdl.org/SDL/file/cd1994d4f3c6/src/video/SDL_pixels.c#l540
ny00
According to the current documentation in SDL_hints.h, if SDL_HINT_ANDROID_SEPARATE_MOUSE_AND_TOUCH is set to "0" (or not set at all) then mouse input should lead to touch events, along with corresponding *fake* mouse events with mouse id SDL_TOUCH_MOUSEID.
However, while moving a mouse around (actually using a trackpad identified as a mouse), I get SDL mouse motion events with differing mouse ids, as follows:
- If the mouse is moved while a mouse button is pressed, the mouse id is SDL_TOUCH_MOUSEID.
- Otherwise, the mouse id for mouse motion events is 0.
I've attached sample code for reference, which includes logs of the various mouse events (the "which" field is covered).
I believe that no actual mouse event should arrive, if the hint is unset. In particular, no mouse motion event should arrive while no mouse button is pressed.
I'm going to attach a patch which resolves this, while also disabling mouse wheel motion events.
xyzdragon
Reading https://wiki.libsdl.org/SDL_RenderCopyEx there is no mention what the angle means. Normally in a mathematically environment positive angles translate to counter-clockwise rotations, but in SDL positive angles means clockwise rotation.
Daniel
SDL_RenderReadPixels with SDL_RENDERER_SOFTWARE reads pixels from wrong coordinates.
SW_RenderReadPixels adjusts the rect coordinates according to the viewport. But since this is already done by SDL_RenderReadPixels, the final rect has x2 bigger X and Y.
Fabian Greffrath
we use SDL_GetPrefPath() in Chocolate Doom to get a reasonable directory to save and restore config files and savegames:
https://github.com/chocolate-doom/chocolate-doom/blob/sdl2-branch/src/m_config.c#L2162
However, since there is no "organization" behind Chocolate Doom and there is really only one "product" called Chocolate Doom, we pass an empty string for the org parameter and the package string for app.
This leads to two consecutive slashes in the path returned by SDL_GetPrefPath() like this:
/home/user/.local/share//chocolate-doom/
While this is harmless, it sure looks bad.
I believe that it should be possible to either pass a NULL pointer for the org parameter or at least have the function detect an empty string as a means to express "there is no origanization, just a single product". The generation of the path string to be returned by the function will have to get adapted accordingly.
Eric Wasylishen
Alt-Up/Down/Left/Right switches between displays using SDL_WINDOWPOS_CENTERED_DISPLAY
Shift-Up/Down/Left/Right shifts the window by 100px
Eric Wasylishen
Small change to checkkeys so you can toggle text input mode with a mouse click.
This is needed for testing how dead keys react to toggling mouse input, i.e. these bugs:
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.
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.
Simon Hug
KMSDRM_VideoInit allocates and frees some connectors and encoders but doesn't set the pointer to NULL after freeing. The cleanup code at the end may free one of those garbage pointer should an error happen in the initialization.
Simon Hug
When WIN_WindowProc processes the WM_TOUCH message, it doesn't check if the touch functions have been properly loaded and may call a NULL pointer. It's probably an extremely rare case, but here's a patch that adds some checks anyway.
Sylvain
On Android, when shared libraries are not correctly loaded (eg SDLActivity.mBrokenLibraries is true), there is a pop-up with an error message.
After user dismisses the pop-up, application crashes:
- because the native function "nativePause()" may no be loaded (if libSDL2.so is not loaded).
- because mSurface is null.
tschwinger@elitemail.org
Most ironically, although autoconf/automake-based builds install (pretty half-assed) CMake package configuration files, they're missing in installations resulting from CMake-based builds entirely.
A proper configuration file typically also loads target exports (implemented in patch 3572, also fixing this issue - see my comment on that issue for details).
I believe it would be best to let the dinosaurs go extinct and redirect all build efforts to the CMake end for two reasons:
1. It potentially provides the best user experience, but you'd have to give it some love and ship with less quirky buildfiles.
2. It would force distros to build SDL via CMake and thus would ensure target exports are actually available everywhere.
Various CMake patches I submitted today in summary (directly converted from the HG commits and `am`d onto a fork of a git mirror that happened to be on `tip`).
https://github.com/tschw/SDL/commits/patched
Fixing #2576#3572, #3613, and this fresh ticket, which is almost entirely advertisement ;).
These already do to make SDL much less of a quirky fella to have in your dependency tree...
Martin Gerhardy
- list(APPEND EXTRA_CFLAGS ${MIR_TOOLKIT_CFLAGS} ${EGL_CLFAGS} ${XKB_CLFLAGS})
+ list(APPEND EXTRA_CFLAGS ${MIR_TOOLKIT_CFLAGS} ${EGL_CFLAGS} ${XKB_CFLAGS})
CFLAGS is spelled wrong in two different ways for EGL and XKB
And while you are on it...
sdl needs mir >= 0.24 afaik - it fails on travis-ci (ubuntu 14.04 LTS with 0.18 installed and in other environments, too (e.g. https://github.com/urho3d/Urho3D/issues/1685)
To fix this one should add a min version check to pkg_check_modules like this
- pkg_check_modules(MIR_TOOLKIT mirclient mircommon)
+ pkg_check_modules(MIR_TOOLKIT mirclient>=0.24 mircommon)
-Enabling checking for GCC_ATOMICS also on clang by default. This way all Android ABIs build successfully
-Android cmake: Threading was not enabled correctly
-Android cmake: Timers and dynamic lib loading were not included in the sources
Eric wing
Hi, I think I found a bug when using SDL_WINDOW_ALLOW_HIGHDPI with SDL_RenderSetLogicalSize on iOS. I use SDL_RenderSetLogicalSize for all my stuff. I just tried turning on SDL_WINDOW_ALLOW_HIGHDPI on iOS and suddenly all my touch/mouse positions are really broken/far-off-the-mark.
I actually don't have a real retina device (still) so I'm seeing this using the iOS simulator with a 6plus template.
Attached is a simple test program that can reproduce the problem. It uses RenderSetLogicalSize and draws some moving happy faces (to show the boundaries/space of the LogicalSize and that it is working correctly for that part).
When you click/touch, it will draw one more happy face where your button point is.
If you comment out SDL_WINDOW_ALLOW_HIGHDPI, everything works as expected. But if you compile with it in, the mouse coordinates seem really far off the mark. (Face appears far up and to the left.)
Alex Szpakowski on the mailing list suggests the problem is
"I believe this is a bug in SDL_Render?s platform-agnostic mouse coordinate scaling code. It assumes the units of the mouse coordinates are always in pixels, which isn?t the case where high-DPI is involved (regardless of whether iOS is used) ? they?re actually in ?DPI independent? coordinates (which matches the window size, but not the renderer output size)."
Additionally, if this is correct, the Mac under Retina is also probably affected too and "as well as any other platform SDL adds high-dpi support for in the future".
Levi Bard
In some environments, xrandr modes initialization can fail even though xrandr support is present and of a sufficient version.
(The one I encountered was an AWS instance running a virtual display)
The attached patch allows SDL to keep trying other methods if xrandr modes initialization fails (still subject to SDL_VIDEO_X11_REQUIRE_XRANDR).
Manuel
The attached patch adds support for KMS/DRM context graphics.
It builds with no problem on X86_64 GNU/Linux systems, provided the needed libraries are present, and on ARM GNU/Linux systems that have KMS/DRM support and a GLES2 implementation.
Tested on Raspberry Pi: KMS/DRM is what the Raspberry Pi will use as default in the near future, once the propietary DispmanX API by Broadcom is overtaken by open graphics stack, it's possible to boot current Raspbian system in KMS mode by adding "dtoverlay=vc4-kms-v3d" to config.txt on Raspbian's boot partition.
X86 systems use KMS right away in every current GNU/Linux system.
Simple build instructions:
$./autogen.sh
$./configure --enable-video-kmsdrm
$make
Now the clipboard isn't lost if you destroy a specific SDL_Window, as it
works on other platforms. You will still lose the clipboard data on
SDL_Quit() or process termination, but that's X11 for you; run a
Clipboard Manager daemon.
Fixes Bugzilla #3222.
Fixes Bugzilla #3718.
Eric Wasylishen
I think I found a better fix.
The problem with https://hg.libsdl.org/SDL/rev/ebdc0738b1b5 is setting the styleMask to 0 clears the NSWindowStyleMaskFullScreen bit, which then confuses Cocoa later when you try to leave fullscreen. Instead I'm just clearing the NSWindowStyleMaskResizable bit, although SetWindowStyle(window, NSWindowStyleMaskFullScreen); seems to also work.
Eric Wasylishen
Unfortunately this commit seems to have broken exiting desktop-fullscreen.
- Launch testgl2.
- Press alt+enter to go fullscreen-desktop
- Press alt+enter again. The spinning cube will freeze, and the window stays fullscreen desktop.
Simon Hug
SDL_GL_GetAttribute doesn't check if a video driver has been initialized and will access the SDL_VideoDevice pointer, which is NULL at that point.
I think all of the attributes require an initialized driver, so a simple NULL check should fix it. Patch is attached.
Jason Wyatt
After hiding the window, SDL_WINDOW_HIDDEN/SDL_WINDOW_SHOWN flags on a window are correctly updated. However on the next SDL_PumpEvents, they are set incorrectly.
This appears to be because X11_GetNetWMState does not check whether the _NET_WM_STATE property exists (it shouldn't on unmapped windows, see https://specifications.freedesktop.org/wm-spec/wm-spec-1.3.html#idm140130317598336). This results in an empty list of atoms for the state, which would imply that the window is not hidden.
(Seen on Fedora 24, Gnome)
--
Dan Ginsburg
More details on my proposed patch: I am on Kubuntu 16.04.2. I ran into this same bug, but with Jason's patch I found that actualType != None was true so the SDL_WINDOW_HIDDEN would still not be set. My fix instead is to explicitly check for whether the window is unmapped rather than relying on the returned values in XGetWindowProperty.
felix
The functions in src/render/SDL_yuv_mmx.c contain the following inline assembly snippet:
/* tap dance to workaround the inability to use %%ebx at will... */
/* move one thing to the stack... */
"pushl $0\n" /* save a slot on the stack. */
"pushl %%ebx\n" /* save %%ebx. */
"movl %0, %%ebx\n" /* put the thing in ebx. */
"movl %%ebx,4(%%esp)\n" /* put the thing in the stack slot. */
"popl %%ebx\n" /* get back %%ebx (the PIC register). */
Here's how it ended up in a binary on my old laptop:
0xb5c17dbd <ColorRGBDitherYV12MMX1X+93>: push $0x0
0xb5c17dbf <ColorRGBDitherYV12MMX1X+95>: push %ebx
0xb5c17dc0 <ColorRGBDitherYV12MMX1X+96>: mov 0xc(%esp),%ebx
0xb5c17dc4 <ColorRGBDitherYV12MMX1X+100>: mov %ebx,0x4(%esp)
0xb5c17dc8 <ColorRGBDitherYV12MMX1X+104>: pop %ebx
Apparently the compiler, oblivious to the fact that the assembly snippet manipulates the %esp register, decided to refer to the operand via that same register instead of via %ebp (I believe -fomit-frame-pointer enables this). This causes %ebx to be loaded with the wrong value, which later leads to a null pointer dereference.
Recent GCC can use the %ebx register normally: <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47602#c16>. There is even an explicit constraint "b" for allocating it.
Holger Schemel
Summary: This patch adds support for key events for the "rewind" and "fast forward" media keys on the Amazon Fire TV remote control.
How to reproduce the problem: Run Android build of SDL2 application on the Amazon Fire TV (tested with "stick" version) and log key events.
Expected behaviour: Every key pressed on the Fire TV remote control should result in a corresponding key event (pressed/released).
Observed behaviour: Of the bottom row of buttons on the Fire TV remote control, only the "play/pause" (middle) button generates a key event, while the "rewind" (left) and "fast forward" (right) buttons to not generate any event at all.
The attached patch adds support for these two missing buttons/keys.
Note 1: Some missing definitions were added for the already existing key codes SDL_SCANCODE_APP1 and SDL_SCANCODE_APP2 (to keep up the correct order of enumerations / array positions when adding the two new key codes).
Note 2: Definitions in "scancodes_linux.h" and "scancodes_xfree86.h" (to also add support for these keys on other platforms) were added without testing. However, I was unable to find corresponding definitions for these two media keys for Windows and Mac OS X.
Note 3: I have also updated the (broken) link to the USB usage page standard PDF document (comment in "include/SDL_scancode.h").
kdrakehp
The attached patch adds capture support to the sndio backend.
The patch also allows the `OpenDevice' function to accept arbitrary device names.
Bogomancer
On X11, windows created using the shaped window API appear distorted unless the width of the shape surface is divisible by 8.
Steps to reproduce:
1) Use your favorite image editor to resize one of the images in test/shapes/ to a width that's not a multiple of 8.
2) Compile and run test/testshape.c on the image you edited.
3) The shaped window will appear twisted and distorted.
It appears the bug was not caught sooner because all the test images are either 640 or 256 pixels wide.
I tracked down the bug to SDL_CalculateShapeBitmap() in SDL_shape.c. The shape surface is reduced to a 1-bit-per-pixel mask, but the original code doesn't take into account that X11 apparently wants each scanline to begin on a new byte.
Juha Niemim?ki
Fix for PTHREAD_MUTEX_RECURSIVE_NP check and restoring the original flags
Two fixes proposed:
1) Looks like there is a copy-paste issue regarding PTHREAD_MUTEX_RECURSIVE_NP check.
2) Compiler flag restoration doesn't look symmetrical regarding if/endif blocks. Moved to an outer block (if PTHREADS).
Ozkan Sezer
(In reply to Ryan C. Gordon from comment #9)
> I've put this patch in as https://hg.libsdl.org/SDL/rev/7213ae46e870 ...can
> you verify this works on the latest MinGW?
>
> Thanks,
> --ryan.
This patch is wrong: the structure in question has nothing to do with any
gcc version in use. I suggest reverting this adding a conigury check for
it, instead. Something like the following should do it: (configure needs
regenerating.)
Mark Callow
SDL_ShowMessageBox calls SDL_CaptureMouse which, in the UIKit driver, raises a ?That operation is not supported? error, overwriting the SDL error that an application may be trying to report.
This is because UIKit SDL_CaptureMouse returns SDL_Unsupported() which ends up calling SDL_SetError() which has the following code:
/* If we are in debug mode, print out an error message */
SDL_LogDebug(SDL_LOG_CATEGORY_ERROR, "%s", SDL_GetError());
The SDL_GetError call here overwrites the static buffer?..
Although an application can avoid this by using SDL_GetErrorMsg(char* errstr, int maxlen) to avoid the static buffer, SDL should be fixed.
The fix is simple. In SDL_SetError change
SDL_LogDebug(SDL_LOG_CATEGORY_ERROR, "%s", SDL_GetError());
to
SDL_LogDebug(SDL_LOG_CATEGORY_ERROR, "%s", error);
where error is the pointer to the buffer where it assembled the message.
Amruth Raj
- My app runs in full screen to play video(I use SDL_WINDOW_FULLSCREEN_DESKTOP)
- Cmd-tab to go out of full screen to another app
- Cmd-tab again to get back to my app
- Press left mouse button at one of the edges of the screen, don't release yet.
After this point the main thread is stuck until I release the left mouse button and hence video rendering doesn't happen anymore.
On debugging more, I see that thread 0 is stuck as shown below with sendEvent processing left mouse down. It comes out only after it receives a left mouse up. There are some frames below which show NSWindowResizing, but my window flag doesn't have SDL_WINDOW_RESIZABLE set.
Thread 0:: CrBrowserMain Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fffbe13d34a mach_msg_trap + 10
1 libsystem_kernel.dylib 0x00007fffbe13c797 mach_msg + 55
2 com.apple.CoreFoundation 0x00007fffa889d434 __CFRunLoopServiceMachPort + 212
3 com.apple.CoreFoundation 0x00007fffa889c8c1 __CFRunLoopRun + 1361
4 com.apple.CoreFoundation 0x00007fffa889c114 CFRunLoopRunSpecific + 420
5 com.apple.HIToolbox 0x00007fffa7dfdebc RunCurrentEventLoopInMode + 240
6 com.apple.HIToolbox 0x00007fffa7dfdcf1 ReceiveNextEventCommon + 432
7 com.apple.HIToolbox 0x00007fffa7dfdb26 _BlockUntilNextEventMatchingListInModeWithFilter + 71
8 com.apple.AppKit 0x00007fffa6396a54 _DPSNextEvent + 1120
9 com.apple.AppKit 0x00007fffa6b127ee -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 2796
10 com.apple.AppKit 0x00007fffa66f568d +[NSWindow(NSWindowResizing) _mouseHysteresisCheck:withExpiration:andDistance:finalMouseLocation:] + 525
11 com.apple.AppKit 0x00007fffa65eedb5 -[NSWindow(NSWindowResizing) _hitTestWithHysteresisCheck:forEvent:allowWindowDragging:] + 394
12 com.apple.AppKit 0x00007fffa6c8f0db -[NSWindow(NSEventRouting) _handleMouseDownEvent:isDelayedEvent:] + 1873
13 com.apple.AppKit 0x00007fffa6c8ca6c -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 1942
14 com.apple.AppKit 0x00007fffa6c8bf0a -[NSWindow(NSEventRouting) sendEvent:] + 541
15 org.libsdl.SDL2 0x000000010d46d74a -[SDLWindow sendEvent:] + 90
16 com.apple.AppKit 0x00007fffa6b10681 -[NSApplication(NSEvent) sendEvent:] + 1145
17 org.libsdl.SDL2 0x000000010d46532b -[SDLApplication sendEvent:] + 139
18 org.libsdl.SDL2 0x000000010d466b2f Cocoa_PumpEvents + 495
19 org.libsdl.SDL2 0x000000010d44c1d5 SDL_PumpEvents_REAL + 53
20 org.libsdl.SDL2 0x000000010d44c2f5 SDL_WaitEventTimeout_REAL + 53
21 org.libsdl.SDL2 0x000000010d44c2b7 SDL_PollEvent_REAL + 23
22 org.libsdl.SDL2 0x000000010d51bb24 SDL_PollEvent + 36
23 libTest.dylib 0x000000010cf3e0e8 SDLEventProcessor::processEvents(int) + 568
24 Test 0x000000010cde6bba BrowserApp::RunAppMessageLoop(BAInstData*, CefStringBase, CefStringBase) + 810
25 Test 0x000000010ce04bbc main + 17980
26 libdyld.dylib 0x00007fffbe016235 start + 1
I further noticed that while entering full screen in SDL_cocoawindow.m NSResizableWindowMask is set. If I clear it inside windowDidEnterFullScreen, then, the issue doesn't repro.
This is discussed at https://discourse.libsdl.org/t/main-thread-gets-stuck-on-left-mouse-down/22753/3 and thanks to Eric for the pointers.
The Xlib documentation demands that 32-bit values here be passed in a long,
even when long itself isn't a 32-bit value. Otherwise libx11 might read
memory incorrectly.
Fixes Bugzilla #3692.
Simon Hug
There's a chance that an audio conversion from many channels to a few can use more than 9 audio filters. SDL_AudioCVT has 10 SDL_AudioFilter pointers of which one has to be the terminating NULL pointer. The SDL code has no checks for this limit. If it overflows there can be stack or heap corruption or a call to 0xa.
Attached patch adds a function that checks for this limit and throws an error if it is reached. Also adds some documentation.
Test parameters that trigger this issue:
AUDIO_U16MSB with 224 channels at 46359 Hz
V
AUDIO_S16MSB with 6 channels at 27463 Hz
The fuzzer program I uploaded in bug 3667 has more of them.
This only affects Wayland and DirectFB, as a Unix system generally has X11
support. Other platforms also have different sizes for the C union in
question, but are likely the only target for that platform, etc.
Apps that might run on Wayland or DirectFB will need to be compiled against
new headers from an official 2.0.6 release, or be prepared to force the x11
target, or not use SDL_GetWindowWMInfo().
Fixes Bugzilla #3428.
Now the compiler might say this:
'SDL_compile_time_assert_mytest' declared as an array with a negative size
instead of
'SDL_dummy_mytest' declared as an array with a negative size
It's easier for Visual Studio users that want this information to turn it on
or live without it, than it is to explain why every debugger that isn't Visual
Studio crashes out here. Eventually SetThreadDescription() will be the thing
everyone uses anyhow.
Fixes Bugzilla #3645.
(and several others).
Failing to check if a key was known to be pressed by SDL was causing
SDL_SendKeyboardKey to send duplicate key pressed events with the repeat
property set to true.
Fixes Bugzilla #3637.
The message sent upon the window being activated or deactivated, to trigger
the call to SDL_SetKeyboardFocus was missing a mandatory parameter. So
keyboard focus was never properly set.
Fixes Bugzilla #3658.
We don't fill buffers just to throw them away during shutdown now, we let the
AudioQueue free its own buffers during disposal (which fixes possible warnings
getting printed to stderr by CoreAudio), and we stop the queue after running
any queued audio during shutdown, which prevents dropping the end of the
audio playback if you opened the device with an enormous sample buffer.
Fixes Bugzilla #3555.
We need more than two buffers to flip between if they are small, or CoreAudio
won't make any sound; apparently it needs X milliseconds of audio queued when
it needs to play more or it drops any queued buffers. We are currently
guessing 50 milliseconds as a minimum, but there's probably a more proper
way to get the minimum time period from the system.
Fixes Bugzilla #3656.
Fixes Bugzilla #3448.
"Starting with Android API 13, another configuration change must be declared
to be handled by the app if it is desired to not let the system handle
rotation itself:
https://developer.android.com/guide/topics/resources/runtime-changes.html#HandlingTheChange
This will have effect if either a developer or SDL per default will set target
API > 12. Currently it is set to 12, but this might change in the future, like
when applying this patch: https://bugzilla.libsdl.org/show_bug.cgi?id=3445
The effect of not having this change applied is that the SDL app is destroyed
upon rotation. Even when the manifest has an additional entry to e.g. always
stay in landscape mode, the onDestroy() call will happen on devices that are
portrait per default, when switching off screen due to power save. The device
will then (at least try to) rotate into portrait to show the portrait screen
lock after resume.
I believe it is safe to apply this patch even with target API still set to 12,
the additional parameter is simply ignored."
"In particular, only one VkSurfaceKHR can exist at a time for a given window. Similarly, a native window cannot be used by both a VkSurfaceKHR and EGLSurface simultaneously"
CR: SamL
If an Emscripten app is in relative mouse mode and the user presses Escape
(or whatever is appropriate), then the pointer lock is broken by the browser.
This keeps track of those losses, and next time the user presses a mouse
button down on the canvas, if the app is still meant to be in relative mouse
mode, we will attempt to regrab the pointer.
This makes it much more seamless for things like first-person shooters, and
the app doesn't need any manual intervention.
Fixes Bugzilla #3562.
From Sylvain:
"With an android landscape application, if you quickly lock, then unlock your
device, you can see sometimes a quick glitch: screen badly draws in portrait,
then it correctly displays in landscape.
Not talking of a smooth rotation, it's a drawing glitch. And you need to have
a plain lock screen, with no model nor passphrase.
I think it happens because the call to "nativeResume()" occurs sometimes too
early.
It should be done once you have *all* those three things (in any sequence):
- onWindowsFocusChanged() set to true
- onResume() called
- a valid call to onSurfaceChanged()
Currently, this is not the case: you don't need to have onResume() called.
Just need to have isPaused, (eg onPaused()).
So "isPaused" should be renamed as "isResumedCalled".
But you also need some kind of isPaused state to make sure to don't call
nativePause() twice (and deadlocks...).
There are also redundant checks to "mHasFocus" and some creation of the
initialisation thread code from onSurfaceChanged() that could me moved.
So here's this patch:
- add some states, so we have cleaner transitions.
- make sure "onResume()" is called.
- some clean up
- it also goes faster in pause state (focus changed, onPause, without requiring isSurfaceReady which does seems to be needed).
Tested on a few devices and it removes the glitch.
But I haven't tested when the activity goes back to "init" state."
Samuel Hopkins
Just confirming that the patch from Andreas (attachment 1715 [details]) works for me under SDL 2.0.3 with xmonad.
Stas Sergeev
Confirming that the patch in this ticket fixes the full-screen switching for dosemu2 on ubuntu-16.04. Note that I am not using xmonad, so this bug appears to be generic.
"Using an application in portrait orientation, turning off the device would
dispatch SDL_APP_WILLENTERBACKGROUND, then SDL_APP_DIDENTERBACKGROUND then
lock the screen.
However, rotating the application the application to landscape, then turning
off the device would incorrectly dispatch SDL_APP_WILLENTERBACKGROUND,
SDL_APP_WILLENTERBACKGROUND, SDL_APP_WILLENTERFOREGROUND and then
SDL_APP_DIDENTERFOREGROUND before locking the screen. You can imagine how
this created trouble :)
It appears this occurs because (on this application) turning off a device
when in landscape is triggering a resize. The resize logic in SDLActivity
triggers a resume.
This patch has resolved the issue on my device:
It prevents the dispatch of (improper) FOREGROUND events when locking
the device, but we get still events when the device is turned back on
and unlocked."
This gracefully recovers when a device format is changed, and will switch
to the new default device if the current one is unplugged, etc.
This does not handle when a new default device is added; it only notices
if the current default goes away. That will be fixed by implementing the
stubbed-out MMNotificationClient_OnDefaultDeviceChanged() function.
"ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement]"
Moving some variable declarations to the top of Android_SetScreenResolution()
* alsa hotplug thread is low priority
* give a chance for other threads to catch up when audio playback is not progressing
* use nonblocking for alsa audio capture
There is a bug with SDL hanging when an audio capture USB device is removed, because poll never returns
These don't have to be power-of-2 sizes anymore because of SDL_AudioStream,
and the new resampler, but also, many platforms don't give you power-of-2 DMA
buffer in the first place!
We will throw away the data anyhow, but some apps depend on the callback
firing to make progress; testmultiaudio.c, if nothing else, is an example
of this.
Capture also will now fire the callback in these conditions, offering nothing
but silence.
Apps can check SDL_GetAudioDeviceStatus() or listen for the
SDL_AUDIODEVICEREMOVED event if they want to gracefully deal with
an opened audio device that has been unexpectedly lost.
According to Steam's OS stats, Windows 8.0 use is pretty much nil. Further,
Microsoft hasn't support Windows 8.0 development in any of their
actively-updated toolchains, and setting it up can be a pain.
In theory, SDL2 still supports Windows 8.0, however building of Windows 8.0
.dlls is no longer the default, if and when using the 'winrtbuild.*' scripts.
The MSVC 2012 project files for building Windows 8.0 dlls remain, though,
for the time being.
This is just enough to get you through a file that just used the extended
header for float or int data. It doesn't handle all the other things that
you expect from this header, like 24-bit samples inside a 32-bit container
or speaker masks.
This should remain binary compatible with Windows XP, as we dynamically
load anything we need and fall back to DirectSound/WinMM/XAudio2 if not
available.
Like other C runtimes, it should probably produce the string "(null)".
This bug probably only affected Windows, as most platforms use their standard
C runtime's snprintf().
Walter van Niftrik
We have found that since SDL 2.0.5 the audio callback thread is created with a very small stack size. In our application this is leading to stack overflows.
We believe there is a bug at http://hg.libsdl.org/SDL/file/391fd532f79e/src/audio/SDL_audio.c#l1132, where the is_internal_thread flag appears to be inverted.
Volumetric
In X11 the SDL error "Unknown touch device" can occur after which the application stops recognizing touch events. For a kiosk-type application this results in a hang as far as the user is concerned. This is reproducible on HP Z220/Z230/Z240 workstations by swapping USB cables for a while and it also occurs with no physical changes, probably due to USB device power management. A workaround is to make SDL re-enumerate the touch devices like it does at startup. A patch is attached.
Matthew
Its possible to set SDL_CaptureMouse() so you continue receiving mouse input while the mouse is outside your window. This works however There is then a gap where no messages send, which is when the mouse is hovering the title bar and the window edges.
X11 seemed to be confused by the broad definition, so WEIGHT_NAME,
SLANT and SETWIDTH_NAME were defined, thus fixing the font lookup
on some systems (tested on Mageia 6 with X11 1.19.1).
Fixes bug 3571.
Tom Seddon
GL_ActivateRenderer may call GL_UpdateViewport, which leaves the GL_PROJECTION matrix selected. But after GL_ResetState, the GL_MODELVIEW matrix is selected, suggesting that's the intended default state.
It seems at least like these should be consistent. Presumably GL_UpdateViewport should be doing a glMatrixMode(GL_MODELVIEW) before it finishes.
Also updates the naming of these Xbox Wireless Controllers connected via USB (and thus the third-party Xbox Controller Driver) to match.
The Xbox Wireless Controller entries are now listed, in order, via USB, bia Bluetooh (with older firmware) and via Bluetooth (with firmware 3.1.1221.0).
This is a bleeding edge API, added to Windows 10 Anniversary Edition (build
1607, specifically).
https://msdn.microsoft.com/en-us/library/windows/desktop/mt774976(v=vs.85).aspx
Nothing supports this yet, including WinDbg, Visual Studio, minidumps, etc,
so we still need to also use the RaiseException hack. But presumably tools
will use this API as a more robust and universal way to get thread names
sooner or later, so we'll start broadcasting to it now.
Firmware revision 3.1.1221.0 changes the mapping of the Xbox One S
controller in Bluetooth mode. Aside from changing the layout of
other buttons, this revision also changes the triggers to act as
Accelerator and Brake axes from the simulation controls page.
The Darwin sysjoystick code didn't previously map anything at these
axes, making it impossible to detect input on these two buttons.
This defaults to the internal SDL resampler, since that's the likely default
without a system-wide install of libsamplerate, but those that need more can
tweak this.
This currently favors libsamplerate over the fast path (quality over speed),
but I'm not sure that's the correct approach, as there may be surprising
changes in performance metrics depending on what packages are available on
a user's system. That being said, currently, the only thing with access to
SDL_AudioStream is an SDL audio device's thread, and it might be mostly idle
otherwise, so maybe this is generally good.
Turns out that iterating from 0 to channels-1 was a serious performance hit!
These cases now tend to match or beat the original audio resampler's speed!
This allows us to avoid an extra copy, allocate less memory and reduce cache
pressure. On the downside: we have to do a lot of tapdancing to resample the
buffer in reverse when the output is growing.
It's expensive and (hopefully) unnecessary. If this becomes an overflow
problem, we could multiply both values by 0.5f before adding them, but let's
see if we can get by without the extra multiplication first.
We never seem to overflow the source buffer now; this might have been a
leftover from a bug that was covered by Vitaly's fixes?
Removing this conditional makes the resampler 10-20% faster. Left an
assert in there for debug builds, in case this still happens.
white.magic
The logic which decides if a device enumerated via the direct input system in the function EnumJoysticksCallback in SDL_dinputjoystick.c is processed is discarding valid joystick devices due to the assumption that devices of the type DI8DEVTYPE_SUPPLEMENTAL are not valid devices.
This change was added with 2.0.4 with this commit http://hg.libsdl.org/SDL/rev/1b9d40126645 that is linked to this bug report https://bugzilla.libsdl.org/show_bug.cgi?id=2460 which indicates that in that case devices of the type DI8DEVTYPE_SUPPLEMENTAL were not desirable as they caused a singular device to emit multiple "device added" events.
Since then there appear to have been a few fixes to handle devices that fall into various other classes in the following two commits:
http://hg.libsdl.org/SDL/rev/10ffb4787d7a and http://hg.libsdl.org/SDL/rev/6a2bbac05728
Two devices I have reports of failing to be listed when the DI8DEVTYPE_SUPPLEMENTAL type is excluded are ECS Gametric Throttle and Thrustmaster MFD Cougar.
Sam Lantinga
I verified that the OUYA controller shows up as a single device with this change, so I've reverted the change to ignore supplemental devices, leaving framework in place to easily add devices that we want to ignore.
Removed some needless things ("len / sizeof (Uint8)"), and made sure the
int32 -> float code uses doubles to avoid working with large integer values
in a 32-bit float.
Mark Callow
The attached patch does the following for the X11 and Windows platforms, the only ones where SDL attempts to use context_create_es_profile:
- Adds SDL_HINT_OPENGL_ES_DRIVER by which the application can
say to use the OpenGL ES driver & EGL rather than the Open GL
driver. (For bug #2570)
- Adds code to {WIN,X11}_GL_InitExtensions to determine the maximum
OpenGL ES version supported by the OpenGL driver (for bug #3145)
- Modifies the test that determines whether to use the OpenGL
driver or the real OpenGL ES driver to take into account the
hint, the requested and supported ES version and whether ES 1.X
is being requested. (For bug #2570 & bug #3145)
- Enables the testgles2 test for __WINDOWS__ and __LINUX__ and adds
the test to the VisualC projects.
With the fix in place I have run testdraw2, testgl and testgles2 without any issues and have run my own apps that use OpenGL, OpenGL ES 3 and OpenGL ES 1.1.
Lukasz Biel
Tried to compile SDL2 using newest version of VS.
Got:
SDL_audiocvt.obj : error LNK2019: unresolved external symbol memcpy referenced in function SDL_ResampleCVT
1>E:\Users\dotPo\Lib\SDL\VisualC\x64\Release\SDL2.dll : fatal error LNK1120: 1 unresolved externals
whole compilation process: http://pastebin.com/eWDAvBce
Steps to reproduce:
clone http://hg.libsdl.org/SDL using tortoise hg,
open SDL\VisualC\SDL.sln,
when promted if should retarget solution click ok,
select release x64 build type,
Build/Build Solution
attempt 2, using Visual Studio cmake support:
open folder SDL\
select release x64 build type,
run CMake\Build CMakeLists.txt
build fails
When switched to debug build type, buils succeeds in both cases.
VS 2017 is still beta.
It causes audio pops if you're converting in chunks (and needs to
allocate/initialize/free on each convert). We'll either adjust this interface
when we break ABI for 2.1 to make this usable, or publish the SDL_AudioStream
API for those that want a streaming solution.
In the meantime, the "simple" resampler produces "good enough" audio without
pops and doesn't have to be initialized, so that'll do for now on the
SDL_AudioCVT interface.
K_NORMTAB, K_SHIFTTAB, K_ALTTAB, K_ALTSHIFTTAB
In the normal case we'll load all the keymaps from the kernel, but this reduces the size of the SDL library for the fallback case when we can't get to the tty.
Mark Logan 2015-08-24 15:57:50 UTC
In SDL_windowsopengles.c, WIN_GLES_SetSwapInterval is as follows:
WIN_GLES_SetSwapInterval(_THIS, int interval)
{
/* FIXME: This should call SDL_EGL_SetSwapInterval, but ANGLE has a bug that prevents this
* from working if we do (the window contents freeze and don't swap properly). So, we ignore
* the request for now.
*/
SDL_Log("WARNING: Ignoring SDL_GL_SetSwapInterval call due to ANGLE bug");
return 0;
}
With a recent version of ANGLE (early July) calling SDL_EGL_SetSwapInterval with a D3D11 backend appears to work just fine. I am working on testing this with D3D9.
--
Alex Szpakowski
I found the bug, it was fixed in 2013. https://bugs.chromium.org/p/angleproject/issues/detail?id=481
In my opinion it should be safe to unconditionally use SetSwapInterval now. Anyone who encounters the bug should update their ANGLE to a version less than 3 years old, especially since they'd be using a SDL version that's 3+ years newer than their ANGLE version.
Rob
I've ran into an issue where I successfully receive SDL_KEY[UP,DOWN] events but not SDL_TEXTINPUT or SDL_TEXTEDITING. In my case the code in SDL_EVDEV_do_text_input() is returning early (on error) prior to calling SDL_SendKeyboardText(). I'm running on the RaspberryPi 3, without X11.
In SDL_EVDEV_do_text_input() there is a condition to check keysyms with a type value below 0xf0, then subtract 0xf0 from type. Without understanding the purpose of this code, I disabled it, recompiled, and I'm getting correct SDL_TEXTINPUT events. I'm going to guess that my hack/fix is going to be problematic in some other environment, but after some initial testing it looks like everything is running fine in my setup.
Richard Russell
Resuming from a suspended state results in a black screen. This only happens when using GLES 1.1 (GLES 2 resumes correctly) and when the render target has been changed using SDL_SetRenderTarget. This problem is new in 2.0.4.
The attached test case demonstrates the issue.
Sylvain Becker has apparently found a fix as follows:
"In the opengles leaf function (in 'src/render/opengles/SDL_render_gles.c'), it appears there is a call to 'GLES_ActivateRenderer' in 'GLES_SetRenderTarget', which is not present in opengles2. When commenting out this 'GLES_ActivateRenderer', it seems to resume fine".
This appears to fix the testcase perfectly, but I don't know whether it could have any undesirable side-effects.
tvc
I believe this patch should fix it, instead of looping through all the tty's and seemingly selecting the wrong one and corrupting the console I've just made SDL open /dev/tty which is the console attached to the current process anyway.
felix
Here's a snippet of SDL_DestroyRenderer from hg revision 10746:7540ff5d0e0e:
SDL_Texture *texture = NULL;
SDL_Texture *nexttexture = NULL;
/* ... */
for (texture = renderer->textures; texture; texture = nexttexture) {
nexttexture = texture->next;
SDL_DestroyTexture(texture);
}
SDL_DestroyTexture removes the texture from the linked list pointed to by the renderer and ends up calling SDL_DestroyTextureInternal, which contains this:
if (texture->native) {
SDL_DestroyTexture(texture->native);
}
If it happens that texture->native is an alias of nexttexture two stack frames up, SDL_DestroyRenderer will end up trying to destroy an already freed texture. I've had this very situation happen in dosemu2.
Bug introduced in revision 10650:a8253d439914, which has a somewhat ironic description of "Fixed all known static analysis bugs"...
Rob
When calling ioctl(fd, KDGKBTYPE, &type) in SDL_EVDEV_is_console(), we declare type as an 'int'. This should be a 'char'. The subsequent syscall, and kernel code, only writes the lower byte of the word.
See: http://lxr.free-electrons.com/source/drivers/tty/vt/vt_ioctl.c?v=4.4#L399
ucval = KB_101;
ret = put_user(ucval, (char __user *)arg);
I've observed intermittent behavior related to this, and I can force an error condition by using an int initialized to 0xFFFFFFFF. The resulting ioctl will set type to 0XFFFFFF02, and the conditional return in SDL_EVDEV_is_console() will fail.
Recommend changing to char, or masking off unused bits.
There was a draft of this where it did audio conversion into the final buffer,
if there was enough room available past what you asked for, but that interface
got removed, so the parameters didn't make sense (and we were using the
wrong one in any case, too!).
For example, if sR is 0 and dR is 255, we will get -255*sA casted to an unsigned value. Basically results are quite large numbers instead of the expected 0-255 range.
Fixed a case where partial trigger pull could be bound to another button
There is a fundamental problem not resolved by this commit:
Some controllers have axes (triggers, pedals, etc.) that don't start at zero, but we're guaranteed that if we get a value that it's correct. For these controllers, the current code works, where we take the first value we get and use that as the zero point and generate axis motion starting from that point on.
Other controllers have digital axes (D-pad) that assume a zero starting point, and the first value we get is the min or max axis value when the D-pad is moved. For these controllers, the current code thinks that the zero point is the axis value after the D-pad motion and this doesn't work.
My hypothesis is that the first class of devices is more common and that we should solve for that, and add an exception to SDL_JoystickAxesCenteredAtZero() as needed for the second class of devices.
Ryan C. Gordon
Kristian says you can't do it with Wayland, and that going forward, it'll just handle whatever you throw at it anyhow.
https://twitter.com/hoegsberg/status/816148272402165761
So I say we mark it SDL_PIXELFORMAT_RGB888, which is what my X11 display currently reports, and leave it at that.
kaisyu
In case of OpenGLES, the sequences of loading and unloading driver library should be like that:
SDL_Init
...
SDL_GL_LoadLibrary
SDL_EGL_LoadLibrary
...
SDL_Quit
...
SDL_GL_UnloadLibrary
SDL_EGL_UnloadLibrary
...
However, according to my test results, the varible '_this->gl_config.driver_loaded' does not allow 'SDL_GL_UnloadLibrary' to call 'SDL_EGL_UnloadLibrary'.
Coriiander
This notice is about a misplaced comment.
Often times when we use an #if #endif sequence, the #endif is followed by a comment to indicate what #if statement it belonged to. The SDL_xaudio2.c file contains a misplaced comment, as follows (I stripped the other comments):
#ifdef __GNUC__
# define SDL_XAUDIO2_HAS_SDK 1
#elif defined(__WINRT__)
# define SDL_XAUDIO2_HAS_SDK
#include "SDL_xaudio2.h"
#else
#if 0
#include <dxsdkver.h>
#if (!defined(_DXSDK_BUILD_MAJOR) || (_DXSDK_BUILD_MAJOR < 1284))
# pragma message("Your DirectX SDK is too old. Disabling XAudio2 support.")
#else
# define SDL_XAUDIO2_HAS_SDK 1
#endif
#endif
#endif /* 0 */
That final /* 0 */ should be moved one line up. Like this (I tabbed it out for you to make it more clear):
Tristan
The internal SDL_vsnprintf implementation accesses memory outside buffer. The bug existed also inside the format (%) processing, which was fixed with Bug 3441.
But there is still an invalid access, if we do not have any format inside the source string and the destination string is shorter than the format string. You can use any string for this test, as long it is longer than the buffer.
Example:
va_list argList;
char buffer[4];
SDL_vsnprintf(buffer, sizeof(buffer), "Testing", argList);
The bug is located on the 'else' branch of the format char test:
while (*fmt) {
if (*fmt == '%') {
...
} else {
if (left > 1) {
*text = *fmt;
--left;
}
++fmt;
++text;
}
}
if (left > 0) {
*text = '\0';
}
As you can see that text is always incremented, even when left is already one. When then on the last lines, *text is assigned the NULL char, the pointer is located outside bounds.
Intellectual Kitty
In SDL_video.c, on line #1756, in SDL_SetWindowPosition (from today's distribution, 12-31-2016, https://hg.libsdl.org/SDL/shortlog/bf19e0c84483):
if (displayIndex > _this->num_displays) {
should be:
if (displayIndex >= _this->num_displays) {
felix
Compiling even a simple SDL2 'hello world' program with gcc -Wstrict-prototypes (GCC 6.2.1) results in warnings like:
/usr/include/SDL2/SDL_gamecontroller.h:143:1: attention : function declaration isn't a prototype [-Wstrict-prototypes]
extern DECLSPEC int SDLCALL SDL_GameControllerNumMappings();
^~~~~~
It seems there is a missing 'void' between the parentheses.
This was a leftover of simplifying the resamplers down from autogenerated
code; I forgot to make something that the generator hardcoded into something
variable.
Fixes Bugzilla #3507.
Ozkan Sezer
http://hg.libsdl.org/SDL/rev/464a2676d8ab seems to have
forgotten removing the return from SDL_dynapi_procs.h, and this patch
does that. Without it, MSVC warns:
c:\sdl2\src\dynapi\SDL_dynapi_procs.h(598) : warning C4098:
'SDL_GL_SwapWindow_DEFAULT' : 'void' function returning a value
c:\sdl2\src\dynapi\SDL_dynapi_procs.h(598) : warning C4098:
'SDL_GL_SwapWindow' : 'void' function returning a value
Ozkan Sezer
This adds the name 'ad' to two unnamed unions in edid.h
and adjusts edid-parse.c for it. Nameless unions are not supported in
ancient gcc, which I happened to use on one of my ancient setups.
These fixes are lumped into two categories:
1. add new file, SDL_dataqueue.c, to UWP/WinRT build-inputs (via MSVC project
files)
2. implement a temporary, hack-fix for a build error in SDL_xinputjoystick.c.
Win32's Raw Input APIs are, unfortunately, not available for use in UWP/WinRT
APIs. There does appear to be a replacement API, available in the
Windows.Devices.HumanInterfaceDevice namespace.
This fix should be sufficient to get SDL compiling again, without affecting
Win32 builds, however using the UWP/WinRT API (in UWP/WinRT builds) would
almost certainly be better (for UWP/WinRT builds).
TODO: research Windows.Devices.HumanInterfaceDevice, and use that if and as
appropriate.
Ciro Santilli
GCC 6, Ubuntu 16.10, cd test; ./configure; make
/bin/sh config.status Makefile
config.status: creating Makefile
gcc -o loopwave loopwave.c -g -O2 -D_REENTRANT -I/usr/include/SDL2 -DHAVE_OPENGLES2 -DHAVE_OPENGL -DHAVE_SDL_TTF -g -lSDL2_test -lSDL2
gcc -o testatomic testatomic.c -g -O2 -D_REENTRANT -I/usr/include/SDL2 -DHAVE_OPENGLES2 -DHAVE_OPENGL -DHAVE_SDL_TTF -g -lSDL2_test -lSDL2
In file included from /usr/include/SDL2/SDL_main.h:25:0,
from /usr/include/SDL2/SDL.h:32,
from testatomic.c:14:
/usr/include/SDL2/SDL_stdinc.h:261:20: error: variably modified ?SDL_dummy_size? at file scope
typedef int SDL_dummy_ ## name[(x) * 2 - 1]
^
testatomic.c:106:1: note: in expansion of macro ?SDL_COMPILE_TIME_ASSERT?
SDL_COMPILE_TIME_ASSERT(size, CountTo>0); /* check for rollover */
^~~~~~~~~~~~~~~~~~~~~~~
Makefile:114: recipe for target 'testatomic' failed
make: *** [testatomic] Error 1
If I remove the line SDL_COMPILE_TIME_ASSERT(size, CountTo>0); /* check for rollover */ it works, lazy to figure out the best way to do this.
This currently doesn't affect absolute motion, which would need to be implemented on each windowing system so the cursor matches the reported mouse coordinates.
Diego
I was previously unaware that rotating the device to a different orientation when the keyboard is shown causes a keyboardWillHide followed by a keyboardWillShow notification. The previous patch would then mistakenly StopTextInput when rotating. This patch fixes that by checking if the device is rotating before stopping text input.
Ozkan Sezer
With rev. 10651, i.e. http://hg.libsdl.org/SDL/rev/747a6a795b21 ,
SDL2 - OS X builds fail to run on 10.6 (my setup: i686 / 10.6.8)
because the symbol _IOPMAssertionCreateWithDescription is missing.
The SDK listing it for 10.7+ does seem correct. Reverting r10651
and rebuilding makes it to function again.
Simon Hug
The SDL_BlitScaled function runs into an access violation for specific blit coordinates and surface sizes. The attached testcase blits a 800x600 surface to a 1280x720 surface at the coordinates -640,-345 scaled to 1280x720. The blit function that moves the data then runs over and reads after the pixel data from the src surface causing an access violation.
I can't say where exactly it goes wrong, but I think it could have something to do with the rounding in SDL_UpperBlitScaled. final_src.y is 288 and final_src.h is 313. Together that's 601, which I believe is one too much, but I just don't know the code enough to make sure that's the problem.
Sylvain
I think this patch fix the issue, but maybe it's worth re-writing "SDL_UpperBlitScaled" using SDL_FRect.
The non-deprecated approach (IOPMAssertion) already exists in SDL, and is
available in Mac OS X 10.6 and later (although it was incorrectly listed as
10.7 and later in SDL). Since SDL now requires 10.6 or later, this is no
longer conditionally used.
realitix
SDL2 allows to create widow and to get information through SDL_SysWMinfo.
But it misses something, with Vulkan, you need the HWND and HINSTANCE of the window for Win32 system.
Sadly, SDL2 provides only HWND but not HINSTANCE.
In some context, it can be difficult to get the HINSTANCE, indeed, I'm using pySDL2 (Python) and I can only access properties that SDL2 gives me.
I have to use a dirty trick like that to get the HINSTANCE: (https://raw.githubusercontent.com/bglgwyng/pyVulkan/master/examples/win32misc.py)
felix
Building SDL 2.0.5, or even the Mercurial snapshot (r10608) with GCC 6.2.1 and --enable-video-directfb generates a number of compiler diagnostics and fails.
Simon Hug
The software renderer produces incorrect results when blending textures at an angle with certain blend modes. It seems that there were some edge cases that weren't considered when the SW_RenderCopyEx function was last changed. Or another bug possibly covered up the problem. (More on that in another bug report.)
Most of the issues come from the fact that the rotating function sets a black colorkey. This is problematic because black is most likely appearing in the surface and the final blit will ignore these pixels. Unless a colorkey is already set (the software renderer currently never sets one), it's very hard to find a free color. Of course it could scan over the whole image until one is found, but that seems inefficient.
The following blend modes have issues when drawn at an angle.
NONE: The black pixels get ignored, making them essentially transparent. This breaks the 'dstRGBA = srcRGBA' definition of the NONE blend mode.
MOD: Again, the black pixels get ignored. This also breaks the 'dstRGB = dstRGB * srcRGB' definition of the MOD blend mode, where black pixels would make the destination black as well. A white colorkey will work though, with some preparations.
BLEND: There are some issues when blending a texture with a translucent RGBA target texture. I - uh - forgot what the problem here exactly is.
This patch fixes the issues mentioned above. It mainly changes the code so it tries to do things without the colorkey and removes the automatic format conversion part from the SDLgfx_rotateSurface function. Getting the format right is something the caller has to do now and the required code has been added to the SW_RenderCopyEx function.
There's a small change to the SW_CreateTexture function. RLE encoding a surface with an alpha mask can be a lossy process. Depending on how the user uses the RGBA channels, this may be undesired. The change that surfaces with an alpha mask don't get encoded makes the software renderer consistent with the other renderers.
The SW_RenderCopyEx function now does these steps: Lock the source surface if necessary. Create a clone of the source by using the pixel buffer directly. Check the format and set a flag if a conversion is necessary. Check if scaling or cropping is necessary and set the flag for that as well. Check if color and alpha modulation has to be done before the rotate. Check if the source is an opaque surface. If not, it creates a mask surface that is necessary for the NONE blend mode. If any of the flags were set, a new surface is created and the source will be converted, scaled, cropped, and modulated. The rest of the function stays somewhat the same. The mask also needs to be rotated of course and then there is the NONE blend mode...
It's surprisingly hard to get the pixel from a rotated surface to the destination buffer without affecting the pixel outside the rotated area. I found a way to do this with three blits which is pretty hard on the performance. Perhaps someone has an idea how to do this faster?
As mentioned above, the SDLgfx_rotateSurface now only takes 8-bit paletted or 32-bit with alpha mask surfaces. It additionally sets the new surfaces up for the MOD blend mode.
I shortly tested the 8-bit path of SDLgfx_rotateSurface and it seemed to work so far. This path is not used by the software renderer anyway.
Vitaly Novichkov
Okay, when I researched code and algorithm, I tried to replace condition "while(dst >= target)" with "while(dst > target)" and crashes are gone.
Seems on some moments it tries to write into the place before memory block begin, therefore phantom crashes appearing after some moments.
Sylvain 2016-11-07 08:49:34 UTC
when rotated +90 or -90, some transparent lines appears, though there is no Alpha or ColorKey.
if you set a dummy colorkey, it will remove the line ...
if you set a some alpha mod, the +90/-90 get transparent but not the 0/180 ...
x414e54
It is a bit of a pain to update the library or rely on whatever version the user has on their computer for default mappings.
So providing an easily updatable text file via SDL_GameControllerAddMappingsFromFile is still currently the most viable way. However using this replaces all mappings provided by the SDL_HINT_GAMECONTROLLERCONFIG environment variable which may have come from the user's custom Steam mapping.
There should be an easy way for games to supply extra game controller mappings to fill in the differences between SDL versions without it clobbering the SDL_HINT_GAMECONTROLLERCONFIG environment variable.
Internally the mappings could use a priority system and if the priority is lower then it will not overwrite the mappings.
For now it just assumes SDL_HINT_GAMECONTROLLERCONFIG is the highest priority, the default hardcoded are the lowest and anything set via the API is medium.
Sam
I've discovered that when building on powerpc64le (and probably powerpc64) SDL's configure script fails to detect dynamic library support, causing it to build a static library. This causes link failures due to undefined symbols later when packages link with -lSDL.
This seems to be because the included autotools package is too old to detect powerpc64le. This change corrects the problem for me but newer versions of autotools should handle it without a patch
Mark Pizzolato
On Windows with Visual Studio, when building SDL as a static library using the x86 (32bit) mode, several intrinsic operations are implemented in code in SDL_stdlib.c.
One of these, _allshr() is not properly implemented and fails for some input. As a result, some operations on 64bit data elements (long long) don't always work.
I classified this bug as a blocker since things absolutely don't work when the affected code is invoked. The affected code is only invoked when SDL is compiled in x86 mode on Visual Studio when building a SDL as a static library. This build environment isn't common, and hence the bug hasn't been noticed previously.
I reopened#2537 and mentioned this problem and provided a fix. That fix is provided again here along with test code which could be added to some of the SDL test code. This test code verifies that the x86 intrinsic routines produce the same results as the native x64 instructions which these routines emulate under the Microsoft compiler. The point of the tests is to make sure that Visual Studio x86 code produces the same results as Visual Studio x64 code. Some of the arguments (or boundary conditions) may produce different results on other compiler environments, so the tests really shouldn't be run on all compilers. The test driver only actually exercised code when the compiler defines _MSC_VER, so the driver can generically be invoked without issue.
Ozkan Sezer
On systems with old glibc, such mine with glibc-2.8, the following warning
is issued and is fixed easily by defining _GNU_SOURCE:
/home/me/SDL2-2.0.5/src/video/x11/SDL_x11modes.c: In function 'CalculateXRandRRefreshRate':
/home/me/SDL2-2.0.5/src/video/x11/SDL_x11modes.c:263: warning: implicit declaration of function 'round'
/home/me/SDL2-2.0.5/src/video/x11/SDL_x11modes.c:263: warning: incompatible implicit declaration of built-in function 'round'
x414e54
I have implemented Drag and Drop and Clipboard support for Wayland.
Drag and dropping files from nautilus to the testdropfile application seems to work and also copy and paste.
This no longer uses a script to generate code for every possible type
conversion or resampler. This caused a bloat in binary size and and compile
times. Now we use a handful of more generic functions and assume staying in
the CPU cache is the most important thing anyhow.
This shrinks the size of the final build (in this case: macOS X amd64, -Os to
optimize for size) by 15%. When compiling on a single core, build times drop
by about 15% too (although the previous cost was largely hidden by multicore
builds).
Alex Baines
I realized overnight that my patch probably broke text input events with UIM, and I confirmed that it does. Can't believe I overlooked that... I've been making stupid mistakes in these patches recently, sorry.
Anyway, *this* one seems to fix it properly. Knowing my luck it probably breaks something else.
Patch uses XkbFreeKeyboard to free the memory returned by XkbGetMap.
Earlier implementation called XkbFreeClientMap which frees all the maps
but not data->xkb structure itself, XkbFreeKeyboard will free maps and
the structure.
Joshua Bodine
I'm going to reopen this because configure should still accurately report whether libudev will be used. Right now it just tests whether it's enabled as an argument, not whether configure was successful in finding it.
Kai Sterker
SDL2 on Haiku so far uses Haiku-specific APIs for loading dynamic objects as add-ons, instead of using dlopen to load them as libraries. This, for example, leads to SDL_mixer not being able to load its audio backends, when compiled with standard settings.
As discussed at https://www.freelists.org/post/haikuports/SDL2-mixer-ogg-music-not-playing-and-other-stuff,2 , the best way to deal with this would be using dlopen instead of load_add_on. The following patch implements this change by dropping the Haiku-specific bits and using dlopen instead.
/home/fedora/SDL2-2.0.5/src/video/SDL_blit_N.c: In function 'calc_swizzle32':
/home/fedora/SDL2-2.0.5/src/video/SDL_blit_N.c:127:5: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement]
const vector unsigned char plus = VECUINT8_LITERAL(0x00, 0x00, 0x00, 0x00,
^
D39 does not support negative viewport values which the current implementation relies on.
D3D11 does support negative viewport values so that will continue working.
Refer to Bug 2799.
Adam M.
When setting a texture alpha mod other than 255 and also specifying a flip mode in the software renderer, the rendering fails. When the texture has an alpha channel, it becomes invisible when flipped. When the texture does not have an alpha channel, it is flipped but the colors are wrong: the alpha mod makes the texture darker rather than more translucent.
0) Initialize a software renderer.
1) Load 16-bit 565 or 32-bit texture.
2) Set texture blend mode to BLEND.
3) Set texture alpha mod to 150.
4) Draw the texture flipped horizontally and/or vertically.
Adam M.
There are three problems in the code that I see.
1. SW_RenderCopyEx enables a color key on surface_scaled even if the source surface didn't have a color key.
2. SW_RenderCopyEx doesn't copy blend mode, color mod, or alpha mod from src to surface_scaled.
3. When SDL_BlitScaled(src, srcrect, surface_scaled, &tmp_rect) is called, it blends the src pixels into surface_scaled instead of overwriting them (if src has blending, etc. enabled).
I've attached a patch that 1) fixes the three problems that I mentioned, 2) adds the requested performance improvement of using the regular blit function if no rotation or flipping is needed, 3) avoids cloning the source surface if no stretching is required, and simplifies the rotation code slightly.
Adam M.
Okay, here is the problem, I think.
During the first blit, RLEAlphaSurface is called to do RLE conversion of the RGBA source into a format allowing it "to be quickly alpha-blittable onto dest". Since the destination is the screen, it has no alpha channel. RLEAlphaSurface calls copy_opaque(dst, src + runstart, len, sf, df) (where copy_opaque is copy_32), which has this code:
SDL_RLEaccel.c:984:
RGBA_FROM_8888(*src, sfmt, r, g, b, a);
PIXEL_FROM_RGBA(*d, dfmt, r, g, b, a);
On the first line, it reads the source pixel 0xFFFFFFFF. The second line drops the alpha value (because dfmt for the screen has no alpha channel) and writes 0x00FFFFFF. Later, when the RLE conversion is being undone, uncopy_32 is called, which has the following code:
SDL_RLEaccel.c:1001:
Uint32 pixel = *s++;
RGB_FROM_PIXEL(pixel, sfmt, r, g, b);
a = pixel >> 24;
PIXEL_FROM_RGBA(*dst, dfmt, r, g, b, a);
However, the the alpha channel has already been dropped by copy_opaque (= copy_32), so pixel = 0x00FFFFFF and 'a' becomes 0. Thus, all opaque pixels lose their alpha channel when being unRLE'd. (I don't know what happens to pixels with alpha from 1-254, but they should be checked too.)
So, that seems to be the problem, but I'm not sure what the solution should be. Since opaque pixels have alpha == 255, I'm thinking to create another uncopy function for opaque pixels that simply uses 255 for alpha.
However, there may be other problems here. For translucent pixels, uncopy_32 assumes the alpha channel is stored in the upper 8 bits, but copy_32 doesn't store it there. Instead, it stores it in whatever location is appropriate for the destination surface. Isn't one of their behaviors incorrect, given the other? I'm not sure which to change, however.
For translucent pixels, it seems that the blit function uses do_blend, which is the BLIT_TRANSL_888 macro, which also assumes alpha is in top 8 bits. It has the comment "we have made sure the alpha is stored in the top 8 bits...", but it seems that's not true (copy_32 doesn't make sure the alpha goes there).
Perhaps the correct fix is to make copy_32 put the alpha there, but then that seems to require that RLE conversion be limited to destination surfaces that don't use the upper 8 bits. However, looking further, it seems that has already been done: if (masksum != 0x00ffffff) return -1; /* requires unused high byte */
Sylvain
When using API 21 and running on an old device (android < 5.0 ?) some function are missing.
functions are (at least) : signal, sigemptyset, atof, stpcpy (strcat and strcpy), srand, rand.
Very few modifications on SDL to get this working :
on SDL
======
Undefine android configuration :
HAVE_SIGNAL
HAVE_SIGACTION
HAVE_ATOF
In "SDL_systrhead.c", comment out the few block of lines with "sigemptyset".
Android.mk:
remove the compilation of "test" directory because it contains a few rand/srand calls
Also, there are more discussions about this in internet :
https://groups.google.com/forum/#!topic/android-ndk/RjO9WmG9pfEhttp://stackoverflow.com/questions/25475055/android-ndk-load-library-cannot-locate-srand
Sylvain
http://developer.android.com/reference/android/view/InputDevice.html
int SOURCE_CLASS_JOYSTICK Constant Value: 16 (0x00000010)
int SOURCE_JOYSTICK Constant Value: 16777232 (0x01000010)
int SOURCE_KEYBOARD Constant Value: 257 (0x00000101)
int SOURCE_GAMEPAD Constant Value: 1025 (0x00000401)
int SOURCE_DPAD Constant Value: 513 (0x00000201)
I have an a PC keyboard that I connect to an android device.
The issue is that "arrow" keys gets lost.
More explanation:
This device gets detected twice by the java "pollInputDevices()" both as SOURCE_KEYBOARD and as a composite (0x1000311 == SOURCE_JOYSTICK | SOURCE_KEYBOARD | SOURCE_DPAD).
Because of being a SOURCE_CLASS_JOYSTICK, only the second entry is registered, and I opened it.
When I press one arrow key, the java method "onKey(...)" is called.
The Source "event.getSource()" is "SOURCE_KEYBOARD", so it enters this conditions :
if ( (event.getSource() & InputDevice.SOURCE_GAMEPAD) != 0 ||
(event.getSource() & InputDevice.SOURCE_DPAD) != 0 ) {
And then, it enters :
SDLActivity.onNativePadDown() (native code in "SDL_sysjoystick.c")
Since the "arrows" are viewed as "D-PAD", it gets translated :
int button = keycode_to_SDL(keycode);
But the android-java "event.getDeviceId()" is wrong: this is the one from the Keyboard, and not the one from the Joystick that I have opened.
So I don't get them through the Joystick interface.
And since, the keycode has been translated, it returns 0 and assume it was consumed.
So I lost the key in the function "Android_OnPadDown()"
Notice, It won't happen with other normal "letters" keys because they does not get translated by "keycode_to_SDL", so "Android_OnPadDown()" returns -1.
And then java code send the keys to "SDLActivity.onNativeKeyDown()".
Possible patch on "Android_OnPadDown" and also "Android_OnPadUp" (and maybe other functons):
85 int
186 Android_OnPadDown(int device_id, int keycode)
187 {
188 SDL_joylist_item *item;
189 int button = keycode_to_SDL(keycode);
190 if (button >= 0) {
191 item = JoystickByDeviceId(device_id);
192 if (item && item->joystick) {
193 SDL_PrivateJoystickButton(item->joystick, button , SDL_PRESSED);
194 }
+ else return -1;
195 return 0;
196 }
197
198 return -1;
199 }
It would allow the java caller function to send the key to "SDLActivity.onNativeKeyDown();"
Another solution, would be to replace:
if ( (event.getSource() & InputDevice.SOURCE_GAMEPAD) != 0 ||
(event.getSource() & InputDevice.SOURCE_DPAD) != 0 ) {
by
if ( (event.getSource() & InputDevice.SOURCE_CLASS_JOYSTICK) != 0)
Because only "SOURCE_CLASS_JOYSTICK" devices are registered/opened.
Sylvain
I have an android device to which I try to connect the google virtual remote application.
https://play.google.com/store/apps/details?id=com.google.android.tv.remote
The java method "pollInputDevices()" detects it as an input source 0x701 which is (SOURCE_KEYBOARD | SOURCE_GAMEPAD | SOURCE_DPAD).
It it not added because it does not AND-bitwise with "SOURCE_CLASS_JOYSTICK".
It's only a virtual DPAD and it works when checking also with SOURCE_CLASS_BUTTON
Sylvain
With a Landscape application.
Going to background with Home Key, then foreground.
The screen is distorted.
This has been reported by Samsung. It happens on S5 and Samsung Alpha, see the video attached.
I have captured the following logcat:
V/SDL (20549): onResume()
V/SDL (20549): surfaceCreated()
V/SDL (20549): surfaceChanged()
V/SDL (20549): pixel format RGB_565
V/SDL (20549): Window size:1920x1080
I/SDL (20549): SDL_Android_Init()
I/SDL (20549): SDL_Android_Init() finished!
V/SDL (20549): SDL audio: opening device
V/SDL (20549): SDL audio: wanted stereo 16-bit 22.05kHz, 256 frames buffer
V/SDL (20549): SDL audio: got stereo 16-bit 22.05kHz, 1764 frames buffer
V/SDL (20549): onWindowFocusChanged(): true
V/SDL (20549): onWindowFocusChanged(): false
V/SDL (20549): onPause()
V/SDL (20549): nativePause()
V/SDL (20549): surfaceDestroyed()
Background / Foreground
V/SDL (20549): onResume()
V/SDL (20549): surfaceCreated()
V/SDL (20549): surfaceChanged()
V/SDL (20549): pixel format RGB_565
V/SDL (20549): Window size:1080x1920
V/SDL (20549): surfaceChanged()
V/SDL (20549): pixel format RGB_565
V/SDL (20549): Window size:1920x1080
V/SDL (20549): onWindowFocusChanged(): true
V/SDL (20549): nativeResume()
This seems to be related to the fact that I have in "AndroidManifest.xml":
android:configChanges="..."
Because of the fields: "orientation" and also "screenSize".
I have looked for another way to solve the issue. Discarding the "surfaceChanged" call, based on the "requestedOrientation" and the new Orientation. It seems to be better.
On my failing test case, the first "surfaceChanged()" is discarded. Sometimes the "focusChanged()" might appear between the two "surfaceChanged()", while the surface is not yet ready. Thus, discarding also the "nativeResume()".
So, for robustness, a call to "nativeResume()" is added at the end of "surfaceChanged()".
Some update:
1/ First I tried, to discard the surface using the current orientation (rather than width / heigh). -> that solve the issue sometimes, but not always.
2/ Samsung Certification now accepts my application that were previously failing.
3/ I personally now owns a Samsung S5, and was able to solve the issue on my side.
4/ I now use the patch and get no complaints from my users. (but I admit, nobody seemed to be complaining before neither...).
5/ I have added a v2 because of a new smart-phone called "Black Berry Passport" that has a square screen of 1440x1440. This screen has a "status bar" so the resolution is in fact : 1440x1308. (as reported by "surfaceChanged").
Problem is: the portrait resolution is in fact a Landscape!
So the "v1" patch is always discarding the "surface" of BlackBerry Passport. Which is terribly bad.
Hence, I added the "v2" patch not to discard the surface when aspect ratio is < 1.20. (BB 1440/1308 is : 1.1009). Which seems fair.
Martin Gerhardy
Not sure - but I think there might be a logic flaw in SDL_SetWindowGrab.
The problem here is that this modifies the window flags and e.g. sets
SDL_WINDOW_INPUT_GRABBED - but the _this->grabbed_window pointer is not
yet set.
Then in SDL_UpdateWindowGrab the _this->grabbed_window pointer is only
set if the function pointer _this->SetWindowGrab is not NULL. But if
this is NULL, the _this->grabbed_window pointer is never set, but every
future call to any of the grab functions include an assert for:
SDL_assert(!_this->grabbed_window || ((_this->grabbed_window->flags &
SDL_WINDOW_INPUT_GRABBED) != 0));
That means the first call works, the second always fails and triggers
the assert.
Magnus Bjerke Vik
This causes issues when for instance using the joystick API to make an Android phone rotate an object by rotating the phone. When the absolute value of an axis reported by android is larger than earth gravity, SDL will overflow the Sint16 value used for joystick axes, causing sporadic movements when close to the gravity. Just holding the phone so that e.g. Y points directly upwards will make it unstable, and even more if you just tap the phone gently from below (increasing the acceleration).
More detailed: SDLActivity gets the accelerometer values in onSensorChanged and divides each axis by earth gravity. SDL_SYS_JoystickUpdate takes each of the axis values, multiplies them by 32767.0 (largest Sint16), and the casts them to Sint16. From this you can see that any value from Android that exceeds earth gravity will overflow the joystick axis.
A fix is to clamp the values so that they won't overflow the Sint16.
Simon Deschenes
My build system still shows warning as errors.
The first warning says that the member named instances can never be false (or NULL) as it is a static array, and we should check for instances[index] which we do anyway.
Ozkan Sezer
pthread/SDL_syssem.c requires _GNU_SOURCE predefined (like SDL_sysmutex.c),
otherwise sem_timedwait() prototype might not be available to it. Problem
seen with glibc-2.3.4.
If the allocation of an SDL_Touch failed, the number of touch devices was still
increased. Later access of the SDL_Touch would then have dereferenced the NULL.
Joe Thompson
This is a regression. The changes to fix#2460 cause the EnumJoysticksCallback() function to return without adding devices (Line 345 in SDL-0a2b6bc7005f\src\joystick\windows\SDL_dinputjoystick.c).
Looking at dinput.h on my system, at least DI8DEVTYPE_DRIVING and DI8DEVTYPE_FLIGHT need to be added to the test.
It might be better to check if (devtype == DI8DEVTYPE_SUPPLEMENTAL) rather than checking if it is NOT EQUAL to a long list of types. Or check if the device is already in the list.
This happens when the pointer is grabbed, but it's not clear if this is a
bug in x.org or my misunderstanding of the XGrabPointer() documentation.
At any rate, we'll want to revisit this later for a better solution.
Fixes Bugzilla #2963.
Make note to send it, and send next time we SDL_PumpEvents().
Otherwise, we might be trying to use malloc() to push a new event on the
queue while a signal is interrupting malloc() elsewhere, usually causing a
crash.
Fixes Bugzilla #2870.
This was the only thing that made SDL_config.h generate differently between
32 and 64-bit versions of Linux, so instead we force a function cast in our
X11 code to match our dynamic loader version, which removes the compile error
on some machines that prompted this test in the first place.
Xlib never wrote to this data, so if you're on an older Xlib where this param
wasn't const, your data should still be intact when we force the caller to
think it was actually const after all.
Fixes Bugzilla #1893.
Fixes Bugzilla #2895.
His notes:
The following trivial changes make SDL2 tree (mostly) compatible with Visual
Studio 2005:
* SDL_stdlib.c: Similar to VS2010 and newer, VS2005 also generates memcpy(),
(it also generates memset(), see below), so propagate the #if condition to
cover VS2005.
* SDL_pixels.c (SDL_CalculateGammaRamp): VS2005 generates a memset() call for
gamma==0 case, so replace the if loop with SDL_memset().
* SDL_windowsvideo.h: Include msctf.h only with VS2008 and newer, otherwise
include SDL_msctf.h
* SDL_windowskeyboard.c: Adjust the #ifdefs so that SDL_msctf.h inclusion is
always recognized correctly.
Fixes Google Chrome, etc, freezing up when SDL owns the clipboard selection
and actually sends thems the correct text for pasting. Confirmed working with
Unicode strings in UTF-8 format.
There were a few tweaks in this patch, but the specific fix is that
event.xselection.target in the SelectionNotify event we send back in reply
must be set to the same atom as the request ("TARGETS" in this case), and
we failed to do that in this special case. Things that don't ask for a target,
like the Gnome Terminal app, worked fine because they don't ask for TARGETS
and just go right to asking for a UTF8_STRING, and Mozilla apparently just
was more liberal in what they accepted in reply.
Chrome would reject our wrong reply and freeze up waiting for a valid one.
Someone should fix that in Chrome, too. :)
Fixes Bugzilla #2926.
Roberto
I have debugged the code checking the function calls when Direct3D is the renderer, remember that with software and OpenGL renderers, this issue is not happening.
- Create the texture:
SDL_Texture *pTex = SDL_CreateTexture(pRenderer, iFormat, SDL_TEXTUREACCESS_TARGET, pSurf->w, pSurf->h);
- Update the texture:
SDL_UpdateTexture(pTex, NULL, pSurf->pixels, pSurf->pitch);
SDL_render.c, SDL_UpdateTexture(): return renderer->UpdateTexture(renderer, texture, rect, pixels, pitch);
SDL_render_d3d.c, D3D_UpdateTexture(): if (D3D_UpdateTextureRep(data->device, &texturedata->texture, texture->format, rect->x, rect->y, rect->w, rect->h, pixels, pitch) < 0) {
SDL_render_d3d.c, D3D_UpdateTextureRep(): if (D3D_CreateStagingTexture(device, texture) < 0) {
SDL_render_d3d.c, D3D_CreateStagingTexture(): result = IDirect3DDevice9_CreateTexture(..., D3DPOOL_SYSTEMMEM, ...) --> FAIL! with INVALIDCALL code
After checking a bit the Microsoft documentation, I found this:
D3DUSAGE_RENDERTARGET can only be used with D3DPOOL_DEFAULT. (https://msdn.microsoft.com/en-us/library/windows/desktop/bb172625%28v=vs.85%29.aspx)
The call that fails, is using D3DUSAGE_RENDERTARGET with D3DPOOL_SYSTEMMEM which is unsupported, hence the INVALIDCALL return code.
The window needs to catch ClientMessage events for one specific window, but
XNextEvent() catches everything, and XWindowEvent doesn't catch ClientMessage,
so we need predicate procedure and XIfEvent() here.
Fixes Bugzilla #2980.
Otherwise, SDL_PIXELFORMAT_BGR24 is reported as having alpha, because
its SDL_ARRAYORDER_BGR pixel order uses the same integer value as
SDL_PACKEDORDER_RGBA, since we weren't checking the pixel type to
differentiate.
Fixes Bugzilla #2977.
These events accidentally slipping in sometimes appears to be a bug (or
maybe new behavior) in 10.10, as previous versions of Mac OS X don't appear
to ever trigger this.
Thanks to Paulo Marques for pointing out the fix on the SDL mailing list!
Fixes Bugzilla #2842 (again).
Zack Middleton
The change to the keymap to use SDL_SCANCODE_TO_KEYCODE in SDL_x11keyboard.c causes all SDL scancodes without a Usc4 character to be XOR'd with SDLK_SCANCODE_MASK, but not all key code are suppose to be (as seen in include/SDL_keycodes.h). SDLK_BACKSPACE is not 0x4000002A.
I think the full list of keys affected are return, escape, backspace, tab, and delete.
Volumetric
The "Unknown touch device" message appears because the initial touch device setup loop uses SDL_GetTouch() as a guard for calling SDL_AddTouch(). SDL_GetTouch() will always report "Unknown touch device" since the device hasn't been added yet. The SDL_GetTouch() call is unnecessary since SDL_AddTouch() calls SDL_GetTouchIndex() to verify that the device hasn't been added yet, and SDL_GetTouchIndex() has the benefit of not reporting an error for a device it can't find.
Jacob Lee
If a user has a non-standard keyboard mapping -- say, their caps lock key has been mapped to Ctrl -- then SDL_GetModState() is no longer accurate: it only considers the unmapped keys. This is a regression from SDL 1.2.
I think there are two parts to this bug: first, GetModState should use keycodes, rather than scancodes, which is easy enough.
Unfortunately, on my system, SDL considers Caps Lock, even when mapped as Control, to be both SDL_SCANCODE_CAPSLOCK and SDLK_CAPSLOCK. The output from checkkeys for it is:
INFO: Key pressed : scancode 57 = CapsLock, keycode 0x40000039 = CapsLock modifiers: CAPS
Whereas the output for xev is:
KeyPress event, serial 41, synthetic NO, window 0x4a00001,
root 0x9a, subw 0x0, time 40218333, (144,177), root:(1458,222),
state 0x10, keycode 66 (keysym 0xffe3, Control_L), same_screen YES,
XKeysymToKeycode returns keycode: 37
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
I think the problem is that X11_UpdateKeymap in SDL_x11keyboard.c only builds a mapping for keycodes associated with a Unicode character (anything where X11_KeyCodeToUcs returns a value). In the case of caps lock, SDL scancode 57 becomes x11 keycode 66, which becomes x11 keysym 65507(Control_L), which does not have a unicode value.
To fix this, I suspect that SDL needs a mapping of the rest of the x11 keysyms to their corresponding SDL key codes.
hiduei
Overview:
Initializing the Video Subsystem causes many errors though everything works as it should.
Steps to Reproduce:
1) Set Loglevel to SDL_LOG_PRIORITY_ERROR
2) Initialize the Video Subsystem (SDL_Init(SDL_INIT_VIDEO))
Actual Results:
Many errors (see attachment) are printed on stderr, then the application continues as expected.
Expected Results:
The errors should have been warnings at most.
Andreas Ragnerstam
I have two windows where one has a renderer where the logical size has been changed with SDL_RenderSetLogicalSize. When I get SDL_MOUSEMOTION events belonging to the non-scaled window these will have been scaled with the factor of the scaled window, which is not expected.
Adding some printf debugging to SDL_RendererEventWatch of SDL_render.c, where (event->type == SDL_MOUSEMOTION), I found that for every mouse motion SDL_RendererEventWatch is called twice and the event->motion.x and event.motion.y are set twice for the event, once for each renderer where only the last one set will be saved to the event struct. This will work fine if both renderers have the same scale, but otherwise the motion coordinates will be scaled for the renderer belonging to another window than the mouse was moved in.
I guess one solution would be to check that window == renderer->window for SDL_MOUSEMOTION events, similar to what is done for when SDL_WINDOWEVENT events.
I get the same error on both X11 and Windows.
The same problem also exists for SDL_MOUSEBUTTONDOWN and SDL_MOUSEBUTTONUP events.
Apparently you might get strange paths from GetModuleFileName(), such as
short path names or UNC filenames, so this avoids that problem. Since you have
to tapdance with linking different libraries and defining macros depending on
what Windows you plan to target, we dynamically load the API we need, which
works on all versions of Windows (on Win7, it'll load a compatibility wrapper
for the newer API location).
What a mess.
This also now does the right thing if there isn't enough space to store the
path, looping with a larger allocated buffer each try.
Fixes Bugzilla #2435.
Jason Wyatt
Currently the keymapnotify event handling is commented out as FIXME in SDL_x11events.c (It looks like this may have functioned SDL1.2).
Not handling this event means that if a window manager shortcut such as ALT+SPACE is used, SDL will send an ALT key down signal, but not an up signal. Also querying SDL about the key state, it believes the ALT key remains pressed.
X passes the events keypress (alt), ?focusout?, ?focusin?, keymapnotify.
If SDL_SaveBMP_RW() was called with NULL passed as SDL_RWops argument, different
values were returned depending on SDL_GetError(). If no error was set before the
call (or SDL_ClearError() was called) then 0 was returned. This is wrong because
nothing was saved. If an error was set before the call then -1 was returned.
This was fixed by directly returning -1 for NULL input instead of deciding based
on SDL_GetError(). No new error is set because this would otherwise override a
maybe more useful error set in SDL_RWFromFile() which is used by SDL_SaveBMP().
Fixes Bugzilla #2798.
Fixes Bugzilla #2212.
Fixes Bugzilla #2826.
Fixes Bugzilla #2661.
Fixes Bugzilla #1885.
Fixes Bugzilla #1578.
Fixes Bugzilla #2751.
(whew!)
Notable changes, from Alex's notes:
- The SDL_WINDOW_ALLOW_HIGHDPI flag is now needed (along with SDL_GL_GetDrawableSize or SDL_GetRendererOutputSize) to use Retina / high DPI resolutions, bringing SDL?s Retina-related behavior on iOS in line with Mac OS X. Window dimensions and display modes are now in the ?points? (non-high DPI) coordinate system rather than pixels, whereas SDL_GL_GetDrawableSize is in pixels.
- Reworked the custom extended launch screen code:
- It now hides after the first SDL_PumpEvents call rather than SDL_CreateWindow, and it fades out in a similar manner to the system launch screen behavior.
- It now mirrors the system launch screen behavior when deciding which image to display: it falls back to using the Launch Images dictionary in Info.plist if the iOS 8+ launch screen nib isn?t available, and if the Launch Images dictionary doesn?t exist it uses the old standard launch image names.
- The extended launch screen can now be disabled via the SDL_IPHONE_LAUNCHSCREEN define in SDL_config_iphoneos.h.
- Added support for SDL_HINT_ACCELEROMETER_AS_JOYSTICK.
- Added access to a window view's renderbuffer and framebuffer to syswm.
- Added OpenGL ES debug labels for the Renderbuffer and Framebuffer Objects created with SDL_GL_CreateContext.
- Added support for sRGB OpenGL ES contexts on iOS 7+.
- Updated OpenGL ES contexts to support native-resolution rendering (when SDL_WINDOW_ALLOW_HIGHDPI is enabled) on the iPhone 6 Plus, i.e. 1080x1920 rather than 1242x2208.
- Updated SDL_GL_CreateContext, SDL_GL_SwapWindow, SDL_GL_MakeCurrent, and SDL_GL_DeleteContext to be more robust.
- Updated SDL windows to display a UIView at all times, even when an OpenGL context is not active. This allows rotation, touch events, and other windowing-related events to work properly without an active OpenGL context. It also makes it easier to use SDL_GetWindowWMInfo after creating a SDL window.
- Updated the iOS-specific Objective-C code to use cleaner and more modern language features and APIs, including ARC instead of manual reference counting.
- Updated SDL_HINT_ORIENTATIONS to allow disabling custom orientations if the hint is set with no valid orientation names.
- Fixed several rotation and orientation bugs with windows and display modes, especially in iOS 8+.
- Fixed SDL_SetWindowFullscreen failing to update the status bar visibility on iOS 7+.
- Fixed the orientation of the offset applied to the window?s view when the onscreen keyboard is shown in iOS 8+.
- Fixed SDL_IsScreenKeyboardShown (patch by Phil Hassey.)
- Fixed several major memory leaks caused by missing autorelease pool blocks in the iOS-specific Objective-C code.
- Removed several dead code paths.
- The iOS 7 SDK (Xcode 5) or newer is now required to build SDL for iOS.
This avoids a hint lookup for each mouse event we get by setting a static Java
variable from native code during our hint watcher callback.
Also attempts to do the right thing with mouse buttons if you happen to be
on an API14 (Ice Cream Sandwich, Android 4.0) or later device. We still
target API12 (Honeycomb MR1, Android 3.1) for SDL 2.0.4 though.
This isn't tested, so I'm pushing to see what the Android buildbot says. Stand
back, I'm a professional!
Clarify that grabbing the mouse only works with one window at a time; this was
always true at the system level, though SDL could previously get confused
by multiple simultaneous grabs, so now we explicitly break any existing
grab before starting a new one and document it as such.
Also track the window that is currently grabbed, and provide an API to query
for that window. This makes it easy to automate mouse ungrabbing at
breakpoints with gdb7's scripting, since the scripts can now know which window
to ungrab.
In 2.1, we should probably change this API to SDL_GrabInput(win) and
SDL_UngrabInput(void), or something.
We continued looping while maxlen > 0, but maxlen was unsigned, so an overflow
would make it a large number instead of negative. Fixed.
Some snprintf() implementations might return a negative value if there isn't
enough space, and we now check for that.
Don't overrun the SDL error message buffer, if snprintf() returned the number
of chars it wanted to write instead of the number it did.
snprintf is a portability mess, we should just never use the C runtime for it.
Fixes Bugzilla #2049.
This extension allows the user to specify whether a full flush is performed when making a context not current.
The only way to set this currently is at context creation, so this patch provides that functionality.
Defualt behaviour is set at FLUSH, as per the spec.
This patch does not contain the changes to WGL, appleGL or other platforms as I do not have access to GL 4.5 hardware on those platforms.
Full details on the use of KHR_context_flush_control can be found here:
https://www.opengl.org/registry/specs/KHR/context_flush_control.txt
The data produced by the callback is just thrown away and the audio thread
delays as if it's waiting for the hardware to drain.
This lets apps that rely on their audio callback firing regularly continue
to make progress to function as properly as possible in the face of disaster.
Apps that want to know that the device is really gone and deal with that
scenario can use the new hotplug functionality.
Device enumeration now happens at startup and then is managed exclusively
through hotplugging instead of full redetection. The device name list now has
a unique "handle" associated with each item and SDL will pass this to the
backend so they don't have to figure out how a human readable name maps to
real hardware for a second time.
Other cleanups, fixes, improvements, plus all the audio backends updated to
the new interface...largely untested at this point, though.
This fills in the core pieces and fully implements it for Mac OS X.
Most other platforms, at the moment, will report a disconnected device if
it fails to write audio, but don't notice if the system's device list changed
at all.
Various constants in ANGLE/WinRT, both in MSOpenTech's ms-master branch, and
in Google's branch, were changed again. This change makes SDL/WinRT work with
them.
To note, the ms-master branch (of ANGLE) was updated via this merge:
bbd2eb0a9c (diff-d1377fbe747de154e1bfcf7221d3de67)
If the function WIN_ConvertUTF32toUTF8() failed (should currently not be
possible) a not terminated string would have been sent as text input event.
This also fixed converting characters more often than needed on key repetition.
If the function Emscripten_ConvertUTF32toUTF8() failed (should currently not be
possible) a not terminated string would have been sent as text input event.
The key event callbacks were always removed from the same target although it is
possible to set them to different targets using the hint. This is only a partial
fix because it assumes that the hint is not changed to a different value later.
64-bit Linux uses a "long" instead of "long long" for 64-bit ints.
Added a special-case this so SDL_PRI?64 doesn't trigger compiler warnings
when used with SDL's 64-bit datatypes on 64-bit Linux.
- fix crash on OSX when removing a device. If the remove happened due to the CFRunLoopRunInMode call in SDL_SYS_JoystickDetect then we would delete the device right away, before SDL_SYS_JoystickUpdate could clean it up. So move the CFRunLoopRunInMode to after the cleanup logic, preventing this case. This does mean that adds and removes of joysticks now take 1 extra frame to show up.
After disconnecting a joystick the remaining kept their original device index.
This was not correct because the device index must be a number between 0 and
SDL_NumJoysticks(). It was fixed with ideas from SDL's joystick implementation
for Android. Some range checks were removed as the caller already checks them.
SDL_SYS_JoystickUpdate() was implemented incorrectly. For every call to it all
attached joysticks were checked. But actually only the given SDL_Joystick should
be checked then. This allowed sending broken events for attached but not opened
joysticks. It also checked the opened joysticks more often than actually needed.
This allows for this kind of code in an application:
int monitorID = 1; // the second monitor!
SDL_SetWindowPosition(sdlWin,
SDL_WINDOWPOS_CENTERED_DISPLAY(monitorID),
SDL_WINDOWPOS_CENTERED_DISPLAY(monitorID));
Fixes Bugzilla #2849.
Yes this seems confusing as on mac+linux Long is either 32 or 64bits depending on the architecture, but this is how the X11 protocol is defined. Thus 5 is the correct value for the nelts here. Not 5 or 10 depending on the architecture.
More info on the confusion https://bugs.freedesktop.org/show_bug.cgi?id=16802
"MACOSX_COREAUDIO" is actually an internal #define set up elsewhere, and
this CMake var is never exported past the CMake script anyhow.
Partially fixes Bugzilla #2807.
- Added new custom launch screen code. It uses the launch screen nib when available on iOS 8+, the launch images dictionary if the launch screen nib isn't available, and the old standard image names if the launch image dictionary isn't in the plist.
The launch screen is now hidden during the first call to SDL_PumpEvents rather than SDL_CreateWindow so apps can have the launch screen still visible if they do time-consuming loading after creating their window. It also fades out in roughly the same way as the system launch screen behavior.
It can be disabled by setting the SDL_IPHONE_LAUNCHSCREEN define in SDL_config_iphoneos.h to 0.
- A blank UIView is now created and displayed when the window is first created. The old behavior was to defer creating any view until SDL_GL_CreateContext, which prevented rotation, touch events, and other windowing-related things from working until then. This also makes it easier to use SDL_GetWindowWMInfo after creating a window.
- Moved the keyboard and animation callback code from SDL's UIView subclasses to its UIViewController subclass, which lets them work properly in all cases when a SDL window is valid, even before SDL_GL_CreateContext is called and after SDL_GL_DeleteContext is called.
- SDL_GL_CreateContext, SDL_GL_SwapWindow, SDL_GL_MakeCurrent, and SDL_GL_DeleteContext are more robust.
- Fixed some edge cases where SDL windows weren't rotating properly or their reported sizes were out of sync with their actual sizes.
- Removed all calls to [UIApplication setStatusBarOrientation:]. It doesn't seem to work as expected in all cases in recent iOS versions.
- Some code style cleanup.
The callbacks used to receive the HTML events were not removed if the joystick
subsystem initialization failed or if the joystick subsystem was quit. Also, the
already connected joysticks were not deleted if the initialization failed later.
The needed header files are already included with SDL.h. Still including them in
the test programs is confusing because it somehow suggests they would be needed.
It's slightly faster than failing later, after a strchr() call, since this
will get called multiple times with a NULL string if the system totally
fails elsewhere.
This change integrates initialization settings for ANGLE/WinRT, as suggested in
MSOpenTech's latest ANGLE template-projects (for MSVC).
This should fix some OpenGL initialization issues on WinPhone 8.1 on ARM, and
on the 1st-generation Surface RT.
SDL_JOYDEVICEADDED events must contain the device index which is a value between
0 and the number of connected joysticks. The old implementation included a value
based on the instance id instead. It worked in some cases because the values are
similar initially. But after disconnecting joysticks this is no more the case
and the always increasing instance id becomes larger than number of joysticks.
Exit was broken since the main loop extraction needed for Emscripten support
because the former local but now global variables were not reset correctly.
Windows Phone does not appear to allow VSync to be turned off. Doing so appears
to either result in content not getting drawn (when the D3D debug runtime is
turned off), or forcing VSync back on and logging an error (when the D3D debug
runtime is turned on).
VSync had been getting turned on anyways, this change just notes such:
- via the WinRT README
- by always setting the SDL_RENDERER_PRESENTVSYNC flag when creating an
SDL_Renderer on Windows Phone
Eric Wasylishen
Here's a patch to make the 'testrelative' demo program more useful: it just makes the orange rectangle wrap around. Previously, the orange cursor would just disappear off screen if you move the mouse a lot in one direction, so it was hard to tell if relative mouse mode was still working.
- Don't create a temporary context first; this was probably due to Windows
needing one to get the address of wglCreateContextAttribsARB(), but that's
a unique quirk of WGL, and doesn't apply to glX. The glX spec explicitly says
you have to get a function pointer that works with any context from
glXGetProcAddress(), including when no context exists.
- Properly check for the GLX_ARB_create_context instead of just looking for a
non-NULL glXCreateContextAttribsARB()...some implementations, like Mesa,
never return NULL for function lookups (Mesa returns pointers into a jump
table that is filled out when the GL is initialized; since you can look up
functions before you have a valid context, it can't definitely say a function
isn't valid at that point).
Normally there's a 200 millisecond delay on all focus events in case there
was a vidmode change, now we note the last vidmode change and only impose this
delay if a change happened extremely recently.
Thanks to Epic Games for reporting this issue.
Jonas Kulla
The configure script didn't differentiate between Linux and Android, unconditionally compiling in the unix implementation of SDL_sysfilesystem.c.
I'm probably one of the very few people building SDL for android using classic configure + standalone toolchain, so this has gone undetected all along.
This is a little macro magic to use malloc() directly instead of SDL_malloc(),
etc, so static analysis tests that know about the C runtime can function
properly, and understand that we are dealing with heap allocations, etc.
This changed our static analysis report from 5 outstanding bugs to 30.
5x as many bugs were hidden by SDL_malloc() not being recognized as malloc()
by the static analyzer!
SDL_WinRTRunApp() is used on WinRT to launch a main(int, char **)-style
function. It has optional, and experimental support for launching content
inside a XAML control, backed by a main() function running on a separate thread.
This is provided via it's 2nd parameter, which can be a pointer to a XAML
control. (If NULL, XAML support will not be used.)
This change renames the experimental feature's parameter (to SDL_WinRTRunApp())
as "reserved", until such time as the functionality is ready for use. It will
likely be renamed again in the future, when running SDL on top of a XAML control
via a separate thread, becomes reasonably usable.
This is a Win32-specific fix for bug 2726. A WinRT fix for this bug was applied
separately, via https://hg.libsdl.org/SDL/rev/91f56dcad879
This fix applies SDL_TOUCH_MOUSEID to 'mouse' events coming from touch devices,
but only when relative-mouse-mode is turned OFF. This bug is still present
when relative-mouse-mode is ON, however Microsoft does not provide documentation
on whether or not those input events (which come from WM_INPUT) can be
identified as touch-specific or not. Unofficially, that data might be available
(via GetMessageExtraInfo()), however this patch only uses MS-documented APIs.
Zack Middleton
Using X11 (on Debian Wheezy), SDL_GetModState() & KMOD_NUM and KMOD_CAPS are not set to system state (numlock/capslock LEDs). Pressing numlock or capslock toggles the mod state, though if num/caps lock is enabled before starting the program it's still reversed from system state. This makes getting KMOD_NUM and KMOD_CAPS in programs unreliable. This can be seen using the checkkeys test program.
The function that appears to have handle this in SDL 1.2 is X11_SetKeyboardState. The function call is commented out with "FIXME:" in SDL 2.
Using Windows backend through WINE; on first key press if numlock and/or capslock is enabled on system, numlock/capslock SDL_SendKeyboardKey is run and toggles KMOD_NUM/KMOD_CAPS to the correct state. On X11 this does not happen.
The attached patch makes X11 backend set keyboard state on window focus if no window was previously focused. It sets all keys to system up/down state and toggles KMOD_NUM/KMOD_CAPS via SDL_SendKeyboardKey to match system if needed. The patch is based on SDL 1.2's X11_SetKeyboardState.
Coriiander
Upon creating a window, a window property is added to it through the Win32-function "SetProp". This is done in the SDL-function "SetupWindowData" in file "src\video\windows\SDL_windowswindow.c".
Whenever you call "SetProp" to add a property to a Win32-window, you should also call the Win32-function "RemoveProp" to remove it before destroying that Win32-window.
While you might think that it's ok and that Windows will clean up nicely itself, it is not ok. It is against all Win32-API guidelines and is mostlikely a leak. Especially on external windows (CreateWindowFrom) you want to have things done right, not messy and leaky, affecting some other module. Even if SDL gets shutdown entirely that external window will now forever still have the "SDL_WindowData" prop attached to it.
The backing scale factor can change when the window moves between retina and non-retina displays.
The only other way to detect such a change is to compare the output of SDL_GL_GetDrawableSize or SDL_GetRendererOutputSize every frame, which is less than desirable, especially since the necessary app logic is likely already being executed when a window resize event is received.
This lets SDL-based apps respond to "Open With" commands properly, as they
can now obtain the requested path via a standard SDL dropfile event.
This is only checked on startup, so apps don't get drop events at any other
time, even if Android supports that, but this is still a definite
improvement.
Fixes Bugzilla #2762.
This apparently has fallout: the PS4 (and maybe PS3?) controllers apparently
report some bogus axes, but it won't change the axes we currently expect, and
thus the game controller config string is still stable.
Fixes Bugzilla #2719.
Since all device detection/removal happens on the main thread now, post events inline with when the status changes occur.
Also fixed rare cases when joystick API functions could return data about removed joysticks when called with a device index.
According to the documentation of Android's MotionEvent, the getPressure() may
return values higher than 1 on some devices. To prevent passing such values into
SDL they are now corrected to 1 in Java before the JNI call (where it is assumed
to be correct).
Currently SDL only sends SDL_FINGERMOTION events if the touch state (position or
pressure) changed. By correcting pressure down to 1 some events may get dropped
in the rare case that only the pressure was changed but was out of range and the
position did not change.
id.zeta
The optimization from Bug 11 added a code branch on cases where the source RGB masks match the destination RGB masks and a optimized blit function Blit4to4MaskAlpha that always overrides the source alpha info would be chosen. Unfortunately, the branch also errorneously took over the RGBA<->RGBA blitting cases where the source alpha info should be copied, while they would instead get overriden in Blit4to4MaskAlpha.
The attached patch fixes that by handling the RGBA<->RGBA cases correctly in that branch with the original BlitNtoNCopyAlpha as well as uses an optimized Blit4to4CopyAlpha along the same vein.
Code signature can be added after build with the following command line:
codesign --force --sign 76BB5ACAC44CA5EFA5F879434D157B81DA842CFB SDL2.framework/Versions/A
With this commit, you can compile SDL2 with Emscripten
( http://emscripten.org/ ), and make your SDL-based C/C++ program
into a web app.
This port was due to the efforts of several people, including: Charlie Birks,
Sathyanarayanan Gunasekaran, Jukka Jyl?nki, Alon Zakai, Edward Rudd,
Bruce Mitchener, and Martin Gerhardy. (Thanks, everyone!)
On Android starting the application after a previous quit did not always work.
Android keeps VM processes for a faster restart and therefore the loaded *.so.
The expected use case is for games that are designed with multiple aspect ratios already in mind and leave optional margins on the edges of the game which won't hurt if they are cut off.
An example use case is a game is designed for wide-screen/16:9, but then wants to deploy on an iPad which is 4:3. Normally, SDL will letterbox, which will shrink things and result in wasted space. But the designer already thought about 4:3 and designed the edges of the game so they could be cut off without any functional loss. So rather than wasting space with letterboxing, "overscan" mode will zoom the rendering to fill up the entire screen. Parts on the edges will be drawn offscreen, but since the game was already designed with this in mind, it is fine. The end result is the iPad (4:3) experience is much better since it feels like a game designed for that screen aspect ratio.
This patch introduces a new SDL_hint: SDL_HINT_RENDER_LOGICAL_SIZE_MODE.
Valid values are "letterbox" or "0" for letterboxing and "overscan" or "1" for overscan.
The default mode is letterbox to preserve existing behavior.
// Example usage:
SDL_SetHint(SDL_HINT_RENDER_LOGICAL_SIZE_MODE, "overscan");
SDL_RenderSetLogicalSize(renderer, SCREEN_WIDTH, SCREEN_HEIGHT);
Chris Beck
When creating a homebrew recipe for wesnoth, I discovered that the SDL image configuration routine does not detect libpng properly -- if you have multiple instances of libpng on your system, and you use environment variables to select an instance which is not in your system directory, the build can be broken, because it will run configuration tests against the system installed version, but deduce that it should use the filename of the system-installed version. In a vanilla build of wesnoth using homebrew, this results in segfaults at runtime, because you end up linking against two different versions of libpng, which is also needed independently of SDL.
The problem is essentially in the "find_lib" routine in the configure file:
find_lib()
{
gcc_bin_path=[`$CC -print-search-dirs 2>/dev/null | fgrep programs: | sed 's/[^=]*=\(.*\)/\1/' | sed 's/:/ /g'`]
gcc_lib_path=[`$CC -print-search-dirs 2>/dev/null | fgrep libraries: | sed 's/[^=]*=\(.*\)/\1/' | sed 's/:/ /g'`]
env_lib_path=[`echo $LIBS $LDFLAGS | sed 's/-L[ ]*//g'`]
for path in $gcc_bin_path $gcc_lib_path $env_lib_path /usr/lib /usr/local/lib; do
lib=[`ls -- $path/$1 2>/dev/null | sort -r | sed 's/.*\/\(.*\)/\1/; q'`]
if test x$lib != x; then
echo $lib
return
fi
done
}
Because the for loop goes over the system directories before the environment directories, any system-installed lib will shadow the lib selected via environment variables. This is contrary to the behavior of the configuration tests earlier in the script, which prefers the environment variable libs over the system-installed libs. The 'for' loop should instead be:
for path in $env_lib_path $gcc_bin_path $gcc_lib_path /usr/lib /usr/local/lib; do
You can see the full discussion on the Homebrew / linuxbrew issue tracker here: https://github.com/Homebrew/linuxbrew/issues/172
I have checked that this bug also affects SDL 1.2.15, SDL_mixer and SDL_ttf 1.2, which all use this same "find_lib" routine. I have not determined if the bug affects SDL 2.0, which seems not to use this exact routine.
Elias Vanderstuyft
Remove the dependency of the calculation of Linux "phase" on "period",
currently the "phase" parameter is interpreted as a time shift, instead of a phase shift.
The Linux input documentation is not clear about the exact units of the "phase" parameter (see http://lxr.free-electrons.com/source/include/uapi/linux/input.h?v=3.17#L1075 ),
but we're about to standardize the 'phase shift' interpretation into the Linux input documentation,
since this will ease the job of a driver to recalculate the effect's state when the user dynamically updates the "period" parameter.
Elias Vanderstuyft
"Horizontal" is not very precise, use "Positive phase" instead.
"Positive" because it's actually waveform(2*pi*t + phase) instead of waveform(2*pi*t - phase).
Elias Vanderstuyft
It's not obvious from the general "haptic direction" description what the SDL direction actually means in terms of force magnitude sign,
currently its meaning is only reflected by the example.
This change does a few things, all with regards to the WinRT implementation of
SDL_GetPrefPath():
1. it fixes a bug whereby SDL_GetPrefPath() did not create the directory it
returned. On other SDL platforms, SDL_GetPrefPath() will create separate
directories for its 'org' and 'app' folders. Without this, attempts to create
files in the pref-path would fail, unless those directories were first created
by the app, or by some other library the app used. This change makes sure
that these directories get created, before SDL_GetPrefPath() returns to its
caller(s).
2. it defaults to having SDL_GetPrefPath() return a WinRT 'Local' folder
on all platforms. Previously, for Windows Store apps, it would have used a
different, 'Roaming' folder. Files in Roaming folders can be automatically,
and synchronized across multiple devices by Windows. This synchronization can
happen while the app runs, with new files being copied into a running app's
pref-path. Unless an app is specifically designed to handle this scenario,
there is a chance that save-data could be overwritten in unwanted or
unexpected ways.
The default is now to use a Local folder, which does not get synchronized, and
which is arguably a bit safer to use. Apps that wish to use Roaming folders
can do so by setting SDL_HINT_WINRT_PREF_PATH_ROOT to "roaming", however it
is recommended that one first read Microsoft's documentation for Roaming
files, a link to which is provided in README-winrt.md.
To preserve older pref-path selection behavior (found in SDL 2.0.3, as well as
many pre-2.0.4 versions of SDL from hg.libsdl.org), which uses a Roaming path
in Windows Store apps, and a Local path in Windows Phone, set
SDL_HINT_WINRT_PREF_PATH_ROOT to "old".
Please note that Roaming paths are not supported on Windows Phone 8.0, due to
limitations in the OS itself. Attempts to use this will fail.
(Windows Phone 8.1 does not have this limitation, however.)
3. It makes SDL_GetPrefPath(), when on Windows Phone 8.0, and when
SDL_HINT_WINRT_PREF_PATH_ROOT is set to "roaming", return NULL, rather than
silently defaulting to a Local path (then switching to a Roaming path if and
when the user upgraded to Windows Phone 8.1).
Jonas Kulla
src/main/windows/SDL_windows_main.c:137:
cmdline = SDL_iconv_string("UTF-8", "UCS-2-INTERNAL", (char *)(text), (SDL_wcslen(text)+1)*sizeof(WCHAR));
I'm trying to compile an SDL2 application for windows using the mingw-w64 32bit toolchain provided by my distro (Fedora 19). However, even the simplest test program that does nothing at all fails to startup with a "Fatal error - out of memory" message because the mingw iconv library provided by my distro does not support the "UCS-2-INTERNAL" encoding and the conversion returns null.
From my little bit of research, it turns out that even though this encoding is supported by the external GNU libiconv library, some glibc versions (?) don't support it with their internal iconv routines, and will instead provide the native endian encoding when "UCS-2" is specified.
Nonetheless, I wonder why the native endianness is considered in the first place when Windows doesn't even run on any big endian archs (to my knowledge). And true enough, 'WIN_StringToUTF8' from core/windows/SDL_windows.h is used everywhere else in the windows backend, which is just a macro to iconv with "UTF-16LE" as source. Therefore it would IMO make sense to use this macro here as well, which would solve my problem (patch attached).
Nitz
I added xdnd_version check to XdndPosition case also
under DEBUG_XEVENTS macro.
by this we can get the action requested by user.
I analysed further and found out that removing xdnd_version check at XdndDrop case is a bad idea because
in XConvertSelection API timestamp should be passed if(xdnd_version >= 1)
otherwise CurrentTime should be passed
So xdnd_version check is important at XdndDrop case
I made xdnd_version as a static so that it can store the version in other cases also.
WinRT apps can set a default, preferred orientation via a .appxmanifest file.
SDL was overriding this on app startup, and making the app use all possible
orientations (landscape and portrait).
Thanks to Eric Wing for the heads up on this!
Visual C++ 2013 Update 4 re-introduced the Sleep() function to WinRT apps (for
code that targets Windows 8.1 and Windows Phone 8.1). This led to a build
error, as SDL was defining it's own Sleep() function (to make up for the lack
of a public Sleep() function). The fix makes sure that SDL's custom Sleep()
function is only used when Windows' Sleep() is not available.
Many thanks go out to Sergiu Marian Gaina for the fix!
This would fail if the compiler was given a .m file _and_ no "-o" option; it
would fail to automatically calculate the correct .o filename in this
situation.
Thanks to Ethan Lee for the help tracking this one down!
Only the first-pressed finger wpuld get reported as having moved (via SDL's
touch APIs). Subsequently pressed fingers wouldn't report as being moved, even
though the OS was reporting (to SDL) that they had moved.
These variants include:
- Windows 8.0 for x86
- Windows 8.0 for x64
- Windows 8.0 for ARM
- Windows 8.1 for x86
- Windows 8.1 for x64
- Windows 8.1 for ARM
- Windows Phone 8.0 for x86 (for use with the Windows Phone emulator)
- Windows Phone 8.0 for ARM
- Windows Phone 8.1 for x86 (for use with the Windows Phone emulator)
- Windows Phone 8.1 for ARM
iOS 8 introduces LaunchScreen NIBs which use autolayout to handle all devices and orientations with a single NIB instead of multiple launch images. This is also the only way to get the App Store badge "Optimized for iPhone 6 and iPhone 6 Plus". So if the application is running on iOS 8 or greater AND has specified a LaunchScreen in their Info.plist, this patch will use the NIB as the launch screen. Otherwise, the code falls back to the legacy code path.
Note: Upon audit of the legacy path, it appears that it does not properly handle the UILaunchImages Info.plist convention. I've added comments inline to the code about this. However, in about a year from now, nobody is going to care about this path since everybody should be using LaunchScreen NIBs.
SDL_HINT_WINRT_PREF_PATH_ROOT allows WinRT apps to alter the path that
SDL_GetPrefPath() returns. Setting it to "local" uses the app's
OS-defined Local folder, setting it to "roaming" uses the app's OS-defined
Roaming folder.
Roaming folder support is not available in Windows Phone 8.0. Attempts to
make SDL_GetPrefPath() return a Roaming folder on this OS will be ignored.
Various bits of documentation on this were added to SDL_hints.h, and to
README-winrt.md
Further support regarding IME and on-screen keyboards is pending, some of
which might not be 100% compatible with other platforms, given WinRT platform
restrictions. An MSDN article at http://msdn.microsoft.com/en-us/library/windows/apps/hh465404.aspx
indicates that on-screen keyboard display requires that the user first tap on
a Windows/XAML text control.
This change adds basic SDL_TEXTINPUT support, with input coming from hardware
keyboards, at a minimum, and without the need for XAML integration (which is
still pending integration into SDL, by and large).
This scenario can occur, for example, when the 4-finger touch sequence is used to switch spaces. the SDL window does not receive the touch up events and ends up thinking there are far more fingers on the pad than there are.
So the solution here is everytime a new "touch" appears we can through and check if there are any existing known touches by the OS and if there are none, abut SDL things there are, we simply go through and cancel the SDL touches.
Side affects.
- the "touch up" won't occur until the users sends a new touch (could be well after the actual release really did occur)
Windows Phone 8.0 either did not define, or provide access to, a 'RoamingFolder'
or 'TemporaryFolder' for apps to use. Windows 8.0 and 8.1 do, as does
Windows Phone 8.1. This change allows SDL-based Windows Phone 8.1 apps to
access these folders, via either the SDL_WinRTGetFSPathUNICODE() or
SDL_WinRTGetFSPathUTF8() functions.
SDL_GetPrefPath(), which on WinRT, is based on SDL_WinRTGetFSPathUTF8(), will
continue to return the app's 'local' folder, despite Windows 8.x
counterpart apps using the 'roaming' folder, in order to preserve compatibility
when 8.0-based Phone apps upgrade to 8.1-based Phone apps.
This patch makes sure that any SDL_MOUSEBUTTONDOWN, SDL_MOUSEBUTTONUP, and
SDL_MOUSEMOTION events, as triggered by a touch event in a WinRT app, set the
event's 'which' field to SDL_TOUCH_MOUSEID. Previously, this was getting set
to the same value as events from a real mouse, '0'.
Thanks to Diego for providing information on this bug, and to Tamas Hamor for
sending over a patch!
The crash would occur when a WinRT app explicitly tried to create an
SDL_Renderer using the "opengles2" renderer (via SDL_HINT_RENDER_DRIVER), but
OpenGL ES 2 / ANGLE .dlls weren't packaged in the app.
The "future-dev" branch of MSOpenTech's ANGLE/WinRT repository (at
https://github.com/msopentech/angle) includes support for Windows Phone 8.1.
This change allows it to be used in conjunction with SDL's OpenGL functions.
ANGLE for WinRT has at least two versions:
- an older version, which supports Windows 8.0 and 8.1. This is currently
the "winrt" branch in MSOpenTech's ANGLE repository (at
https://github.com/msopentech/angle)
- a newer version, which drops support for Windows 8.0, but is under more
active development (via MSOpenTech's "future-dev" branch), and which was
recently merged into the ANGLE project's official "master" branch
(at https://chromium.googlesource.com/angle/angle)
Both versions are setup using slightly different APIs. SDL/WinRT will now
attempt to detect which version is being used, and configure it appropriately.
The script was originally written for an SDL_gamecontrollerdb.h which had groups
of mappings separated by single lines starting with a "#". This was changed some
time ago to #endif/#if pairs. Because the script assumed only a single #endif in
the whole file it no longer worked correctly and only processed the first group.
The return value of SDL_malloc() was not checked and NULL therefore not handled.
Also added setting of error message for the other SDL_malloc() in this function.
Nitz
Variable entry going out of scope leaks the storage it points to, at:
/* Need to add a hint entry for this watcher */
hint = (SDL_Hint *)SDL_malloc(sizeof(*hint));
if (!hint) {
return;
}
Patch is attached.
The return value of SDL_malloc() was not checked and NULL therefore not handled.
NULL returned by SDL_GameControllerMapping()/SDL_GameControllerMappingForGUID()
now either means "no mapping" (as before) or "no memory" (just crashed before).
For consistency with the similar functions getting SDL_GameController as input.
Also NULL is no SDL_GameController and therefore can not have a mapping anyway.
- made keycode listings a bit easier to read
- listed VK_ keycode names, where appropriate
- removed a few pieces of dead + commented-out code
- applied a common 'WINRT_' prefix to internal function names
If the alert dialog could be canceled the Activity would not be finished here.
Also setting the property to "true" would be redundant because that is default.
Attributes on the host device's rotation were getting applied to offscreen
textures in an invalid manner. This was causing some apps to look different,
depending on how the device was rotated.
A negative periodic magnitude doesn't exist in Windows' and MacOS' FF APIs
The periodic magnitude parameter of the SDL Haptic API is based on the Linux
FF API, so it means they are not directly compatible:
'dwMagnitude' is a 'DWORD', which is unsigned.
Fixes Bugzilla #2701.
This modifies SDL_PauseAudio behavior to pause all audio devices instead of
just the default one (required on Android, at least for testmultiaudio on my
Nexus 4 which reported 2 audio devices).
It also changes SDL_PauseAudioDevice to retain the device lock from pause until
resume in order to save battery in mobile devices.
Philipp Wiesemann
I attached a patch for an incomplete implementation of the messagebox parts.
It was not tested on lots of devices yet and features a very fragile workaround to block the calling SDL thread while the dialog is handled on Android's UI thread. Although it works for testmessage.c I assume there are lot of situations were it may fail (standby, device rotation and other changes). Also not all flags and colors are implemented.
On the other hand most uses of the messagebox are to show an error on start and fragility (or working at all) may not matter there.
since the window system doesn't do it for us like other platforms.
This prevents sticky keys and missed keys when going in and out
of focus, for example Alt would appear to stick if switching away
from an SDL app with Alt-Tab and had to be pressed again.
CR: Sam
This helps when modern versions of The Gimp (and lots of other things)
produces a 32-bit bitmap with an alpha channel, or anything with "BI_BITFIELDS"
format, since that data is now embedded in the bitmap info header instead of
directly following it and we would accidentally skip over embedded versions of
it.
Fixes Bugzilla #2714.
Alex Szpakowski
SDL's Cocoa backend uses the CGDisplayMode API to get refresh rate information about a display mode, but CGDisplayModeGetRefreshRate will return 0 on most non-CRT monitors.
The only way I know of to get correct refresh rate information in OS X is via the CoreVideo DisplayLink API.
I have attached a patch which tries to use the CVDisplayLinkGetNominalOutputVideoRefreshPeriod function if CGDisplayModeGetRefreshRate fails, which fixes display mode refresh rate information on the monitors I tested.
The CVDisplayLink API requires linking with the CoreVideo framework, and the patch updates the various build files to do so.
+ Handle HidePreeditText IBus signal.
+ Use SDL_GetKeyboardFocus instead of SDL_GetFocusWindow.
+ Move the X11 IBus SetFocus calls to the X11_DispatchFocus functions.
+ Simplify the IBus ifdefs when handling X11 KeyEvents.
+ Remove inotify watch when SDL_IBus_Quit is called.
skaller
using gcc 4.2 (the default) on Mac OSX 10.6.8
CC build/SDL_dynapi.lo
In file included from /Users/johnskaller/SDL/src/dynapi/SDL_dynapi.c:31:
include/SDL_syswm.h:211:39: error: missing binary operator before token "("
The fault appears to be here:
#if defined(__OBJC__) && __has_feature(objc_arc)
that the __has_feature macro is not supported by gcc 4.2.
The code works fine with my clang 3.3svn.
hotgloupi
Configuring using "cmake -DSDL_STATIC=1 -DSDL_SHARED=0" generate and error in CMakeLists.txt at line 1334:
CMake Error at CMakeLists.txt:1334 (install):
install TARGETS given target "SDL2" which does not exist in this directory.
This install rule shouldn't be present when the DLL has been disabled
Tim McDaniel
This patch replaces all use of NSAutoreleasePool with the Apple recommended @autoreleasepool. @autoreleasepool is supposedly more efficient, and since it is scope based it can't be accidentally not released.
Tim McDaniel
On OSX, with revision 8729, the coordinate space for window position and the coordinate space for global mouse position don't match. For a non-fullscreen window, the window position is global relative to the bottom of the menubar. The global mouse position is relative to the top of the screen. This affects Cocoa_WarpMouse and potentially other things as well. Further, the coordinate system for window position is now affected by what screen it is on. For example, if I have two equal size screens oriented side by side such that the tops of the screens are equal in global space, with the menubar on one screen, and a window straddles the two screens, the window's y position makes no sense. The window's y position depends on what screen "most" of the window is on. So if I move the window horizontally just a bit, the y position of my window is now different by the size of the menubar, even though the window was not moved vertically.
I'd like to reiterate that this was a fairly fundamental change (and a breaking change for us). If SDL OSX is to really support multi-display configurations, this is especially problematic.
If the real concern is preventing windows from going under the menubar, then perhaps a solution involving something like overriding [NSWindow constrainFrameRect] would be less problematic than redefining the global window coord space for the main display.
Andreas Falkenhahn
SDL_RenderReadPixels() doesn't seem to work when trying to read pixels from a texture that has been created using SDL_TEXTUREACCESS_TARGET and has been selected as the render target using SDL_SetRenderTarget().
I am attaching a small program that demonstrates the issue. I get the following result here:
READ PIXEL RETURN: 0 --- COLOR CHECK: ff000000
But it should be:
READ PIXEL RETURN: 0 --- COLOR CHECK: ffff0000
Tested with SDL 2.0.3 on Windows 7.
Nitz
In SDL_CreateTextureFromSurface:
SDL_PixelFormat *dst_fmt;
/* Set up a destination surface for the texture update */
dst_fmt = SDL_AllocFormat(format);
temp = SDL_ConvertSurface(surface, dst_fmt, 0);
Here is need of NULL check for dst_fmt because there are chances of NULL return from SDL_AllocFormat(format);
Tobias Himmer
this patch adds a check to the CMake build script to detect whether the VideoCore API is available.
If it is found, it enables SDL_VIDEO_DRIVER_RPI and will also add the needed include/library directory flags to CMAKE_C_FLAGS so the subsequent check for GLES succeeds in picking up the headers.
Seems to work fine on Raspbian.
Patch from Benoit Pierre:
video: fix clipping handling in SDL_UpperBlitScaled
- honor destination clipping rectangle
- update both destination and source rectangles when clipping source
rectangle to source surface and destination rectangle to destination
clip rectangle
- don't change scaling factors when clipping
N.B.:
- when no scaling is involved (source and destination width/height are
the same), SDL_UpperBlit is used (so SDL_BlitScaled behaves like
SDL_BlitSurface)
- the final destination rectangle after all clipping is performed is
saved back to dstrect (like for SDL_UpperBlit)
There was a misconception that Linux's saturation and deadband parameters -
on which the corresponding SDL parameters were based - use only half of the
possible range.
Thanks, Elias!
Partially fixes Bugzilla #2686.
The _xgetbv intrinsic was being used in ARM builds of SDL/WinRT, which was
leading to linker errors. This commit limits _xgetbv use to the platforms on
which it is available, x86 and x64.
This will (eventually) make SDL_GetQueuedAudioSize() more accurate, and thus
reduce latency. Right now this isn't implemented anywhere, so we assume data
fed to the audio callback is consumed by the hardware and immediately played
to completion.
For versions of XAudio2 with an IXAudio2SourceVoice::GetState() that offers a
flags parameter, we can use XAUDIO2_VOICE_NOSAMPLESPLAYED, since we don't
need this information in our current calls. According to MSDN, this makes the
the call about 3x faster.
1) Moves all READMEs to docs/
2) Renames them to *.md, adds some Markdown with the idea to add a lot more
3) Moves the doxyfile config to doc/ and makes it parse the headers at ../include as well as the md files in docs.
4) Skips SDL_opengl*.h headers from the docs
5) Minor fixes to doxyfile
This requires at least Xcode 4.5 and the iOS 6 SDK to build, but it doesn't change the minimum supported runtime version (iOS 5.1). Less than 2% of iOS users are running iOS 5, so I hope developers aren't trying to build SDL using an SDK which doesn't support iOS 6/7...
Nitz
In GL_CreateTexture function:
if (GL_CheckError("glGenTexures()", renderer) < 0) {
SDL_free(data);
return -1;
}
Here only data is getting free but data->pixels getting leak.
So have to free data->pixels before free data.
Previously, SDL would always expose display modes and window dimensions in terms of pixels, and would add an extra 'fake' display mode on retina screens which would contain the non-retina resolution. Calling SDL_CreateWindow with the dimensions of that fake display mode would not work.
Now, SDL only exposes display modes and window dimensions in terms of points rather than pixels. If the SDL_WINDOW_ALLOW_HIGHDPI flag is passed into SDL_CreateWindow, then any OpenGL contexts created from that window will be sized in pixels rather than points (retrievable with SDL_GL_GetDrawableSize.) Window dimensions and mouse coordinates are still in terms of points rather than pixels even with that flag.
This matches the behavior of SDL in OS X more closely, and lets users choose whether to make use of retina displays and lets them handle it properly.
Damian Kaczmarek
Basically this bug is probably not a common use case. My goal is to allow rendering totally without a window, for example to a screenshot and I need to rely on SDL_SetRenderTarget to properly work for a purely software renderer created by SDL_CreateSoftwareRenderer.
Pablo Mayobre
When generating a signed app with SDL 2.0.3 an issue comes up, watching at the Error Log points out that the issue lies in the src/main/android/SDL_android_main.c where the process name is defined as "SDL_app", this name turns into an erroneous name so it should be changed to "app_process"
chasesan
When using SDL_RenderCopyEx, I get a problem on some platforms where the output is offset by +/-1 on other platforms and not on others. I tried it with a center of both 0,0 (and offsetting by width/height) and NULL (for centered).
The rotation involved is 90, and/or -90 rotation. The rotation was a constant, no arithmetic was involved when inputting it into SDL_RenderCopyEx.
This occurred with 32x32, 24x24, and 16x16 texture sizes. I apologize that I don't have more precise information, as I received the information as a bug report myself. But I have tracked the problem down to here.
My program requires pixel perfect alignment on several different platforms, so this is something of a showstopper for me.
--
Sylvain
It appears the RenderCopyEx is done as expected,
this is the red rectangle which is not correctly positionned !
So, here's patch with a 0.5 float increment, like for opengles2, for DrawLines, and also Draw Points.
binarycrusader
Since changeset 358696c354a8, SDL 2.0 has been broken on Solaris when compiling with the Solaris Studio compiler (which uses the pthread implementation of SDL_AtomicLock).
Notably, it gets stuck at the MemoryBarrierRelease in SDL_GetErrBuf:
6585 # 218
6586 if (!tls_errbuf && !tls_being_created) {
6587 SDL_AtomicLock_REAL ( & tls_lock );
6588 if (!tls_errbuf) {
6589 SDL_TLSID slot;
6590 tls_being_created = SDL_TRUE;
6591 slot = SDL_TLSCreate_REAL ( );
6592 tls_being_created = SDL_FALSE;
6593 { SDL_SpinLock _tmp = 0 ; SDL_AtomicLock_REAL ( & _tmp ) ; SDL_AtomicUnlock_REAL ( & _tmp ) ; };
^^^ loops forever above
6594 tls_errbuf = slot;
6595 }
6596 SDL_AtomicUnlock_REAL ( & tls_lock );
6597 }
Running: testthread
(process id 28926)
^Cdbx: warning: Interrupt ignored but forwarded to child.
signal INT (Interrupt) in __nanosleep at 0xfe52a875
0xfe52a875: __nanosleep+0x0015: jae __nanosleep+0x23 [ 0xfe52a883, .+0xe ]
Current function is SDL_Delay_REAL
204 was_error = nanosleep(&tv, &elapsed);
(dbx) where
[1] __nanosleep(0xfeffe848, 0xfeffe850, 0xfe75a5ac, 0xfe5169d8), at 0xfe52a875
[2] nanosleep(0xfeffe848, 0xfeffe850), at 0xfe516a3b
=>[3] SDL_Delay_REAL(ms = 0), line 204 in "SDL_systimer.c"
[4] SDL_AtomicLock_REAL(lock = 0xfeffe88c), line 104 in "SDL_spinlock.c"
[5] SDL_GetErrBuf(), line 225 in "SDL_thread.c"
[6] SDL_ClearError_REAL(), line 216 in "SDL_error.c"
[7] SDL_InitSubSystem_REAL(flags = 0), line 116 in "SDL.c"
[8] SDL_Init_REAL(flags = 0), line 244 in "SDL.c"
[9] SDL_Init(a = 0), line 89 in "SDL_dynapi_procs.h"
[10] main(argc = 1, argv = 0xfeffe948), line 65 in "testthread.c"
As far as I can tell, this is because pthread_spin_trylock() always returns EBUSY for this particular lock; since it works in other places, I'm suspicious.
Different Solaris Studio compiler versions seem to make no difference.
I've verified this is broken on Linux as well if SDL_spinlock.c is modified to use the pthread implementation.
This appears to be because pthread_spin_init() and pthread_spin_destroy() are not used with the locks as required.
Wei Mingzhi
surface->map should be invalidated in SDL_SetSurfacePalette(), otherwise the palette would not be effective when blitting to another non-8bit surface which we previously blitted to.
Alex Szpakowski
Some minor changes to the Mac-specific backend code:
- Fixed up some code style issues (mostly brace style inconsistencies).
- Fixed a compiler warning in SDL_cocoaevents.m.
- Removed some useless code now that the 10.7 SDK is required to build SDL.
- Removed Gestalt(gestaltSystemVersion, ...) call and switched to NSAppKitVersionNumber for version checking code. Using Gestalt with gestaltSystemVersion will give 0x1090 in Mac OS 10.10+, and the whole Gestalt function was deprecated in Mac OS 10.8.
Alex Szpakowski
Now that SDL on iOS requires CoreMotion to be linked, some of the Xcode projects included with the SDL source (such as the iOS tests and the iOS app template) as well as the premake and automake scripts need to be updated.
I've attached a patch which does so. It also fixes the SDL Xcode project to build for 64-bit ARM as well as armv7 by default (or whatever the default ARM targets are for the Xcode version used), which is what the iOS app template expects.
Alex Szpakowski
Since this commit https://hg.libsdl.org/SDL/rev/59b543340d63 , calling SDL_DestroyWindow will crash the program if the window has an active OpenGL context.
This is because the Cocoa_DestroyWindow code sets the window's driverdata to NULL and then calls [context setWindow:NULL], which tries to access the window's driverdata, resulting in a null pointer dereference.
I have attached a patch which fixes the issue by moving the line which sets the driverdata to NULL to after the lines which call functions that use the driverdata pointer.
Notes:
- Support for the 'Guide' button does not seem to be possible, as
XInputGetStateEx is not available on WinRT.
- Haptic support appears to be working on WinRT now!
- SDL/WinRT does not allow calls to LoadLibrary or LoadLibraryEx. The calls
to those were removed by this change, but only when compiling for WinRT.
Non-WinRT Windows will continue to detect and load XInput via LoadLibrary and
GetProcAddress calls.
If the EGL extension EGL_KHR_create_context is available, we can use it to
set the core/compatability profile and the minimum OpenGL version.
Use this if it is available to get the context requested by the GL attributes.
SDL/WinRT currently uses a separate XInput backend from SDL/Win32, as WinRT
has no support for DirectInput. This change makes SDL/WinRT's XInput
code snag some recently-changed bits from the Win32-specific,
DirectInput + XInput backend, in order to get the SDL_GameController API
working again on WinRT, insofar that axes map to the correct parts.
TODO:
- test all buttons, making sure WinRT maps buttons the same way that Win32 does
- consider making the Win32 and WinRT codebases share more stuff, minus
the sort of duplication happening via this change. Maybe simulate, or
stub-out, DirectInput calls when on WinRT?
Todd Seiler
Call Stack:
#0 0x0000000101c29291 in Cocoa_StartTextInput at /Users/Todd/Desktop/codes/sources/SDL/src/video/cocoa/SDL_cocoakeyboard.m:512
#1 0x0000000101c110c5 in SDL_SetKeyboardFocus at /Users/Todd/Desktop/codes/sources/SDL/src/events/SDL_keyboard.c:643
#2 0x0000000101c32be4 in SetupWindowData at /Users/Todd/Desktop/codes/sources/SDL/src/video/cocoa/SDL_cocoawindow.m:981
#3 0x0000000101c32d2a in Cocoa_CreateWindowFrom at /Users/Todd/Desktop/codes/sources/SDL/src/video/cocoa/SDL_cocoawindow.m:1092
#4 0x0000000101c99999 in SDL_CreateWindowFrom_REAL at /Users/Todd/Desktop/codes/sources/SDL/src/video/SDL_video.c:1338
#5 0x0000000101ce1484 in SDL_CreateWindowFrom at /Users/Todd/Desktop/codes/sources/SDL/src/dynapi/SDL_dynapi_procs.h:547
#6 0x0000000100018a5e in SceneRenderer at /Users/Todd/Desktop/codes/sources/tseiler_Todds-MacBook-Pro_3405/AppName/src/SceneRenderer.cpp:138
#7 0x0000000100017ca5 in SceneRenderer at /Users/Todd/Desktop/codes/sources/tseiler_Todds-MacBook-Pro_3405/AppName/src/SceneRenderer.cpp:145
#8 0x000000010000cd96 in App::execute(int, char**) at /Users/Todd/Desktop/codes/sources/tseiler_Todds-MacBook-Pro_3405/AppName/src/App.cpp:28
#9 0x0000000100004402 in main at /Users/Todd/Desktop/codes/sources/tseiler_Todds-MacBook-Pro_3405/AppName/src/main.cpp:8
This issue occurred when using Ogre3D Graphics engine on Mac (cocoa) to create the window. Then handing the window handle off to SDL_CreateWindowFrom().
In Ogre3D application you do the following:
window_ = root_->initialise(true, "Ogre Window 2");
loadOgreResources();
Ogre::WindowEventUtilities::addWindowEventListener(window_, this);
#if OGRE_PLATFORM == OGRE_PLATFORM_APPLE
NSWindow* Data = 0;
window_->getCustomAttribute("WINDOW", &Data);
sdl_window_ = SDL_CreateWindowFrom((void*)Data);
#endif
It results in a crash in this function:
SDL_cocoakeyboard.m
void
Cocoa_StartTextInput(_THIS)
{
SDL_VideoData *data = (SDL_VideoData *) _this->driverdata;
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
SDL_Window *window = SDL_GetKeyboardFocus();
NSWindow *nswindow = nil;
if (window)
nswindow = ((SDL_WindowData*)window->driverdata)->nswindow;
// ...
}
The crash occurred because "driverdata" was nil. Before this function call, a call to SetupWindowData is called:
SDL_cocoawindow.m
static int
SetupWindowData(_THIS, SDL_Window * window, NSWindow *nswindow, SDL_bool created)
{
// ...
if ([nswindow isKeyWindow]) {
window->flags |= SDL_WINDOW_INPUT_FOCUS;
SDL_SetKeyboardFocus(data->window);
}
/* Prevents the window's "window device" from being destroyed when it is
* hidden. See http://www.mikeash.com/pyblog/nsopenglcontext-and-one-shot.html
*/
[nswindow setOneShot:NO];
/* All done! */
[pool release];
window->driverdata = data;
return 0;
}
As you can see: "window->driverdata = data" is performed after the "SDL_SetKeyboardFocus()" call, which eventually leads to "Cocoa_StartTextInput()" where the crash occurs.
Alex Szpakowski
SDL's code for exposing the accelerometer as a joystick on iOS currently uses UIAccelerometer, which was superseded by the CoreMotion framework and deprecated since iOS 5.
The UIAccelerometer code still works (for now), but it also throws deprecation warnings whenever SDL is built for iOS, since SDL's deployment target is no longer below iOS 5.
I've created a patch which replaces the old UIAccelerometer code with a replacement based on the CoreMotion framework. It has identical functionality (to SDL users), however iOS apps are now required to link to the CoreMotion framework when using SDL.
This adds support for all XInput devices, exposed through the SDL joystick API.
The button and axis reporting for XInput devices has been changed to match DirectInput and other platforms.
The game controller xinput mapping has been updated so this change is seamless.
There is a new hint, SDL_HINT_XINPUT_USE_OLD_JOYSTICK_MAPPING, for any applications that have hardcoded the old xinput button and axis set. This hint will be removed in SDL 2.1.
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
It was simpler to just have the polling (actually: hotplug detection)
functions return immediately if it's not an appropriate time to poll.
Note that previously, if any joystick/controller was opened, we would poll
every time anyhow, skipping this function.
* Test programs use project references instead of hard-coding SDL library dependencies
* Test data files are copied only when needed.
* Copying SDL2.dll is no longer necessary
* Fixed /SAFESEH warning
* Fixed attempted rebuild of SDL every time a test program is run
SDL2 reports the following message when we type the "/" on br-abnt2 keyboards:
The key you just pressed is not recognized by SDL. \
To help get this fixed, please report this to the SDL mailing list \
<sdl@libsdl.org> X11 KeyCode 97 (89), X11 KeySym 0x2F (slash).
That's because the corresponding entry in the scancodes table is
marked with value SDL_SCANCODE_UNKNOWN.
This commit fixes that adding the value SDL_SCANCODE_SLASH for this entry.
- Removed USE_GETTICKCOUNT code; it's never used now.
- Reduced the number of preprocessor checks for WinRT.
- Renamed timeSetPeriod() so it doesn't look like a Win32 API call.
An existing hint lets apps that don't need the timer resolution changed avoid
this, to save battery, etc, but this fixes several problems in timing, audio
callbacks not firing fast enough, etc.
Fixes Bugzilla #2944.
This makes the X error handler used for GL context creation handle *all* errors
and provide the user with specific error messages when SDL_GL_CreateContext
fails.
CR: icculus@icculus.org
Alex Szpakowski
Patch to fix the y component of the position of fullscreen windows in OS X.
In Mac OS X with the latest Mercurial code, when a window is in exclusive-fullscreen the y component of its position is offset by the same amount that is normally taken up by the menubar, resulting in a black bar at the top of the screen.
The recent changes to the internal ConvertNSRect function make it treat the bottom of the menubar as 0 for the y component of window positions, even when the window is fullscreen and 'above' the menubar.
I have attached a patch which fixes the issue by only making the window position relative to the menubar in windowed modes.
Eric Wasylishen
Steps to reproduce:
- Run testwm2 app in the SDLTest Xcode project
- Press Control+R to enable relative mouse mode. The mouse cursor should disappear.
- Press Control+Enter to enter fullscreen.
- Expected: a black screen with no cursor visible. Observed: a black screen, but the mouse cursor is visible in the middle of the screen. It doesn't move when I move the mouse.
Reproduced with latest sdl2 hg (changeset f6010ead184f) on OS X 10.9.2. Can't reproduce the problem on OS X 10.6.8 or 10.7.5.
I'm speculating that this really an Apple bug.. but anyway, the attached workaround seems to fix it for me, and I think it's fairly safe.
A more obvious idea, sticking a call SDL_SetCursor(NULL) at the end of Cocoa_SetWindowFullscreen, didn't work.
Eric Wasylishen
The problem seems to be the spaces handling code in -setFullscreenSpace: (SDL_cocoawindow.m) is incorrectly reporting that the SDL_WINDOW_FULLSCREEN -> windowed transition has already happened.
i.e. I saw this case was getting hit when trying to leave SDL_WINDOW_FULLSCREEN:
"else if (state == isFullscreenSpace) {
return YES; /* already there. */
}"
With the attached patch, both Control+Enter (SDL_WINDOW_FULLSCREEN toggle) and Option+Enter (SDL_WINDOW_FULLSCREEN_DESKTOP toggle) work in an sdl test app (I tried testwm2). Tested on OS X 10.9.2.
snake5creator
When starting application with the usual "double click on file" method on Windows, only holding the last click, an unnecessary MOUSEBUTTONDOWN event is sent before the initial MOUSEMOTION event, and mouse button state is stuck in the sense that it takes a subsequent button release, followed by another press for the system to resume sending events (beginning with the next button release / MOUSEBUTTONUP event).
Input event log with held double-click startup: http://i.imgur.com/nypGKR2.png
Without: http://i.imgur.com/yaIqAvV.png
From Melesie
I noticed that when user switches from fullscreen mode to windowed mode and exits application while in windowed mode, Windows performs an additional change of display settings, even though desktop resolution is the same as current one. This causes short black screen to show up. The only way I know of avoiding this is to explicitly switch to default display settings found in registry. MSDN documentation for ChangeDisplaySettingsEx states:
Passing NULL for the lpDevMode parameter and 0 for the dwFlags parameter is the easiest way to return to the default mode after a dynamic mode change.
This would have been a one-line patch to the documentation (specifying that
captures only work as long as the left mouse button is pressed), but I didn't
like that, so I got a little crazy about this instead.
There were several good arguments for this: it's how Windows works with
WM_NCHITTEST, SDL doesn't need to manage a list of rects, it allows more
control over the regions (how do you use rects to cleanly surround a circular
button?), the callback can be more optimized than a iterating a list of
rects, and you don't have to send an updated list of rects whenever the
window resizes or layout changes.
This should be a "long" which on a 64-bit system is likely to be > 32-bits,
causing XGetICValues() to write past the end of the variable (and stack).
Fixes Bugzilla #2513.
All WinRT builds of SDL will now output, "SDL2.dll". Previously, the Windows
8.x/RT builds would output, "SDL.dll", and Windows Phone 8 builds would output,
"SDL_WinPhone.dll". The change to "SDL2.dll" puts WinRT dll naming in-line with
that seen on Win32.
SDL/WinRT's MSVC project files will now appear as either "SDL2-WinRT" or
"SDL2-WinPhone", when displaying in MSVC.
This set of changes should not break any older WinRT or Windows Phone 8 app
builds that rely on MSVC's Project-to-Project reference system to build SDL2 for
the correct platform(s), and to install SDL2 dll files into the apps' output
packages. App builds that reference SDL dll files directly should, however,
now reference "SDL2.dll".
It seems like a net improvement in all the scenarios Sam and I could
think of, and looking at hg history it was added for fullscreen
window management specifically. Much of that code has changed since
then, but maybe it needs to stay there for that and simply be moved
to a fullscreen condition check.
It would solve this issue:
https://bugzilla.libsdl.org/show_bug.cgi?id=2439
As well as cases where on SteamOS, we hide/show specific Steam
overlay windows while expecting them to stay in the background, since
changing the window stacking order really angers the NVIDIA driver.
CR: Sam.
(Most of its complaints here are that these ints can be negative, although
they wouldn't been in sane cases. Checking sanity is what assertions do, and
it placates the analyzer appropriately.)
These scenarios can happen when a GPU is switched, its driver updated, or in
some virtual machines (such as Parallels) are suspended and then resumed. In
these cases, all GPU resources will already be lost, and it's up to the app to
recover.
For now, SDL's D3D11 renderer will handle this by freeing all GPU resources,
including all textures, and then sending a SDL_RENDER_TARGETS_RESET event.
It's currently up to an app to intercept this event, destroy all of its
textures, then recreate them from scratch.
SDL_WINDOWEVENT_FOCUS_LOST is now sent when an app's native window is hidden.
Likewise, SDL_WINDOWEVENT_FOCUS_GAINED is sent when an app's window is shown.
This mimicks behavior seen on iOS and Android.
SDL_WINDOWEVENT_MINIMIZED and SDL_WINDOWEVENT_RESTORED are now sent when the
app's native window is hidden and shown. Previously, these were sent when an
app was suspended and resumed. On Windows 8.x/RT, an app may be sent to the
background without being suspended, which previously meant that
SDL_WINDOWEVENT_MINIMIZED might never have been sent. (On Windows Phone 8,
however, this seems to be different, whereby apps sent to the background appear
to always get suspended.)
SDL_APP_WILLENTERBACKGROUND is now sent as soon as the app is told that it is
about to go to the background. SDL_APP_DIDENTERBACKGROUND is sent via a WinRT
'deferral operation', which is how WinRT gives apps a bit of extra time
(multiple seconds worth) to prepare for an app-backgrounding.
The distinction may be important as the deferral operation's code is always run
in a separate thread. For Direct3D-only apps, this means that between the
two SDL app-backgrounded events, SDL_APP_WILLENTERBACKGROUND will be the only
one run from the main thread. Given that some WinRT operations can only be done
on the main thread (operations to the CoreWindow fall into this category), this
could be important.
It is important to note that pre-deferral code may only have a very short bit of
time to execute code, less so than code run in the deferral operation (where
SDL_APP_DIDENTERBACKGROUND is sent from), which usually gets several seconds to
run.
SDL/WinRT did have support for OpenGL ES 2 via an older version of ANGLE/WinRT,
however its API changed a few months ago, and SDL/WinRT would crash when trying
to use it. It would also occasionally crash when using the older version.
This changeset should make SDL/WinRT work with the latest version, as
available via MS Open Tech's git repository of it at
https://github.com/msopentech/angle
Older versions of ANGLE/WinRT (from either https://github.com/stammen/angleproject
or https://bitbucket.org/DavidLudwig/angleproject) will need to be updated to
MS Open Tech's latest version.
It's been hardcoded out forever now, but I've now forcibly removed it with
the preprocessor so static analysis doesn't complain about it for now.
Eventually I want to rewrite or remove this code.
This is actually a false-positive, in this case, since Clang doesn't know
that SDL_SetError() only ever returns -1. Feature request to improve that,
with explanation about these specific SDL patches, is here:
http://llvm.org/bugs/show_bug.cgi?id=19208
Rotation detection and handling should now work across all, publicly-released,
WinRT-based platforms (Windows 8.0, Windows 8.1, and Windows Phone 8.0).
This changeset prevents IDXGISwapChain::ResizeBuffers from being invoked on
Windows Phone 8, a function that isn't available on the platform (but is
available on other Windows platforms). The call would fail, which ultimately
led to a crash.
This changeset also attempts to make sure that the D3D11 swap chain is created
at the correct size, when using Windows Phone 8.
Still TODO: make sure rotation-querying works across relevant Windows
platforms (that support Direct3D 11.x).
Fix to allow using SDL when compiling with v110_xp or v120_xp -- compiling with VS2012/VS2013 with the XP targeting option.
In order to ensure that we can target Windows XP we compile with the v120_xp toolset instead of v120. This means that we use an earlier SDK version and it means that winapifamily.h is not available. Compiling for this old SDK can be detected using the _USING_V110_SDK71_ define which is set through the %(PreprocessorDefinitions) option.
Eventually we'll probably move the version checking to higher level code and report the actual version of context that got created, but to avoid breakage we'll leave it like this for now.
The D3D11 renderer is now slightly faster than D3D9 on my Windows 8 machine (testsprite2 runs at 3400 FPS vs 3100 FPS)
This will need tweaking to fix the Windows RT build.
klose
File: SDL_gesture.c
Method: SDL_GestureAddTouch
When a new SDL_GestureTouch element is added to the global SDL_gestureTouch array the variable 'centroid' of the new element is not initialized.
The problem is that this variable is read isndie SDL_GestureProcessEvent when a SDL_FINGERDOWN event occurs.
- SDL_WINDOW_FULLSCREEN works as always (change resolution, lock to window).
- SDL_WINDOW_FULLSCREEN_DESKTOP now puts the window in its own Space, and
hides the menu bar, but you can slide between Spaces and Command-Tab between
apps without the window minimizing, etc.
- SDL_WINDOW_RESIZABLE windows will get the new 10.7+ "toggle fullscreen"
window decoration and menubar item. As far as the app is concerned, this is
no different than resizing a window, but it gives the end-user more power.
- The hint for putting fullscreen windows into the Spaces system is gone,
since Spaces can't enforce the requested resolution. It's a perfect match
for FULLSCREEN_DESKTOP, though, so this is all automated now.
configure wraps this C code in a main() function, so you can't declare a
function body in there. Besides, I'm not sure why we declared a function
that's part of the multitouch API anyhow.
Now we just reference a type that only exists if the headers have multitouch
support and call it a day.
SDL was expected that each SDL_DisplayMode had a driverdata field that was SDL_malloc'ed, and was calling SDL_free on them. This change moves WinRT's driverdata content into a SDL_malloc'ed field.
Yamagi
A customer of mine had the strange problem, that SDL_SetRelativeMouseMode() was failing for him on Windows 7. Luckily he was willing to provide some debug informations. We could track this problem down to RegisterRawInputDevices() failing due to security software running on his system (Norton Internet Security to be precise, but there are reports of similar problems with other products. For example [1]). Working around this issue with SDL_WarpMouseInWindow() is easy, and while I don't think that SDL2 can provide an internal workaround it would be really nice and helpfull if this could be documentated somewhere.
1: http://forums.codeguru.com/showthread.php?498374-How-to-run-a-very-long-SQL-statement
Coriiander
In src\timer\windows\SDL_systimer.c there is an error with regards to timeBeginPeriod and timeEndPeriod. These functions typically get called when no high resolution timer is available, and GetTickCount is not used.
According to MSDN (link: http://msdn.microsoft.com/en-us/library/windows/desktop/dd757624(v=vs.85).aspx), for every call to timeBeginPeriod a subsequent call to timeEndPeriod is required. While SDL is currently doing this, it fails to call timeEndPeriod when cleaning up/shutting down SDL. Please note that these functions affect things on a system level. Failing to call timeEndPeriod, disables applications for using WINMM-timers after usage&shutdown of SDL, as effectively they the mechanism is now broken.
Solution:
Ensure this code gets called when shutting down the timer subsystem:
#ifndef USE_GETTICKCOUNT
if (!hires_timer_available)
{
timeSetPeriod(0);
}
#endif
This makes it possible to move windows by their title bar, even if they're in
relative mode, if you click the title bar when the window does not have focus.
Bug: https://bugzilla.libsdl.org/show_bug.cgi?id=2396
Previously we were postponing our -[NSOpenGLContext update] call to the next
SDL_GL_SwapWindow, even if the context was current on the current thread. This
changes it so that we will do the update immediately if it's the current
context.
If you're rendering on another thread, you need to call SDL_GL_SwapWindow once
after a resize event to ensure your drawable will produce non-garbage data.
Bug: https://bugzilla.libsdl.org/show_bug.cgi?id=2339
If the window has been created with values for SDL_GL_CONTEXT_PROFILE_MASK,
SDL_GL_CONTEXT_MAJOR_VERSION and SDL_GL_CONTEXT_MINOR_VERSION not matching those
required by the renderer, attempt to recreate the window.
This is needed on platforms where both GL and GLES 1/2 surfaces are supported
by the video backend, requiring that the window be recreated when switching
between context types.
Pressing the hardware back button on a Windows Phone 8 device will now cause SDL to emit a pair of key-down and key-up events, with the SDL scancode, SDL_SCANCODE_AC_BACK.
By default, if WinRT's native back-button-press events are not explicitly marked as 'handled', then Windows Phone will terminate the app. More details on Microsoft's reasoning behind this can be found on MSDN, at http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj247550(v=vs.105).aspx
To mark back-button-press events as 'handled', set SDL_HINT_WINRT_HANDLE_BACK_BUTTON to 1. Setting it to anything else will cause these events to not be marked as 'handled'.
Due to limitations in Windows Phone's APIs, SDL will emit a virtual key-up event immediately after the back button's key-down event is registered. Unfortunately, Windows Phone 8 only allows one to register for back-button-press events, and not back-button-release events.
This change is only relevant for Windows 8, 8.1, and RT apps, and only for those that are network-enabled. Such apps must feature a link to a privacy policy, which must be displayed via the Windows Settings charm. This is needed to pass Windows Store app-certification.
Using SDL_SetHint, along with SDL_HINT_WINRT_PRIVACY_POLICY_URL and optionally SDL_HINT_WINRT_PRIVACY_POLICY_LABEL, will cause SDL/WinRT to create a link inside the Windows Settings charm, as invoked from within an SDL-based app.
Network-enabled Windows Phone apps do not need to set this hint, and should provide some sort of in-app means to display their privacy policy. Microsoft does not appear to provide an OS-integrated means for displaying such on Windows Phone.
The destination target's alpha wasn't getting set correctly in many cases. Among other problems, this prevented some alpha-blended textures from displaying correctly in Windows Phone 8's multitasking screen.
The d3d11 renderer now uses the same blending settings found in the d3d9 renderer.
The projection and view matrices are now computed ahead of time, as they both get computed in the same spot, and typically not often. If this does, however, become a performance problem later on, this change can always be reverted.
Previously, the shaders would get compiled separately, the output of which would need to be packaged into the app. This change should make SDL's dll be the only binary needed to include SDL in a WinRT app.
Due to the new "tap and hold" IME in Mountain Lion and above, we were getting
inconsistent repeat of SDL_TEXTINPUT events. Disabling that functionality (since
you can't see the popover anyway) solves this.
Bug: https://bugzilla.libsdl.org/show_bug.cgi?id=2387
The DualShock 4 has all elements listed twice: once in the top-level list of
elements, and once in an "Application Collection" element at the top-level.
Each element has a proper cookie with a unique value, so now we descend into
each element collections, but before we add an element to the device's list,
we make sure we don't already have one with that cookie, probably from
another collection or a buggy device.
Tiemo Jung
All CPU detection functions SDL_Has* will return false, even if it is supported by the CPU, if SDL is compiled with MSVC and the target is x64.
The reason for this is that 'CPU_haveCPUID' will return 0 and macro 'cpuid' in SDL_cpuinfo.c is the fallback implementation, which sets all params to zero.
It is safe to assume that cpuid is supported on a CPU that runs windows x64, so CPU_haveCPUID can just return 1, and the empty macro can be replaced with a small wrap around the __cpuid intrinsic.
Felix Geyer
Starting from version 2.0.1 libsdl fails to build on Debian GNU/kFreeBSD in SDL_cpuinfo.c.
GNU/kFreeBSD defines __FreeBSD_kernel__ but not __FreeBSD__.
The #ifdef __FreeBSD__ check should be extended for __FreeBSD_kernel__, see the attached patch.
Build log:
libtool: compile: gcc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -DUSING_GENERATED_CONFIG_H -Iinclude -I/?BUILDDIR?/libsdl2-2.0.1+dfsg1/include -mmmx -m3dnow -msse -msse2 -fvisibility=hidden -D_REENTRANT -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-kfreebsd-gnu/dbus-1.0/include -DHAVE_USBHID_H -DUSBHID_NEW -D_REENTRANT -Wall -c /?BUILDDIR?/libsdl2-2.0.1+dfsg1/src/cpuinfo/SDL_cpuinfo.c -fPIC -DPIC -o build/.libs/SDL_cpuinfo.o
/?BUILDDIR?/libsdl2-2.0.1+dfsg1/src/cpuinfo/SDL_cpuinfo.c: In function 'SDL_GetSystemRAM':
/?BUILDDIR?/libsdl2-2.0.1+dfsg1/src/cpuinfo/SDL_cpuinfo.c:632:35: error: 'HW_MEMSIZE' undeclared (first use in this function)
int mib[2] = {CTL_HW, HW_MEMSIZE};
^
/?BUILDDIR?/libsdl2-2.0.1+dfsg1/src/cpuinfo/SDL_cpuinfo.c:632:35: note: each undeclared identifier is reported only once for each function it appears in
make[2]: *** [build/SDL_cpuinfo.lo] Error 1
Tim McDaniel
On OSX, an SDL app forces a system shutdown to be cancelled. This happens because [SDLAppDelegate applicationShouldTerminate] returns NSTerminateCancel. A better approach is to subclass NSApplication and override terminate to do nothing except call SDL_SendQuit. In response to a system shutdown notification, this allows the normal SDL Quit event processing to occur, and if the app then terminates, system shutdown occurs normally. Please see the attached patch, based on SDL 2.0.1.
Tim McDaniel
On OSX, the app name in the menu bar is not localized. This can be fixed using the following implementation for GetApplicationName in SDL_cocoaevents.m:
static NSString *
GetApplicationName(void)
{
NSDictionary *dict;
NSString *appName = 0;
appName = [[NSBundle mainBundle] objectForInfoDictionaryKey:@"CFBundleDisplayName"];
if (!appName)
appName = [[NSBundle mainBundle] objectForInfoDictionaryKey:@"CFBundleName"];
if (![appName length])
appName = [[NSProcessInfo processInfo] processName];
return appName;
}
Brian Minton
When building static or shared libraries on cygwin 1.7.25 on Windows 7 (32-bit), I get the following link errors:
build/.libs/SDL_windowskeyboard.o: In function `UIElementSink_QueryInterface@12':
/home/c-bminton/src/SDL/src/video/windows/SDL_windowskeyboard.c:995: undefined reference to `IID_IUnknown'
build/.libs/SDL_windowskeyboard.o: In function `IPPASink_QueryInterface@12':
/home/c-bminton/src/SDL/src/video/windows/SDL_windowskeyboard.c:1101: undefined reference to `IID_IUnknown'
collect2: error: ld returned 1 exit status
Makefile:126: recipe for target 'build/libSDL2.la' failed
make: *** [build/libSDL2.la] Error 1
--
The libuuid from e2fsprogs is completely unrelated to the w32api UUID.DLL implib. FWIW, any *NIX software that I've seen obviously wants the e2fsprogs version, but if libuuid-devel is installed (in /usr/lib) then you can't link against the w32api implib with a simple -luuid.
- Use the SDL_AUDIO_MASK_DATATYPE bit when selecting an implementation
where it matters. Previously two existing AUDIO_F32 cases had been
written, but were unreachable.
- Add AUDIO_F32 case for SDL_ConvertSurround_4.
- Fix incorrect pointer arithmetic causing the 2 to 6 channel
conversion for 4 byte audio formats to read and write beyond the end
of the buffer.
Leonardo
Event watchers are being executed on the inverse order they are added because they are added to the head of the SDL_event_watchers list.
Since watchers are allowed to change events before they are reported (they shouldn't, imo), this breaks code that rely on watcher execution order (such as distributed event handling).
An easy scenario to see this behaving weird to the user is if you add an event watcher to check mouse coordinates and check them again in your event loop. If you add the watcher after renderer's one (which always happens after you have initialized renderer), you get the same event but different coordinates.
The proposed patch adds the event watcher in the tail of the list, not in the beginning, and correctly fixes this problem.
Alex Szpakowski
Currently the UIKit/EAGL backend for SDL's OpenGL context creation API doesn't support OpenGL ES 3, despite iOS 7+ being capable (on devices with the necessary hardware.)
I have attached a patch to add support. It's also slightly more future-proof, so eventual OpenGL ES 4+ capability on iOS should hopefully work without requiring changes to SDL's UIKit/EAGL backend.
Alex Szpakowski
On my Mac OS X system (10.9.1), the SDL_MOUSEWHEEL event reports negative X values when my trackpad scrolls to the right, and positive X values when my trackpad scrolls to the left. This is backwards from what I'd expect, and I don't think it matches the Windows wheel events.
The vertical scroll values are what I'd expect though, and are consistent what gets reported on Windows (positive Y for scrolling up, negative Y for scrolling down.)
This is with "scroll direction: natural" disabled in the OS X trackpad settings (i.e. my scroll direction in non-SDL OS X programs matches what happens in Windows and Linux.)
I also tested with the horizontal scroll on a real mouse (Logitech G500 without custom drivers), and the horizontal scroll values in SDL are still flipped.
I "solved" the issue for myself by changing this line in the Cocoa_HandleMouseWheel function:
float x = [event deltaX];
to this:
float x = -[event deltaX];
I believe it should work fine with that change - I found something similar in another codebase while looking online for my issue - but I haven't tested on anything below Mac OS 10.8.
Besides being a little more simple to use than the earlier IOKit HID API, and
less likely to be deprecated, it also has the added benefit of working with
the Sony DualShock 4 controller in Bluetooth mode out of the box, whereas
the previous API has a bug that makes it report bad data for the
controller.
Cleaned up several other things in this code, having gone over every line of
it. The remaining deprecated calls are also gone.
Testing:
* Set the SDL_HINT_MOUSE_RELATIVE_MODE_WARP hint true, run testsprite2, press Ctrl-R to enter relative mode, alt tab away from the window, then click on the title bar of the window. Didn't get the mouse button release before, and we do now.
CR: Yahn + Alfred
The render target usage in controllermap is required if you are forced to use
the app at a different resolution than the one the art has been made for, for
example on Android, where you don't control the resolution.
(The coordinates for each button are hardcoded to the art size, and appear out
of place otherwise)
ernest.lee
[Exec] CMake Error at cmake_install.cmake:151 (FILE):
[13:37:43][Exec] file INSTALL cannot find
[13:37:43][Exec] "C:/TeamCity/buildAgent/work/2e3d17a492e75daf/Build/libSDL2.so".
The cmake INSTALL project doesn't work because it uses Linux so shared library paths. Windows uses dlls and I think cygwin also uses dlls. I've included this patch. Can you check if it works?
Sandu Liviu Catalin
I'm unable to compile the latest SDL (directly from the repository) even though I disabled every DirectX option since I don't need DirectX.
I allways het these errors:
D:\DevLibs\SDL\src\render\direct3d\SDL_render_d3d.c:1897:1: error: unknown type name 'IDirect3DDevice9'
D:\DevLibs\SDL\src\render\direct3d\SDL_render_d3d.c:1898:25: error: unknown type name 'SDL_Renderer'
ny00
SDL_RenderClear clears a render target with the wrong color, if the opengles2 renderer driver is used and the target texture's format is SDL_PIXELFORMAT_ARGB8888.
The bug is *not* reproduced if SDL_PIXELFORMAT_ABGR8888 is used as the texture format (the first from the renderer's list).
It is further not reproduced using any of the following renderer drivers: opengl, opengles (apparently powered by Gallium3D), software.
Finally, the correct color can be drawn using SDL_RenderFillRect (instead of SDL_RenderClear).
A few details about the current setup:
- OS: Ubuntu 12.04 for x86_64
- GPU: GeForce GTX 460
- GPU driver version: 331.20-0ubuntu1~xedgers~precise1 (from the xorg-edgers PPA)
---
Seth Williams
Sam,
It appears that the clear just needs to take the render target format into consideration.
Seth.
This lets it know, for example, that when you do this...
SDL_assert(ptr != NULL);
...that (ptr) is definitely not NULL at this point in the program, for the
sake of static analysis. While a buggy program could definitely trigger this
assertion, Clang assumes your assertion check is covering it and won't
report possible NULL dereferences after this point.
Since SDL_assert might continue if the user clicks "ignore", without this
change Clang would notice you checked for NULL (meaning that NULL is a real
possibility here) and still wrote code outside of that test branch that
dereferences the pointer, and thus would always trigger false positives.
Static analysis is fun!
We'll flip the default back to enabled right after 2.0.2 is finalized, and
try to declare them stable and ready by 2.0.3.
Those that have an interest in supporting them in 2.0.2 can manually enable
them in the configure script with --enable-video-wayland and/or
--enable-video-mir.
Haneef Mubarak
AVX is the successor to SSE* and is fairly widely available. As such, it really ought to be detectable.
This functionality ought to be trivial to implement, and not having it means being forced to write an ugly workaround to check for AVX (so that normal SSE can be used if AVX is not available).
Here is an example on detecting AVX from SO (it actually shows ways to cehck for all of teh fancy instructions):
http://stackoverflow.com/questions/6121792/how-to-check-if-a-cpu-supports-the-sse3-instruction-set
The reasoning behind this change is that source2 in -tools mode has a single OpenGL context that is used with multiple different windows. Some of those windows are created outside the engine (i.e. with Qt) and therefore we need to use SDL_CreateWindowFrom() to get an SDL_Window for those. The requirement for sharing an OpenGL context across multiple different windows is that each window has the same pixel format. To facilitate this, I now set SDL_HINT_VIDEO_WINDOW_SHARE_PIXEL_FORMAT for the main window before calling SDL_CreateWindowFrom(). When I do this, SDL_CreateWindowFrom() will:
1. Set the pixel format of the returned window to the same pixel format as this SDL_Window passed in with the hint
2. The flag SDL_WINDOW_OPENGL will be set on the new window so it can be used for OpenGL rendering.
I only currently implemented this for Win32/WGL so implementing it for other platforms (i.e. X11) remains a TODO.
CR: SamL
Some pseudocode that shows how this is used in Source2:
HWND hExternalHwnd; // HWND that was established outside of SDL
// Create main window (happens inside platwindow.cpp)
SDL_Window *mainWindow = SDL_CreateWindow( , SDL_WINDOW_OPENGL .. );
// Create GL context, happens inside rendersystemgl
SDL_GLContext onlyContext = SDL_GL_CreateContext( mainWindow );
// Now I need to create another window from hEternalHwnd for my swap chain that will have the same pixel format as mainWindow, so set the hint
SDL_SetHint( SDL_HINT_VIDEO_WINDOW_SHARE_PIXEL_FORMAT, CFmtStr( %p, mainWindow) );
// Create the secondary window. This returned window will have SDL_WINDOW_OPENGL set and share a pixel format with mainWindow from the hint
SDL_Window *secondaryWindow = SDL_CreateWindowFrom( hExternalHwnd );
// To render to the main window:
SDL_GL_MakeCurrent( mainWindow, onlyContext );
// Do some rendering to main window
// To render to the secondary window:
SDL_GLMakeCurrent( secondaryWindow, onlyContext );
// Do some rendering to secondary window
This fixes weird behavior on Mac where our first responder reverts to the window
itself, rather than the SDLTranslatorResponder, after the window has lost focus
once. This causes Escape to call cancelOperation: on the NSWindow, which by
default removes our fullscreen-ness.
When someone has turned off SDL_TEXTINPUT we should probably set another initial
responder that handles the Escape behavior, so that SDL_TEXTINPUT doesn't change
fullscreen behavior (and possibly other behavior) like it does now.
Previously, we'd minimize fullscreen windows (if
SDL_HINT_VIDEO_MINIMIZE_ON_FOCUS_LOSS was set) during SDL_DestroyWindow if they
had keyboard focus, because we call SDL_SetKeyboardFocus(NULL) which yields a
OnWindowsFocusLost event.
Related to https://bugzilla.libsdl.org/show_bug.cgi?id=1840
SDL 2.x recently accepted patches to enable OpenGL ES 2 support via Google's ANGLE library. The thought is to try to eventually merge SDL/WinRT's OpenGL code with SDL-official's.
Leszek Godlewski
As described in the other thread
(http://lists.libsdl.org/pipermail/sdl-libsdl.org/2013-November/091997.html),
I've run into a case of SDL2 not recognizing a wireless Xbox 360
controller receiver properly on Debian Linux amd64 testing.
Apparently, the generated GUID is slightly different.
Device in question:
Bus 001 Device 015: ID 045e:0291 Microsoft Corp. Xbox 360 Wireless
Receiver for Windows
BurnSpamAddress
Steps to reproduce:
1. Grab the cursor with SDL_SetCursorGrab()
2. Alt-tab away from the window
3. Click on the titlebar of the window
This will cause the window to disappear underneath the taskbar!
This appears to be a general issue with ClipCursor() on windows, i.e. I am getting the same behavior if I call ClipCursor() directly.
It is caused by a feedback loop between the ClipCursor function and the modal resize/move event loop that handles mouse-based sizing on Windows.
Ghassan Al-Mashareqa
The SDL_ceil function is implemented incorrectly when HAVE_CEIL is not defined (HAVE_LIBC not defined).
The following code:
double val = SDL_ceil(2.3);
printf("%g", val);
prints "2.0", as STD_ceil is defined as:
double
SDL_ceil(double x)
{
#ifdef HAVE_CEIL
return ceil(x);
#else
return (double)(int)((x)+0.5);
#endif /* HAVE_CEIL */
}
This functions is used in the SDL_BuildAudioResampleCVT function of the audio subsystem (SDL_audiocvt.c), and causes a bug in that function.
Lets Android take care of which is the primary pointer (the one acting as the
mouse in SDL), reorganized the Java side code as well to make it easier to
understand.
If your application wants to have access to the full resolution even when the system has DPI scaling enabled, call SetProcessDPIAware() before calling SDL_Init()
e.g.
typedef BOOL (WINAPI *SetProcessDPIAware_t)(void);
HMODULE hMod = LoadLibrary("user32.dll");
if ( hMod ) {
SetProcessDPIAware_t pSetProcessDPIAware = GetProcAddress( hMod, "SetProcessDPIAware" );
if ( pSetProcessDPIAware ) {
pSetProcessDPIAware();
}
FreeLibrary( hMod );
}
To enable this, set the environment variable SDL_MOUSE_RELATIVE_MODE_WARP to "1"
When mouse relative mode is disabled, put the cursor back where the application expects it to be, instead of where it was when relative mode was enabled.
Based on the original port to Wayland by: Joel Teichroeb, Benjamin Franzke, Scott Moreau, et al.
Additional changes in this commit, done by me:
* Wayland uses the common EGL framework
* EGL can now create a desktop OpenGL context
* testgl2 loads GL functions dynamically, no need to link to libGL anymore
* Assorted fixes to the Wayland backend
Tested on the Weston Compositor (v1.0.5) that ships with Ubuntu 13.10,
running Weston under X. Tests ran: testrendercopyex (all backends), testgl2, testgles2,testintersections
pjz
SDL_ltoa(-2147483648,s,10) only returns "-" because there is a bug in the code:
if ( value < 0 ) {
*bufp++ = '-';
value = -value;
}
but -(-2147483648) is still -2147483648 (0x80000000) as signed int (or long), so the following loop doesn't run at all. Similar bug are also in SDL_lltoa.
BTW, there is no sanity check for radix.
Brandon Schaefer
This means everything will render black if the software rendering backend selects a pixel format that supports alpha. So it seems best to at lease assume alpha is supported.
SDL_GameControllerAddMappingsFromFile is now a convenience macro.
controllermap can now skip bindings by pressing space or clicking/touching the
screen.
Joe LeVeque
Line 3 of SDL_VS2013.sln file reads "# Visual Studio 2012" instead of "# Visual Studio 2013" which causes Windows to associate the file with Visual Studio 2012, if installed, instead of Visual Studio 2013.
Ryan C. Gordon
To keep the directory layout sane, we should probably move this one piece of source to the linux catch-all directory, instead of making it look like this is part of an SDL "input" subsystem.
Marcus von Appen
clang provides support for optimized atomics.
The attached patch enables the cmake build system to take clang into account on checking for atomics.
norfanin
The MMX path in SDL_fillrect.c uses the SSE intrinsic _mm_stream_pi. The function or symbol provided by the compiler will not be present because the SSE header may not get included. The linker will complain about an undefined reference.
Since this is the only intrinsic used here (and someone forgot to create one for MOVQ), I think the MMX path can be removed completely. At least I don't see another way to move 64-bits from an MMX register to memory.
If it works correctly you should see a square moving from the upper left to the lower right, with a little yellow box at the top of the moving square.
You can pass --target as a command line option to have it use a render target instead of rendering directly to the screen. The output should be identical in this case.
philhassey
On OS/X after calling SDL_SetWindowBordered right mouse clicks no longer register.
Steps to Reproduce:
1. Open a windowed window on OS/X. (With the border on.)
2. e.button.button will give values 1,2,3 depending on which mouse button I click.
3. Call SDL_SetWindowBordered to disable the border.
4. e.button.button will only give values 1,2. 3 (right mouse button) stops coming through.
Expected result:
I expect all mouse buttons to register.
Haiku uses most of the standard pthread API, with a few #ifdefs where we
still need to fallback onto the old BeOS APIs.
BeOS, however, does not support pthreads (or maybe doesn't support it well),
so I'm unplugging support for the platform with this changeset. Be Inc went
out of business in 2001.
Ivan Rubinson
As it turns out, it was impossible to render a texture flipped diagonally (both vertically and horizontally) with one RenderCopyEx call.
With help from #SDL @ freenode, we came up with a fix.
"Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'backgroundWindows not nil in enterFullScreenTransitionWithOptions:animated:activatingIt:'"
To reproduce this, run testsprite2, press Alt-Enter once, again while it's animating to fullscreen, and then again while it's animating out of fullscreen.
philhassey
Overview: While SDL_SetTextInputRect works perfectly to move my window out of the way of the virtual keyboard using SDL2/Android, on iOS this function has no effect.
Steps to Reproduce: Call SDL_SetTextInputRect with a rect near the bottom of the screen before calling SDL_StartTextInput.
Actual Results: The iOS virtual keyboard is displayed after calling SDL_StartTextInput, but the screen is not shifted to reveal the TextInputRect region.
Expected Results: The screen should be shifted to reveal the TextInputRect region (like with SDL2/Android.)
This patch implements SDL_SetTextInputRect for uikit/iOS.
It sets up notification handlers to respond to changes in the display of the keyboard. These handlers then change the frame of the view so it is moved out of the way of the keyboard as per SetTextInputRect.
This fixes behavior with the new Mac OS X fullscreen space code, as well as improve behavior on Linux desktops.
The default for normal fullscreen mode is still to minimize because we're likely doing a mode switch and don't want to stick around as a borderless window in the background.
I still haven't figured out why my application is being minimized when I try to raise, it but my previous workaround is causing issues.
For now the correct way to raise and/or restore the window is as follows:
if ( !(SDL_GetWindowFlags( window ) & SDL_WINDOW_MINIMIZED) )
{
SDL_RaiseWindow( window );
}
if ( SDL_GetWindowFlags( window ) & SDL_WINDOW_MINIMIZED )
{
SDL_RestoreWindow( window );
}
I will investigate the window state change rules more fully in the future.
CR: Alfred Reynolds
When we get a kCGEventTapDisabledByTimeout or
kCGEventTapDisabledByUserInput, the event tap would perform an invalid
memory access. void pointers are so fun.
This code only runs if you explicitly build with SDL_MAC_NO_SANDBOX.
Patrice Mandin
I encountered a problem trying to load a 8-bit paletted BMP file using SDL. This file was generated using GIMP 2.8. It has a big BITMAPINFOHEADER (0x6c bytes for biSize field), and thus the palette is incorrectly setup.
Lorenzo Pistone
this patch adds support for the horizontal wheel in Windows. It is shamelessly copied off the vertical wheel code, but I guess that that is a value added in consistency.
Thanks to Denis Bernard!
Also, changed the Android manifest so the app doesn't quit with orientation
changes, and made testgles.c exit properly on Android.
This bumps the build SDK level to 12 (up from 10). Runtime requirements remain
the same (at API level < 12 joystick support is disabled).
Also enables building SDL for armv7 and x86.
A port of the ANGLE library (OpenGL ES 2.0 for Direct3D) to WinRT, via https://github.com/stammen/angleproject, is used as a base.
To enable, clone 'angleproject' into the directory one above where SDL/WinRT is, open the file SDL/include/SDL_config_winrt.h, and uncomment the #defines that begin with 'SDL_VIDEO_OPENGL'. From there, apps can create an OpenGL capable SDL_Window via the flag, SDL_WINDOW_OPENGL, and an OpenGL ES 2 context via SDL_GL_CreateContext. The Direct3D 11.1 renderer cannot be used alongside SDL_WINDOW_OPENGL. Only Windows 8/8.1 is supported for now. Shaders may need to be precompiled, in some (all?) cases.
Joseph Carter
Whitespace in a makefile is consequential. In fact, it's part of the syntax. And at least a few versions of make puke on Makefiles with lines indented with spaces, not tabs. Obviously GNU make used on Debianish systems is not strictly among them, or this would fail. Even so, I cannot resist the urge to pedantically fix this, if only to get rid of the bright syntax error red coloration in vim. :)
Joseph Carter
test/testdrawchessboard.c checks out of hg with DOS line endings on non-dos systems. Fixed via:
perl -pi -e 's/\r//g' test/testdrawchessboard.c
norfanin
The audio_enumerateAndNameAudioDevicesNegativeTests test in testautomation_audio.c reports a failure for SDL_GetAudioDeviceName when called on a driver that has only the default device. SDL_GetNumAudioDevices reports 1, but SDL_GetAudioDeviceName does not check if the index passed by the caller is in that range in this case. For positive numbers anyway.
This can be reproduced with the dummy driver on Windows and Linux.
Daniel Ribeiro Maciel
CMake is not adding src/core/linux/*.c to the build, linking to SDL results in errors:
(...)/libSDL2-2.0.so.1.0.1: undefined reference to `SDL_UDEV_AddCallback'
(...)/libSDL2-2.0.so.1.0.1: undefined reference to `SDL_UDEV_Poll'
(...)/libSDL2-2.0.so.1.0.1: undefined reference to `SDL_UDEV_Init'
(...)/libSDL2-2.0.so.1.0.1: undefined reference to `SDL_UDEV_Quit'
(...)/libSDL2-2.0.so.1.0.1: undefined reference to `SDL_UDEV_DelCallback'
(...)/libSDL2-2.0.so.1.0.1: undefined reference to `SDL_UDEV_Scan'
collect2: error: ld returned 1 exit status
Mai Lavelle
I've recently tried to create multiple windows and process key events for them, and found that key events weren't being generated for most of the windows. After some investigating I've observed the following effects. All but the most recently created window experience these effects...
- a focus lost event is generated immediately after the focus gained event, even tho window still has focus
- key events report window id 0 rather than the id of the window which has focus, SDL thinks no window has focus?
- giving focus to a non SDL window and then selecting an SDL window causes events to be generated as expected, but only until focus changes again
Focus change events are queued and delayed (200 ticks) before they are dispatched. The problem occurs when a focus out and focus in event are received on the same tick. When these delayed events are dispatched they will be sent in the order determined by the window list rather than the order in which they are received.
The focus out dispatch is implemented by calling SDL_SetKeyboardFocus(NULL). This will remove focus from any window, regardless of whether it is the one originally targeted by the X11 event.
Since SDL_SetKeyboardFocus() will always dispatch a focus lost event as needed, the easiest solution is simply to only call SDL_SetKeyboardFocus(NULL) when SDL_GetKeyboardFocus() matches the target window.
The first bug had mouse motion events not getting sent out on non-touch devices, if and when a mouse button wasn't pressed.
The second bug caused virtual mouse motion events to get sent out-of-order on touch devices: the motion event would get sent after the touch occurred, rather than before.
To enable the Debug Layer, set the hint, SDL_HINT_RENDER_DIRECT3D11_DEBUG to '1'.
The Debug Layer will be turned off by default, both in Release and Debug builds (of SDL).
Alex Szpakowski
I actually made a mistake when creating the previous patch file... I forgot to include a crucial line which changed.
I've attached a new patch which just changes the line I forgot, since the other part has already been applied to the repository.
I tested this one by doing a clean rebuild of SDL, and it works with the new patch.
J?nis R?cis
Reopening as compilation with ANSI C throws lots of unnecessary warnings, both using MinGW and using Linux GCC. (BTW, what happened? MinGW is broken to all hell. sdl2-config does not even link SDLMain anymore?)
I think this may have been lost somewhere, so again: GCC supports inlining via __inline__ in all known versions of GCC, regardless of the C standard in use. Please don't assume that __STRICT_ANSI__ implies no inlining support.
Nitz
I was going through the SDL_IntersectRectAndLine function and wondered to see the ComputeOutCode function implementation.
The problem in this algo is, x and y axis are getting check with respect to 0, Which is wrong, it should be get checked with respect to rectangle x and y axis.
C.W. Betts
The recommended way of getting a file name that POSIX file APIs can open in OS X when using an NSString is -[NSString fileSystemRepresentation]. However, the current filesystem API in hg uses -[NSString UTF8String].
Denis Bernard
Background information: http://developer.android.com/reference/android/hardware/SensorEvent.html#values
Steps to reproduce: compile testjoystick.c as an android app (change screen size according to your device). While running the app, also run:
adb logcat -c; adb logcat -s 'SDL:*' 'SDL/APP:*'
When tilting the device left/right, the joystick moves in the opposite direction of what one would expect. Or at least, the behaviour is not consistent with the Y axis.
Also when the device sits on a table (obviously not moving), the Z axis value oscillates between -32000 and +32000 (by overflow):
I/SDL/APP ( 1994): Joystick 0 axis 2 value: 32511
I/SDL/APP ( 1994): Joystick 0 axis 2 value: 32575
I/SDL/APP ( 1994): Joystick 0 axis 2 value: 32383
I/SDL/APP ( 1994): Joystick 0 axis 2 value: -32386
I/SDL/APP ( 1994): Joystick 0 axis 2 value: -32450
I/SDL/APP ( 1994): Joystick 0 axis 2 value: -32578
This is caused by the accelerometer yielding a constant value around 9.81 for Z and feeding something like 0.9 to 1.1 to the joystick driver, resulting in the overflow.
Proposed fix in SDLActivity.java (swap X and subtract G from Z reading)
Andreas Ertelt
The problem in question is caused by changeset 7771 (http://hg.libsdl.org/SDL/rev/5486e579872e / https://bugzilla.libsdl.org/show_bug.cgi?id=2121)
The redefinition of __inline__ (introduced by the addition of begin_code.h:128's "|| __STRICT_ANSI__") results in mingw's gcc throwing multiple
warning: always_inline function might not be inlinable [-Wattributes]
as well as a whole bunch of redefinitions of mingw internals which break linking of projects including the SDL2 headers.
manuel.montezelo
Since the bug report[1] in 2006 Debian is shipping the patch attached.
[1] http://bugs.debian.org/375822
Maybe nowadays you don't propagate that library for linking, so maybe the patch should be dropped, but at the moment I do not have an easy/quick way to check it.
So I am submitting this report in the case that you consider it useful (even if maybe the patch itself has to be reworked), or otherwise learn if the patch is unneeded or even harmful.
Sean McKean
I am running Ubuntu 12.04 (GL version 1.4 Mesa 8.0.4) , and on drawing a set of lines through the renderer through SDL_RenderDrawLines() (looped or not) or SDL_RenderDrawRect() I notice a pixel missing. For RenderDrawLines() it seems to be the second point in the sequence; for RenderDrawRect() it is the lower-right. This can be fixed by specifying SDL_RenderDrawPoint(s), but wouldn't it be easier to specify each pixel in a GL_POINTS glBegin/End loop in the OpenGL code, just to make sure?
I also ran the same program on Android; the rendering seemed to be correct, which uses glDrawArrays.
Kevin Wells
Overview:
SDL_RenderClear is only clearing part of a texture when it is the render target and a different size than the screen.
Steps to Reproduce:
1) This only occurs with the render driver set to direct3d, so: SDL_SetHint(SDL_HINT_RENDER_DRIVER,"direct3d")
Also, my window was 1280x720.
2) Create a texture for a render target with a resolution of 1024x1024:
texture=SDL_CreateTexture(main_window.renderer,SDL_PIXELFORMAT_RGBA8888,SDL_TEXTUREACCESS_TARGET,1024,1024);
SDL_SetTextureBlendMode(texture,SDL_BLENDMODE_BLEND);
3) Target the texture for rendering: SDL_SetRenderTarget(main_window.renderer,texture);
4) Set the draw color to whatever you want (problem occurs with both 0,0,0,0 and 0,0,0,255 among others) and then clear the render target:
SDL_SetRenderDrawColor(main_window.renderer,0,0,0,0);
SDL_RenderClear(main_window.renderer);
Actual Results:
Only about the top 3/4s of the texture gets cleared on calling SDL_RenderClear. The bottom 1/4 or so does not clear.
Expected Results:
Entire render target should be cleared.
Marcus von Appen
The autotools-based code uses X_CFLAGS and some hackish x_includes code to add some necessary includes to SDL_CFLAGS for proper X11 and OpenGL include handling.
At the moment, the cmake-baed build code does not do that. Below is a patch, which provides the necessary changes to add a proper include to the SDL_CFLAGS.
J?nis R?cis
Brief history:
We recently ported a game from SDL 1.2 to SDL 2. While doing Windows testing, I soon discovered that the game exits without opening a window with my cross-compiled SDL2.dll, but works great with the SDL2.dll from the MinGW SDK on libsdl.org. It was as simple as swapping out the DLLs to make it work.
Running the game in Wine showed that the game actually does run, up until the call to SDL_CreateWindow, which fails and leads the game to print out an error:
Failure to create window (LoadLibrary("OPENGL32.DLL"): (null))
Which basically says that there was no error, but maybe that's a Wine quirk.
The error string originates in SDL_windowsopengl.c, in WIN_GL_LoadLibrary, which contains this piece of code:
wpath = WIN_UTF8ToString(path);
_this->gl_config.dll_handle = LoadLibrary(wpath);
SDL_free(wpath);
if (!_this->gl_config.dll_handle) {
char message[1024];
SDL_snprintf(message, SDL_arraysize(message), "LoadLibrary(\"%s\")",
path);
return WIN_SetError(message);
}
After some digging, I discovered the culprit: WIN_UTF8ToString returns NULL. Why? Because it calls iconv_open from an iconv.dll that does not support the UCS-2-INTERNAL encoding. Why does the official SDL2.dll work? Because it calls no external iconv functions at all.
It turns out that the Fedora MinGW infrastructure (from which I obtained the conventiently prebuilt iconv.dll) does not provide a DLL from libiconv, but instead provides a DLL from a minimal Windows library called win-iconv. Which knows a good bit, but doesn't know anything about UCS-2-INTERNAL:
http://code.google.com/p/win-iconv/source/browse/trunk/win_iconv.c#155
So there are two problems here:
1) The error message is clearly useless, because LoadLibrary is an innocent bystander. Instead wpath should probably checked for NULL, and a more appropriate error should be set. Ideally something that makes it clear than an external iconv is causing trouble.
2) SDL doomed itself at the ./configure step, by finding an existing iconv and happily using it without confirming support for the mandatory encodings required by SDL.
There are certainly a few easy ways out of the situation (although I didn't yet manage to figure out how to prevent ./configure from looking for external iconv), but this had me completely stomped for a good while, so I figured it's worth writing down if anything.
(Search also found this, which talks a little about using UTF-16LE instead of UCS-2-INTERNAL: https://bugzilla.libsdl.org/show_bug.cgi?id=2075)
Denis Bernard
Background information: http://android-developers.blogspot.fr/2010/09/one-screen-turn-deserves-another.html and http://developer.android.com/reference/android/hardware/SensorEvent.html
Right now, the Android accelerometer event handler feeds raw accelerometer data to the SDL Joystick driver. The result is that for landscape-only applications, the axis need to be swapped if running on a portrait device (like a phone), and vice-versa: running a portrait only app on a landscape device like a tablet.
The purpose of this patch is to perform coordinate remapping of the accelerometer data before feeding it to the SDL joystick driver so that the X axis of the joystick is always aligned with the X axis of the display, same for the Y axis.
This has been tested on applications that support screen orientation changes as well as applications with fixed screen orientations, both on phones and tablets.
Andreas Ertelt
SDL_dxjoystick.c is setting the classguid for device (dis)connect events to USB Devices in general:
dbh.dbcc_classguid = GUID_DEVINTERFACE_USB_DEVICE;
Wouldn't it make more sense to have it just subscribe to Hid device events? This would mean less meaningless events reaching the application.
Marcus von Appen
Revision eecbcfed77c9 of the SDL hg repo introduces the new
SDL_GetSystemRAM() function, which breaks the build on FreeBSD. Find
attached a patch, which unbreaks the build and also should (for most
cases) properly implement the sysctl support it.
norfanin
Fixes the version check for some functions that are only present with the MSVC 2013 CRT libraries.
I did my testing wrong and failed to see that 2012 doesn't have these functions. Microsoft implemented them in their upcoming 2013 version, though. The attached patch changes it to the check for the next version.
I also removed the HAVE_ITOA because that would require linking with oldnames.lib and it's easier to just let the SDL implementation take over.
Joseph Carter
There's a whole set of configure tests for BSD's libusbhid, and they only matter on BSD. However, if you have the library on Linux, it gets pulled in as library bloat. And it's bloat of the highest order since not a single function call to the library is ever made unless you're on a *BSD.
Denis Bernard
This patch to Android.mk adds support for static linking of libSDL for Android applications. A patched readme with static build instructions is also provided.
It does not break existing build environments setup according to the README-android.txt since the static library version will not be built in not required.
The static build uses the Android NDK module system (see docs/IMPORT-MODULE.html in the NDK folder and step 5 in the instructions below).
Instructions:
1. Copy the android-project directory wherever you want to keep your projects
and rename it to the name of your project.
2. Create a symlink to SDL/src/main/android/SDL_android_main.c as
<project>/jni/src/SDL_android_main.c
3. Rename <project>/jni/src/Android_static.mk to <project>/jni/src/Android.mk
(overwrite the existing one)
4. Edit <project>/jni/src/Android.mk to include your source files
5. create and export an environment variable named NDK_MODULE_PATH that points
to the parent directory of this SDL directory. e.g.:
export NDK_MODULE_PATH="$PWD"/..
6. Edit <project>/src/org/libsdl/app/SDLActivity.java and remove the call to
System.loadLibrary("SDL2") line 42.
7. Run 'ndk-build' (a script provided by the NDK). This compiles the C source
Although this requires an environment variable to be setup, it can be added once and for all to the main Android.mk of the project.
T. Joseph Carter
As discussed (possibly to death), the Linux joystick driver does not actually report events for added or removed joysticks when you haven't got udev support.
We simply cannot know about removed joysticks without udev. But we can (and we should) report adding them. This brings the legacy case in line with pretty much the rest of SDL's joystick drivers.
This reverts http://hg.libsdl.org/SDL/rev/7cdeb64faa72 and fixes it in
the correct way. If you call SDL_SetWindowPosition on a fullscreen
window, it would update the x & y variables for the window, but not
actually move the window (since it was fullscreen). That would make the
internal state of the SDL_Window incorrect, causing
SDL_WarpMouseInWindow to offset incorrectly.
This makes it so SDL_SetWindowPosition updates the `windowed' x & y
coordinates, which take effect when you revert from fullscreen.
norfanin
Some of the tests keep using the pointers of a destroyed SDL_Window when the common event handling handled the close event. The event handler itself does not NULL the pointer after the destruction.
The attached patch adds a loop in the handler that will assign NULL to the destroyed window. It also adds checks to some of the tests so they skip those windows by checking for NULL.
On Android available touch devices are now added with video initialization (like
the keyboard). This fixes SDL_GetNumTouchDevices() returning 0 before any touch
events happened although there is a touch screen available. The adding of touch
devices after a touch event was received is still active to allow connecting
devices later (if this is possible) and to provide a fallback if the new init
did not work somehow. For the implementation JNI was used and API level 9 is
required. There seems to be nothing in the Android NDK's input header (input.h)
to implement everything on C side without communication with Java side.
This can break builds of existing SDL/WinRT apps. To fix, remove the reference to SDL_winrt_main.cpp, then add a reference to the renamed file, SDL_winrt_main_NonXAML.cpp. If you get a build error about a missing .winmd file, enable the /ZW compiler flag for that one file (at minimum).
1. remove references to SDL's project files from the Visual Studio Solution. To note, these project files have been renamed, and will show up in Visual Studio with the text, "load failed".
2. add the SDL project files back into the Visual Studio Solution
3. for each project that should link to SDL, add a reference to it. This can be done by right-clicking on it in Visual Studio, selecting "References...", clicking "Add New Reference", checking the box next to the SDL project, then closing each dialog by clicking OK.
SDL_mixer, SDL_ttf, and SDL_image for WinRT have been updated, and will be pushed to my Bitbucket repos with these changes having been made. If you do not pull in these changes, be sure to re-add to them the reference to the SDL project, as described above.
XAudio2 2.8's header file, xaudio2.h, doesn't compile in plain C code for WinRT
apps, not automatically at least. Initially, this file was adapted to compile
as C++, however these changes are now deprecated in favor of some preprocessor
based hacks that should get xaudio2.h to compile (while making sure XAudio2
still works).
This change should allow apps to render correctly in Portrait mode, at minimum,
Support for orientation changes is pending.
Thanks to Pierre-Yves for assistance!
This is part of an overall effort to use the name, "WinRT", rather than "WindowsRT" (or "Windows RT"), as the shorthand name often seems to mean something different than the longhand name. (WinRT is an API, Windows RT is a product name)
This change removes some code that attempted to allow non-standard window sizes, the idea of which was to do display scaling, and a hackish one at that. If display scaling is needed, use SDL_Renderer as appropriate.
- moved SDL_WinRTApp.* from src/video/windowsrt/ to src/core/winrt/, and renamed them to SDL_winrtapp.* (to mimick case-sensitivity used elsewhere in SDL)
- renamed all "windowsrt" directories (in src) to "winrt", as the shorthand name is used more often (and, IMO, "WinRT" != "Windows RT", not entirely at least)
norfanin
SetupWindowData in SDL_windowswindow.c doesn't initialize two members of SDL_WindowData with NULL. This is an issue because other parts of the SDL code seem to make the assumption that this is the case. WIN_DestroyWindowFramebuffer for example uses data->mdc and data->hbm if they're not NULL.
Lloyd Bryant
SDL_CreateTexture() is succeeding (i.e. returning a valid pointer) when the requested horizontal or vertical size of the texture exceeds the maximum allowed by the render. This results in hard-to-understand errors showing up when later attempting to use that texture (such as with SDL_SetRenderTarget()).
Added a reference to SDL_Direct3D9GetAdapterIndex to SDL_test_common.c so SDL will fail to compile if the new symbol isn't included properly.
CR: Jorgen
norfanin
Adds a condition so only the MSVC 2012 compiler defines the macros for the functions of its version.
Attaching a patch that adds a condition so that the HAVE_X supported by MSVC 2012 only get defined with that compiler. MSVC 2008 and 2010 will then build without any modification to the SDL source code.
Also moved HAVE_M_PI to a separate check. The Microsoft headers require _USE_MATH_DEFINES to be defined before they define the constants.
aBothe
I tried to experiment a bit with SDL2 and OpenGL today and noticed that something caused some weird flickering when resizing my nicely drawn SDL2/OpenGL window:
Just after resizing, the background went black and I had to let my OpenGL code redraw the contents..
However, after some hours spent with googling I found out that in OpenGL examples where this CWBackPixel flag was not used when creating X windows, there was no flickering while resizing the window.
See http://www.sbin.org/doc/Xlib/chapt_04.html @ "The Window Background" for more info.
# Date 1379621782 -3600
# Thu Sep 19 21:16:22 2013 +0100
Work around a false-positive in the X11 mouse wheel code
This false positive occurs when one particular button on my mouse is
pressed. The kernel which I'm using is patched to cause a release event to
be synthesised immediately when the mouse says that this button is pressed
because the mouse doesn't signal release until the button is next pressed.
(Also documents a false negative, observed with the horizontal scroll wheel
on the same mouse.)
X11_RestoreWindow() had a call ordering problem that prevented activation, and X11_RaiseWindow() wasn't attempting activation. Windows and OS X both activate in these cases.
CR: saml
SDL provides an SDL_VIDEO_X11_VISUALID environment variable that lets you override
window visuals, but it wasn't being checked for OpenGL windows.
CR: Sam.
We can't use _try/_except without the C runtime, and we can't use inline
asm with the Win64 compiler. We'll need to move this to an .asm file or
something later.
kikuchan
Some joysticks with high sampling rate need to be read() more fast,
otherwise it delay user inputs due to internal queue.
Especially, an app that issues SDL_PollEvent() not so frequent
Dmitry Marakasov
Unlike SDL_Rect (typedef struct SDL_Rect {} SDL_Rect), SDL_Point (typedef struct {} SDL_Point) structure is unnamed. This feels inconsistent and makes it impossible to use forward declaration for SDL_Point, having to include whole SDL_rect.h instead.
norfanin
When SDL_vsnprintf handles the %x format specifier, a boolean is set to signal forced lower case. It also should be able to signal forced upper case for the %X specifier. A boolean is not sufficient anymore. The attached patch adds an enum for the three cases: lower, upper and no change.
Pallav Nawani
This effects all SDL_Logxxx functions. On android, the debug output has a priority that is 1 higher than intended, ie, if you try SDL_LogInfo, the log has the priority of Warn instead.
SDL_syssem.c:159 comparison of unsigned expression >= 0 is always true
Solved by comparing unsigneds directly
SDL_systimer.c:164: warning: control may reach end of Compile
Solved by returning the default value if all else fails.
SDL_androidgl.c:41:1: warning: type specifier missing, defaults to 'int'
SDL_androidgl.c:47:1: warning: control reaches end of non-void function
Solved by adding void return type to the function implementation
Make it so XInput devices are listed before DirectInput devices, and that the XInput
devices are sorted by userid in ascending numeric order (so device 0 comes first).
Now multiple XInput controllers map correctly to device indexes instead of grabbing
the first available userid, and are completely separated out from DirectInput.
Also, the hardcoded limitation on number of DirectInput devices is gone. I don't
expect there to really ever be more than eight joysticks plugged into a machine, but
it was a leftover limitation for a static array we didn't actually use anymore.
Fixes Bugzilla #1984. (etc?)
If ac_x_libraries is empty it means that the library's found in the default path,
so we skip adding it to the XLIB variable as it screws up the search path.
- also adds OS X specific magic for bundled apps adding an Info.plist property of name SDL_FILESYSTEM_BASE_DIR_TYPE to the following values will change the bahaviour.
* bundle -- use the bundle directory e.g. "/Applications/MyGame/Blah.app/"
* parent -- use the bundle parent directory e.g. "/Applications/MyGame/"
* resource -- use the bundle resource directory (default) e.g. "/Applications/MyGame/Blah.app/Contents/Resources/"
- detect that you tried to open a gamecontroller in xinput mode and failed, then re-get the mapping for the dinput variant you did open (and most likely now just fail the open)
CR: SamL
This entire function is kind of a mess and more complicated than needed, but I don't want to refactor it too heavily tonight. May look at improving how the indexes are assigned more significanly later. The way it handles not finding a valid "gamepad" type device is also super broken, it leaves in place the xinput bindings but opens the controller with dinput and ends up with completely wrong mappings, not solving that now, but fixing the bug where we'd very frequently not find a controller due to gaps in assigned player numbers should mostly avoid it.
Andreas
The issue comes down to this line on MSDN:
"TranslateMessage produces WM_CHAR messages only for keys that are mapped to ASCII characters by the keyboard driver."
"WM_KEYDOWN and WM_KEYUP combinations produce a WM_CHAR or WM_DEADCHAR message. WM_SYSKEYDOWN and WM_SYSKEYUP combinations produce a WM_SYSCHAR or WM_SYSDEADCHAR message."
Except for WM_CHAR, none of these messages are used in SDL. Hence TranslateMessage should be dropped entirely and proper handling be included in the WM_KEYDOWN event.
Currently TranslateMessage is called for every message even if it must not be called in certain cases (like "An application should not call TranslateMessage if the TranslateAccelerator function returns a nonzero value.").
WM_CHAR message handling should remain for external processes posting these messages - additionally, WM_UNICHAR should be added.
I made a patch for src/video/windows/SDL_windowsevents.c that seems to work fine. It doesn't solve the "missing" composition for Khmer, but at least input for languages that cannot be mapped to ASCII characters (and for which IME is not used) will now work on Windows.
Jianyu Guan
I found I make a big mistake that when dstA==0, I just simply let *dstp=*srcp and forgot to make dstRGB = srcRGB*srcA.
The if consition "(*dstp & amask) == 0" in BlitRGBtoRGBPixelAlphaMMX and BlitRGBtoRGBPixelAlphaMMX3dNow should be removed.
I see the Remarks of function SDL_BlitSurface shows that "when SDL_BLENDMODE_BLEND, we have dstA = srcA + (dstA * (1-srcA))". however, I tested some pictures but the result implies "dstA=arcA" actually. I stepped into the source code, and found after I set SDL_BLENDMODE_BLEND for the source surface, the final blit function is BlitRGBtoRGBPixelAlphaMMX when I use SDL_BlitSurface on my computer. And I found these codes:
else if (alpha == amask) {
/* opaque alpha -- copy RGB, keep dst alpha */
*dstp = (*srcp & chanmask) | (*dstp & ~chanmask);
The same code is used in BlitRGBtoRGBPixelAlphaMMX3DNOW and BlitRGBtoRGBPixelAlpha. So I think they still keep dst alpha.
Best regards,
Jianyu Guan
If the app is in landscape mode and the user presses the power button, a pause
is followed immediately by a surfaceChanged event because the lock screen
is shown in portrait mode. This triggers a "false" resume.
So, we just pause and resume following the onWindowFocusChanged events.
Also, wait for SDL_APP_WILLENTERBACKGROUND and SDL_APP_DIDENTERBACKGROUND before
blocking the event pump.
Some more recent compilers emit SSE aligned store instructions for the loop,
causing crashes if the destination buffer isn't aligned on a 32-bit boundary.
This would also crash on platforms like ARM that require aligned stores.
This fixes a crash inside SDL_FillRect that happens with the official x64 mingw
build.
The Windows Phone 8.1 'MessageDialog' API only seems to support two buttons,
despite the documentation for such mentioning support for three. Trying to use
three or more buttons leads to an exception being thrown. As such, any attempt
to use more than two buttons via SDL_ShowMessageBox (on Windows Phone 8.1) will
lead to no message box getting shown, and the call returning an error.
The Win32 MessageBox and dialog APIs are not available in WinRT apps, to note.
More extensive message dialog support might be available at some point, if and
when XAML support is more fully fleshed-out. I'm not certain of this, though.
When a Windows Phone 8.0 app was rotated to anything but Portrait mode, touch
input coordinates, as well as virtual mouse coordinates, were usually getting
reported as coming from the wrong part of the screen.
If a Windows Phone 8.1 device was rotated to anything but Portrait mode,
the Direct3D 11 renderer's output wouldn't get aligned correctly with the
screen.
This change removes the "Shared" component from the Windows 8.1 and Windows
Phone 8.1 project files, then renames the projects to use a file structure
that's the same as used for the Windows 8.0 and Windows Phone 8.0 projects.
This change now places WinRT projects in the following directories:
VisualC-WinRT\WinRT81_VS2013\ -- Windows 8.1 project files
VisualC-WinRT\WinPhone81_VS2013\ -- Windows Phone 8.1 project files (NEW, as of this change)
VisualC-WinRT\WinRT80_VS2012\ -- Windows 8.0 project files
VisualC-WinRT\WinPhone80_VS2012\ -- Windows Phone 8.0 project files
Windows 8.0 and Windows Phone 8.0 projects, as well as apps or libs that
reference these, should be unaffected by this change.
Windows 8.1 and Windows Phone 8.1 based apps or libs that reference SDL's
projects directly will need to have their old references removed, then
replaced with new ones that point to the updated structure.
This is a step towards supporting "Universal" Windows apps, when building for
Windows Phone. SDL can now build against the Windows Phone 8.1 SDK, and apps
linked to it can run, however further work and testing is required as some
previously Phone-only code appears to no longer be applicable for
Windows Phone 8.1. The Windows 8.1 code paths does seem to be preferable, but
should probably be tested and updated on a finer-grained basis.
If in doubt, use the Windows Phone 8.0 projects for now, as located in
VisualC-WinRT/WinPhone80_VS2012/
TODO:
- look at any Windows Phone specific code paths in SDL, and see if Phone 8.1
should use the Windows Phone code path(s), or the Windows 8.x or 8.1 paths
The Win32 APIs, VerifyVersionInfoW and VerSetConditionMask, are not currently
available for use in WinRT apps. This change primarily #if[n]defs-out some
calls to them.
This commit also includes some base-level support for Universal apps.
TODO:
- add support for Windows Phone 8.1
- add support for satellite libs: SDL_image, SDL_ttf, and SDL_mixer
Setting the tag type will let libtool work even when it cannot infer
the type of the code being built. One way libtool may fail to infer
the tag type is if one uses a mock compiler (such as for static
analysis).
This allows the joystick hotplug to function without the main event loop
(specifically: without SDL_INIT_VIDEO), and moves explicit polling for
joysticks where it belongs at the low-level: in SDL_SYS_JoystickDetect().
This lets apps call SDL_JoystickUpdate() to get hotplug events and keep
SDL_NumJoysticks() correct, as expected. As SDL_PumpEvents() (and
SDL_PollEvents, etc) calls SDL_JoystickUpdate(), existing apps will function
as before.
Thanks to "raskie" on the forums for pointing this out!
This fixes a bug where we'd offset positions by the height of the dock, if it
was along the bottom of the screen.
Fixes https://bugzilla.libsdl.org/show_bug.cgi?id=2509
Thanks to Alex Szpakowski for bug & patch.
It used to be that SDL_SetWindowPosition was relative to the top of the screen,
which didn't make sense. In addition, borderless windows can be positioned
*below* the menubar, so SDL_SetWindowPosition(win, 0, 0) on a borderless window
would hide ~30ish pixels of the window below the menubar.
This fixes an issue where an empty cliprect is treated the same as a NULL
cliprect, causing the render backends to disable clipping.
Also adds a new API, SDL_RenderIsClipEnabled(render) that allows you to
differentiate between:
- SDL_RenderSetClipRect(render, NULL)
- SDL_Rect r = {0,0,0,0}; SDL_RenderSetClipRect(render, &r);
Fixes https://bugzilla.libsdl.org/show_bug.cgi?id=2504
All WinRT projects have been merged into a single directory, "VisualC-WinRT",
with platform-specific variants in subdirectories off of it. This structure
has been applied to a few major SDL satellite libraries as well (SDL_image,
SDL_mixer, and SDL_ttf).
Currently, only Windows 8.0/RT and Windows Phone 8.0 targets are supported.
Windows 8.1/RT/Phone targets are planned.
Projects that use SDL_image/WinRT, and link to it via Visual Studio's
project-to-project reference system, will need to be updated, to reflect the
changes in the project structure. This can be done by:
1. removing the MSVC project(s) for SDL/WinRT
2. re-added the MSVC project(s) for SDL/WinRT
3. right-clicking on the app, or projects that use those libraries, choosing
References, removing the references to any of these projects (they'll likely
be highlighted with an exclamation mark), then re-adding them
To note, the satellite libraries that reference SDL/WinRT have been updated
already. The changes for those libraries will be pushed to hg.libsdl.org
shortly.
TODO:
- add support for Windows 8.1 and Windows Phone 8.1 targets, using
Microsoft's new "Universal" app support, if possible. These will be added to
a new subdirectory, or subdirectories (if more than one sets of projects are
needed, hopefully not), of "VisualC-WinRT".
- investigate NuGet support, which could allow Visual C++ to download
new copies of SDL/WinRT, its satellite libraries, and their dependencies,
from remote servers.
It's picking up the system headers instead of the RPi build files.
Theoretically, we _can_ support Wayland on this platform, though, as there
_is_ a Raspberry Pi port out there...
Thomas Schatz
The dynamic library (extracted from SDL2-2.0.3.dmg and put in /Library/Frameworks/) references the __Block_copy symbol in /usr/lib/libSystem.B.dylib, which cannot be found:
dlopen(/Library/Frameworks/SDL2.framework/SDL2, 6): Symbol not found: __Block_copy
Referenced from: /Library/Frameworks/SDL2.framework/SDL2
Expected in: /usr/lib/libSystem.B.dylib
From what I could gather __Block_copy seems to be related to the blocks extension to the C programming language introduced by Apple since OSX-10.6 (see: http://thirdcog.eu/pwcblocks/). If this is indeed the case, I don't think the SDL2-2.0.3.dmg on the website is at all compatible with OSX-10.5 countrary to what is announced.
cplu
When I double click on a window, the "clicks" field (newly added since 2.0.2) in SDL_MouseButtonEvent is 1 instead of 2.
However, when I "tripple" click, "clicks" field is then 2.
I'v look into the source code in SDL_windowsevents.c and found that when a double click event comes, WIN_WindowProc will get a WM_LBUTTONDBLCLK msg. The message sequence of a double click is:WM_LBUTTONDOWN->WM_LBUTTONUP->WM_LBUTTONDBLCLK->WM_LBUTTONUP.
Bryan Cain
Using any SDL application with the Wayland backend under Weston, if the application sets a cursor with SDL_SetCursor, the cursor will work until the mouse pointer leaves the window. When the pointer re-enters the window, there will be no cursor displayed at all.
I did some digging, and the reason for this is that SDL attaches the buffer to the cursor surface only once (during cursor creation) and assumes that it will stay attached. This is not how Wayland works, though - once the compositor is done rendering the buffer, it will release it, so it is no longer attached to the surface. When the cursor re-enters the window a second time, SDL sets the cursor to the same surface with no buffer attached, so no cursor is displayed.
This is fixed by the attached patch, which makes SDL attach the buffer to the surface when the cursor is set, not when it is created.
Bryan Cain
Wayland_CreateSystemCursor tries to load a cursor named "wait" for two of the system cursor categories. This causes a segmentation fault when one of these cursors is used, because "wait" is not an actual cursor name in X11/Wayland cursor themes.
I can't attach my patch since I'm on a mobile right now, but I can confirm that simply replacing "wait" with "watch" for both of its uses in Wayland_CreateSystemCursor (in SDL_waylandmouse.c) fixes the bug.
Ashley Whetter
RHEL6 and CentOS6 systems still use an old version of udev (147). It wasn't until udev 148 (Yep. 1 version off!) that the input class system changed from "ID_CLASS" to "ID_INPUT_{JOYSTICK,KEYBOARD,MOUSE,etc}" (http://lwn.net/Articles/364728/). Because SDL2 looks for the ID_INPUT_X field this means that it never detects any input devices on RHEL6 systems.
I've attached a patch which fixes the problem. If no input devices are detected with "ID_INPUT_X" then SDL will fallback to looking for the old style "ID_CLASS" udev field instead.
Because of the "big change" between udev versions I doubt it'll ever get upgraded on RHEL6, but because RHEL7 is on the way I don't know if this patch is worth merging. Hopefully it'll help anyone out that's having this problem though.
Sylvain
Someone provided a patch for this, recently on the mailing list :
-----
Hi,
it is possible to skip the bug in libX11 by using the defaults for
XNResourceName and XNResourceClass in `XCreateIC' (the table for the
"Input Context Values" [1] in libX11-doc shows that a default is
provided if it is not set).
diff -ur SDL2-2.0.3~/src/video/x11/SDL_x11window.c SDL2-2.0.3/src/video/x11/SDL_x11window.c
--- SDL2-2.0.3~/src/video/x11/SDL_x11window.c 2014-04-04 17:09:40.764307181 +0200
+++ SDL2-2.0.3/src/video/x11/SDL_x11window.c 2014-04-04 17:10:23.887765046 +0200
@@ -239,8 +239,7 @@
data->ic =
X11_XCreateIC(videodata->im, XNClientWindow, w, XNFocusWindow, w,
XNInputStyle, XIMPreeditNothing | XIMStatusNothing,
- XNResourceName, videodata->classname, XNResourceClass,
- videodata->classname, NULL);
+ NULL);
}
#endif
data->created = created;
Tito Latini
[1] http://www.x.org/releases/X11R7.7-RC1/doc/libX11/libX11/libX11.html#Input_Context_Values
Lasse ??rni
While enabling $1 gesture support in the Urho3D engine which uses SDL2 I detected some errors in the gesture code in SDL_gesture.c:
- In the function SDL_SaveAllDollarTemplates() the following line should use index variable j instead of i:
rtrn += SaveTemplate(&touch->dollarTemplate[i], dst);
- In the function SDL_SaveDollarTemplate() the following code should use index variable j instead of i:
if (touch->dollarTemplate[i].hash == gestureId) {
return SaveTemplate(&touch->dollarTemplate[i], dst);
- In the function SDL_SendGestureDollar() the x & y coordinates are being written to the mgesture structure, which results in garbage due to dgesture and mgesture being different data structures inside the union. The coordinates should be written to dgesture.x & dgesture.y respectively
Changes included:
- adding support for a few, additional, VirtualKey constants
- removing accesses to 'windows_scancode_table', as the table's contents
don't line up with WinRT virtual keys. Using Windows older VK_* constants
may, however, be a good alternative in a future update.
* Added cross-platform Vulkan graphics support in SDL_vulkan.h
SDL_Vulkan_LoadLibrary()
SDL_Vulkan_GetVkGetInstanceProcAddr()
SDL_Vulkan_GetInstanceExtensions()
SDL_Vulkan_CreateSurface()
SDL_Vulkan_GetDrawableSize()
SDL_Vulkan_UnloadLibrary()
This is all the platform-specific code you need to bring up Vulkan on all SDL platforms. You can look at an example in test/testvulkan.c
* Added SDL_ComposeCustomBlendMode() to create custom blend modes for 2D rendering
* Added SDL_HasNEON() which returns whether the CPU has NEON instruction support
* Added support for many game controllers, including the Nintendo Switch Pro Controller
* Added support for inverted axes and separate axis directions in game controller mappings
* Added functions to return information about a joystick before it's opened:
SDL_JoystickGetDeviceVendor()
SDL_JoystickGetDeviceProduct()
SDL_JoystickGetDeviceProductVersion()
SDL_JoystickGetDeviceType()
SDL_JoystickGetDeviceInstanceID()
* Added functions to return information about an open joystick:
SDL_JoystickGetVendor()
SDL_JoystickGetProduct()
SDL_JoystickGetProductVersion()
SDL_JoystickGetType()
SDL_JoystickGetAxisInitialState()
* Added functions to return information about an open game controller:
SDL_GameControllerGetVendor()
SDL_GameControllerGetProduct()
SDL_GameControllerGetProductVersion()
* Added SDL_GameControllerNumMappings() and SDL_GameControllerMappingForIndex() to be able to enumerate the built-in game controller mappings
* Added SDL_LoadFile() and SDL_LoadFile_RW() to load a file into memory
* Added SDL_DuplicateSurface() to make a copy of a surface
* Added an experimental JACK audio driver
* Implemented non-power-of-two audio resampling, optionally using libsamplerate to perform the resampling
* Added the hint SDL_HINT_AUDIO_RESAMPLING_MODE to control the quality of resampling
* Added the hint SDL_HINT_RENDER_LOGICAL_SIZE_MODE to control the scaling policy for SDL_RenderSetLogicalSize():
"0" or "letterbox" - Uses letterbox/sidebars to fit the entire rendering on screen (the default)
"1" or "overscan" - Will zoom the rendering so it fills the entire screen, allowing edges to be drawn offscreen
* Added the hints SDL_HINT_MOUSE_NORMAL_SPEED_SCALE and SDL_HINT_MOUSE_RELATIVE_SPEED_SCALE to scale the mouse speed when being read from raw mouse input
* Added the hint SDL_HINT_TOUCH_MOUSE_EVENTS to control whether SDL will synthesize mouse events from touch events
Windows:
* The new default audio driver on Windows is WASAPI and supports hot-plugging devices and changing the default audio device
* The old XAudio2 audio driver is deprecated and will be removed in the next release
* Added hints SDL_HINT_WINDOWS_INTRESOURCE_ICON and SDL_HINT_WINDOWS_INTRESOURCE_ICON_SMALL to specify a custom icon resource ID for SDL windows
* The hint SDL_HINT_WINDOWS_DISABLE_THREAD_NAMING is now on by default for compatibility with .NET languages and various Windows debuggers
* Updated the GUID format for game controller mappings, older mappings will be automatically converted on load
* Implemented the SDL_WINDOW_ALWAYS_ON_TOP flag on Windows
Linux:
* Added an experimental KMS/DRM video driver for embedded development
iOS:
* Added a hint SDL_HINT_AUDIO_CATEGORY to control the audio category, determining whether the phone mute switch affects the audio
Open the package contents of the older Xcode and your newer version of Xcode and copy over the folders in Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport
Then open the file Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/SDKSettings.plist and add the versions of iOS you want to deploy to the key Root/DefaultProperties/DEPLOYMENT_TARGET_SUGGESTED_VALUES
Open your project and set your deployment target to the desired version of iOS
Finally, remove GameController from the list of frameworks linked by your application and edit the build settings for "Other Linker Flags" and add -weak_framework GameController
SDL has support for OpenGL ES 2.x under Windows via two alternative
implementations.
The most straightforward method consists in running your app in a system with
a graphic card paired with a relatively recent (as of November of 2013) driver
which supports the WGL_EXT_create_context_es2_profile extension. Vendors known
to ship said extension on Windows currently include nVidia and Intel.
The other method involves using the ANGLE library (https://code.google.com/p/angleproject/)
If an OpenGL ES 2.x context is requested and no WGL_EXT_create_context_es2_profile
extension is found, SDL will try to load the libEGL.dll library provided by
ANGLE.
To obtain the ANGLE binaries, you can either compile from source from
https://chromium.googlesource.com/angle/angle or copy the relevant binaries from
a recent Chrome/Chromium install for Windows. The files you need are:
* libEGL.dll
* libGLESv2.dll
* d3dcompiler_46.dll (supports Windows Vista or later, better shader compiler)
or...
* d3dcompiler_43.dll (supports Windows XP or later)
If you compile ANGLE from source, you can configure it so it does not need the
d3dcompiler_* DLL at all (for details on this, see their documentation).
However, by default SDL will try to preload the d3dcompiler_46.dll to
comply with ANGLE's requirements. If you wish SDL to preload d3dcompiler_43.dll (to
support Windows XP) or to skip this step at all, you can use the
SDL_HINT_VIDEO_WIN_D3DCOMPILER hint (see SDL_hints.h for more details).
Known Bugs:
* SDL_GL_SetSwapInterval is currently a no op when using ANGLE. It appears
that there's a bug in the library which prevents the window contents from
refreshing if this is set to anything other than the default value.
Vulkan Surface Support
==============
Support for creating Vulkan surfaces is configured on by default. To disable it change the value of `SDL_VIDEO_VULKAN` to 0 in `SDL_config_windows.h`. You must install the [Vulkan SDK](https://www.lunarg.com/vulkan-sdk/) in order to use Vulkan graphics in your application.
Copyright (C) 1997-2016 Sam Lantinga <slouken@libsdl.org>
Copyright (C) 1997-2017 Sam Lantinga <slouken@libsdl.org>
This software is provided 'as-is', without any express or implied
warranty. In no event will the authors be held liable for any damages
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
