Sylvain
Re-opening this issue.
It fixes the test-case, but it introduces a regression with another bug (bug #4313).
So here's a new patch that activate cropping of the source surface to solve the issue.
It also reverts the wrong changeset.
It prevents unneeded colorkey error message.
Otherwise, we are using the allocator before the app can set up its own hooks.
Now we use VirtualAlloc, and WideCharToMultiByte (because SDL_iconv uses
SDL_malloc, too!) to get ready to call into SDL_main.
This also makes console_wmain() call into the same routines as everything
else, so we don't have to deal with those allocations, too. Hopefully we
end up with the same results from GetCommandLine() as we do in wargv.
Fixes Bugzilla #4340.
Include guards in most changed files were missing, I added them keeping
the same style as other SDL files. In some cases I moved the include
guards around to be the first thing the header has to take advantage of
any possible improvements compiler may have for inclusion guards.
If we run into problems where these events aren't dispatched (initialized on a different thread than the main thread?) we may need to create a separate thread to handle device notifications like we do with the windows joystick subsystem.
If you enable this, you'll need to link with CoreBluetooth.framework and add something like this to your Info.plist:
<key>NSBluetoothPeripheralUsageDescription</key>
<string>MyApp would like to remain connected to nearby bluetooth Game Controllers and Game Pads even when you're not using the app.</string>
It needs to use Bool (which is an int) and not BOOL (which is CARD8), which
causes problems on platforms with different byte order and alignment, etc.
Fixes Bugzilla #4326.
Dominik Reichardt
Xcode warns about
"Traditional headermap style is no longer supported; please migrate to using separate headermaps and set 'ALWAYS_SEARCH_USER_PATHS' to NO."
Just doing the latter is enough to silence the warning without ill effects on compiling. This affects the macOS Xcode projects as well as the iOS projects. Definitely not a bug but an annoying warning that could go away.
Otherwise if SDL_POWER_DISABLED is disabled (eg with --disable-power):
... with clang -pedantic:
src/power/SDL_power.c:48:50: warning: use of GNU empty initializer extension [-Wgnu-empty-initializer]
static SDL_GetPowerInfo_Impl implementations[] = {
^
src/power/SDL_power.c:48:50: warning: zero size arrays are an extension [-Wzero-length-array]
2 warnings generated.
... with gcc -pedantic:
src/power/SDL_power.c:48:50: warning: ISO C forbids empty initializer braces [-Wpedantic]
src/power/SDL_power.c:48:50: warning: ISO C forbids empty initializer braces [-Wpedantic]
static SDL_GetPowerInfo_Impl implementations[] = {
^
src/power/SDL_power.c:48:30: error: zero or negative size array ?implementations?
static SDL_GetPowerInfo_Impl implementations[] = {
^~~~~~~~~~~~~~~
... with Watcom:
./src/power/SDL_power.c(85): Error! E1112: Initializer list cannot be empty
Creating a full-screen SDL renderer on Windows will keep the screensaver
suspended by DirectX, as is default for full-screen DX applications. However,
for applications that render in windowed-mode, the screensaver will
still kick in, even if SDL_DisableScreenSaver() is called or
SDL_HINT_VIDEO_ALLOW_SCREENSAVER is set to 0 (default). Implementing
a SuspendScreenSaver() function for Win32 fixes this behavior.
This means that if you have two devices named "Soundblaster Pro" in your
machine, one will be reported as "Soundblaster Pro" and the other as
"Soundblaster Pro (2)".
This makes it so you can't into a position where one of your devices can't
be opened because another is sitting on the same name.
duckgrease
SDL_RenderCopyEx blits wrong image (in some cases it's bunch of alternating horizontal lines, some cases it's image from the wrong coordinate, and in some cases it's just a bunch of garbled pixels), when the following conditions are met:
- Use software renderer.
- Enable either horizontal or vertical flip.
- source and destination rectangles must have same width and height, and must be smaller than the size of the texture.
- source rectangle's X and Y coordinates must be 0.
Icenowy Zheng
One front buffer is locked in GLES_SetupCrtc() and overrides the next_bo just locked in KMSDRM_GLES_SwapWindow, then the next_bo gets lost and is not released even when quitting the video.
It may leads to problems with GLES drivers that doesn't clean up GBM correctly if there's any bo left (e.g. the Mali Utgard r6p2 blob). In the case of Mali Utgard r6p2 blob, the DRM device file is still hold by the blob, and if you try to SDL_Quit to let another program to run (this is done by EmulationStation), the new program will fail to open DRM device.
This fixes issues for applications that have a large number of shared libraries
For more information, see https://github.com/KeepSafe/ReLinker for ReLinker's repository.
Sylvain
I did various benches. with clang 6.0.0 on linux, and ndk-r16b on android (NDK_TOOLCHAIN_VERSION=clang).
- still see a x10 speed factor.
- with duff_loops, it does not use vectorisation (but doesn't seem to be a problem).
on linux my patch is already at full speed on -O2, whereas the duff_loops need -O3 (200 ms at -03, and 300ms at -02).
I realized that on Android, I had a slight variation which fits best.
both on linux with -O2 and -O3, and on android with 02/03 and armeabi-v7a/arm64.
Here's the patch.
suffix to the temp Pixel local in the DUFFS_LOOP.
SDL_blit.h (ASSEMBLE_RGB): add _ prefix to temp Pixel locals to avoid
any possible shadowings.
The warnings were like the following:
In file included from src/video/SDL_blit_N.c:26:0:
src/video/SDL_blit_N.c: In function 'BlitNtoNKeyCopyAlpha':
src/video/SDL_blit_N.c:2421:24: warning: declaration of 'Pixel' shadows a previous local [-Wshadow]
Uint32 Pixel = ((*src32 & rgbmask) == ckey) ? *dst32 : *src32;
^
src/video/SDL_blit.h:475:21: note: in definition of macro 'DUFFS_LOOP8'
case 0: do { pixel_copy_increment; /* fallthrough */ \
^
src/video/SDL_blit_N.c:2419:13: note: in expansion of macro 'DUFFS_LOOP'
DUFFS_LOOP(
^
src/video/SDL_blit_N.c:2399:12: warning: shadowed declaration is here [-Wshadow]
Uint32 Pixel;
^
Author: Anthony Pesch <inolen@gmail.com>
Date: Fri May 4 20:21:21 2018 -0400
Added SDL_AUDIO_ALLOW_SAMPLES_CHANGE flag enabling users of SDL_OpenAudioDevice to get
the sample size of the actual hardware buffer vs having a stream created to handle the
delta
From Tom Black:
I'm having problems initializing the sensor module. I'm compiling with a standard ./configure && make && sudo make install, and the module says it's enabled, but SDL_Init(SDL_INIT_EVERYTHING) is failing with SDL_GetError() returning "SDL not built with sensor support".
Author: Micha? Janiszewski <janisozaur+signed@gmail.com>
Date: Fri Sep 28 20:38:04 2018 +0200
CMake: fix building tests on Linux
In case where libunwind.h has been found, it will be used by compiler,
but linker wasn't updated to reflect use of this new library.
it used to place zeroes between the sign and the number. (space-padding
from within SDL_PrintString() seems OK: spaces are added before sign.)
also fixed the maxlen handling if the number has a sign.
add HAVE_ENDPOINTVOLUME_H, HAVE_MMDEVICEAPI_H and HAVE_AUDIOCLIENT_H
in SDL_config.h.in, SDL_config.h.cmake, SDL_config_windows.h, and in
SDL_config_winrt.h.
Sylvain
Patch a few warnings when using:
-Wmissing-prototypes -Wdocumentation -Wdocumentation-unknown-command
They are automatically enabled with -Wall
- remove force-enabling of pad_zeroes for %u for compatibility
(was added in https://hg.libsdl.org/SDL/rev/701f4a25df89)
- ignore pad_zeroes for %s and %S
- ignore pad_zeroes for %d, %i and %u if a precision is given
Alexei
On WM_WINDOWPOSCHANGED event, WIN_UpdateClipCursor() is called. SDL_WINDOW_INPUT_FOCUS is set even when the mouse pointer is not inside the SDL window and therefore ClipCursor(&rect) is called. When dragging the window and rect.bottom=800 (i.e. the bottom edge of the screen) the SDL window is clipped to the bottom of the screen and it is not possible to move it back to the center of the screen.
Anthony @ POW Games
SDL_CreateTextureFromSurface makes an internal call to SDL_GetColorKey which can return an error and spams the error log with "Surface doesn't have a colorkey" even though the original function didn't return an error.
Wayde Reitsma
After attempting to use SDL2 in the way described in this bug, I found the main issue was the includes not being added to the compiler command.
I found the issue was that the target_include_directories commands for the SDL2, SDL2-static and SDL2main targets only sets the public includes for installations using the INSTALL_INTERFACE generator expression.
I have written a patch to CMakeLists.txt that fixes this issue by adding another item to the target_include_directories commands, utilizing the BUILD_INTERFACE generator expression to correctly add the include directory during builds.
src/joystick/hidapi/SDL_hidapijoystick.c: In function 'HIDAPI_InitializeDiscovery':
src/joystick/hidapi/SDL_hidapijoystick.c:281: error: 'true' undeclared (first use in this function)
src/joystick/hidapi/SDL_hidapijoystick.c:281: error: (Each undeclared identifier is reported only once
src/joystick/hidapi/SDL_hidapijoystick.c:281: error: for each function it appears in.)
src/joystick/hidapi/SDL_hidapijoystick.c: In function 'HIDAPI_UpdateDiscovery':
src/joystick/hidapi/SDL_hidapijoystick.c:339: error: 'true' undeclared (first use in this function)
src/joystick/hidapi/SDL_hidapijoystick.c:341: error: ISO C90 forbids mixed declarations and code
Sylvain
The issue is totally reproducible on P8 Lite.
"The dlopen() call doesn't include the app's native library directory. The behavior of dlopen() by Android is not guaranteed".
Workaround in getMainSharedObject()
Just replace
return library;
with
return getContext().getApplicationInfo().nativeLibraryDir + "/" + library;
src/core/linux/SDL_evdev.c:104:1: warning: "_THIS" redefined
In file included from src/core/linux/../../events/SDL_events_c.h:26,
from src/core/linux/SDL_evdev.c:45:
src/core/linux/../../events/../video/SDL_sysvideo.h:146:1: warning: this is the location of the previous definition
Alexandre
DirectFB supports 32-bit ABGR pixel format via DSPF_ABGR, but SDL doesn't map SDL_PIXELFORMAT_ABGR8888 to DSPF_ABGR.
A patch is attached and should add support for ABGR pixel format devices.
The only place angle is activated and causes effect is RenderCopyEx. All other
methods which use vertex shader, leave angle disabled and cause useless sin/cos
calculation in shader.
To get around shader's interface is changed to a vector that contains results
of sin and cos. To behave properly when disabled, cos value is set with offset
-1.0 making 0.0 default when deactivated.
As nice side effect it simplifies GLES2_UpdateVertexBuffer: All attributes are
vectors now.
Additional background:
* On RaspberryPi it gives a performace win for operations. Tested with
[1] numbers go down for 5-10% (not easy to estimate due to huge variation).
* SDL_RenderCopyEx was tested with [2]
* It works around left rotated display caused by low accuracy sin implemetation
in RaspberryPi/VC4 [3]
[1] https://github.com/schnitzeltony/sdl2box
[2] https://github.com/schnitzeltony/sdl2rendercopyex
[3] https://github.com/anholt/mesa/issues/110
Signed-off-by: Andreas M?ller <schnitzeltony@gmail.com>
This prevents us from clearing the clip rect globally when another application has set it.
There's also an experimental change to regularly update the clip rect for a window defensively, in case someone else has reset it. It works well, but I don't know if it's cheap enough to call as frequently as it would be called now, and might have other undesirable side effects.
Also fixed whitespace and SDL coding style
C.W. Betts
This cleans up the Xcode project by setting the Xcode groups to the corresponding directories. This also removes the Resources folder in OS X's Products group and adds the CoreBluetooth framework to the iOS tests (this is needed due to the addition of hidapi.
The code is now reliant on SDL_PrivateJoystickAdded() and SDL_PrivateJoystickRemoved() being called correctly when devices are added or removed on Windows
"In release 2.0.6, when Linux evdev keyboard support has been moved to a
separate source file, a feature was added to disable normal keyboard event
processing to prevent "spilling" keystrokes to background virtual console.
This feature has one unpleasant side effect: if application fails to call
`SDL_Exit` before termination or crashes with fatal signal, console is left
in unusable state with keyboard not working and no possibility to switch
virtual console. If user has a chance, he can login remotely and restore
keyboard with `kbd_mode`, otherwise the only option is to reboot the machine.
This patch fixes that problem by intercepting fatal signals (with `sigaction`)
and process termination (with `atexit`), to restore keyboard state, if it
wasn't properly restored with `SDL_Exit`.
The function registered with `atexit` also restores original signal handlers,
to prevent leaving invalid handlers after SDL library is unloaded, if it was
loaded dynamically with `dlopen`.
No signal handlers or `atexit` function are installed if SDL boolean hint
`SDL_HINT_NO_SIGNAL_HANDLERS` is `SDL_TRUE`.
Additionally, if environment variable `SDL_INPUT_LINUX_KEEP_KBD` exists,
keyboard initialization function completely skips disabling keyboard. This
can be useful for debugging."
Fixes Bugzilla #4193.
This would cause problems in various ways, but specifically triggers an
assert when you close a WASAPI capture device in an app running over RDP.
Related to (but not the actual bug) in Bugzilla #3924.
SDL_UDEV_Scan must be called during SDL_SYS_HapticInit to ensure devices
outside of the 0-31 range are added to the list of haptic devices.
Fixes Bugzilla #3923.
First: disable d'n'd events by default; most apps don't need these at all, and
if an app doesn't explicitly handle these, each drop on the window will cause
a memory leak if the events are enabled. This follows the guidelines we have
for SDL_TEXTINPUT events already.
Second: when events are enabled or disabled, signal the video layer, as it
might be able to inform the OS, causing UI changes or optimizations (for
example, dropping a file icon on a Cocoa app that isn't accepting drops will
cause macOS to show a rejection animation instead of the drop operation just
vanishing into the ether, X11 might show a different cursor when dragging
onto an accepting window, etc).
Third: fill in the drop event details in the test library and enable the
events in testwm.c for making sure this all works as expected.
Parse out a copy of the varargs ourselves to get to the reply portion, since
the original passed to D-Bus might modify or not modify the caller's copy,
depending on system ABI.
At the HG state abdd17144682, 64-bit assemblies are using SSE2-based resampler, produces junk sound when converting the S32 -> Float32 -> S16 chain. The `NEED_SCALAR_CONVERTER_FALLBACKS` thing works perfectly.
If I will find a reason that caused this mistake, I'll send a patch by myself.
Now you don't need the latest Wayland installed to build with
newer protocols supported, as they'll build correctly; even if
your system can't use them, we can make intelligent decisions
at runtime about what's available on the current machine anyhow.
This also simplifies some logic and possible failure cases in
the configure and CMake scripts.
Fixes Bugzilla #4207.
This is just in parity with the existing zxdg-shell-unstable-v6 code. Making
the Wayland target robust (and uh, with title bars) is going to take a lot
of work on top of this.
The previous code attempted to use set_buffer_size / set_period_size
discretely, favoring the parameters which generated a buffer size that was
exactly 2x the requested buffer size. This solution ultimately prioritizes
only the buffer size, which comes at a large performance cost on some machines
where this results in an excessive number of periods. In my case, for a 4096
sample buffer, this configured the device to use 37 periods with a period size
of 221 samples and a buffer size of 8192 samples. With 37 periods, the SDL
Audio thread was consuming 25% of the CPU.
This code has been refactored to use set_period_size and set_buffer_size
together. set_period_size is called first to attempt to set the period to
exactly match the requested buffer size, and set_buffer_size is called second
to further refine the parameters to attempt to use only 2 periods. The
fundamental change here is that the period size / count won't go to extreme
values if the buffer size can't be exactly matched, the buffer size should
instead just increase to the next closest multiple of the target period size
that is supported. After changing this, for a 4096 sample buffer, the device
is configured to use 3 periods with a period size of 4096 samples and a buffer
size of 12288 samples. With only 3 periods, the SDL Audio thread doesn't even
show up when profiling.
Fixes Bugzilla #4156.
Fixes CMake not being able to find X11 on FreeBSD (which generally has the
headers in /usr/local/include/X11).
List of other popular places borrowed from CMake's FindX11 module.
This worked on the configure script because of magic in the AC_PATH_X macro.
Fixes Bugzilla #4815.
"Applications (such as SDL's testgesture) do "event.tfinger.x * window_width"
to find window coord. Currently the X11 XInput2 backend expects application
to do "event.tfinger.x * (window_width-1)" instead.
X11 XInput2 touch events are normalized so x is 1.0 at "width - 1" but other
SDL backends appear to have x be 1.0 at "width". Same issue for touch event
y with regards to height."
Fixes Bugzilla #4183.
If we change the current context behind the app's back, those tracking
the current context to minimize context changes are going to get
confused.
This brings the EGL backend in line with the GLX one.
Fixes Bugzilla #4199.
This was reproducible by running an SDL app on the console from an ssh login. In this case the terminal wasn't owned by the user running the app, so we were using the default keymap, which didn't have state transitions defined for ctrl and alt, so once we entered that state keypresses would no longer transition out of that state, nor would they generate text.
As a workaround, we'll just reset to the default shift state if that happens, which means we'll get text for keys pressed while ctrl is held down, but I don't think that's a big problem.
Note that in this case we also can't mute the keyboard, so the keypresses go to the console, which probably isn't what you want...
SDL_ExitProcess(), SDL_AbortAssertion() and SDLTest_BailOut().
(Commit 303c1e0fb0cf for bug #4100 removed SDL_NORETURN from
SDL_ExitProcess() and SDL_AbortAssertion() in order to avoid
warnings from windows builds, but that's temporary I guess..)
These are entirely untested
Several USB ids refer to multiple packaged products. In those cases I tried to use the most common name, or a general name (e.g. PS3 Controller), or a completely generic name (e.g. USB gamepad) if it wasn't clear what type of controller it was.
Patches welcome!
Expand SDLActivity::SDLSurface::surfaceChanged() callback to grab the panel width and height at the same time and pass that along to the native code. Only works on API 17+. Duplicates surface dimensions whenever it fails.
Add Android_DeviceWidth/Android_DeviceHeight globals to native code.
Disambiguate Android_ScreenWidth/Android_ScreenHeight -> Android_SurfaceWidth/Android_SurfaceHeight
Use device width/height for all display mode settings.
This means we have to consider SDL_WINDOW_MINIMIZED a window creation flag, but on non-windows platforms we just remove it and let the normal FinishWindowCreation re-apply and do the minimize as I have no idea what is right on them or if anything should change.
CR: Phil
Martin ?irokov
Launching an SDL application with SDL_AUDIODRIVER=jack, and then calling SDL_OpenAudioDevice() with whatever parameters fails with an error like this one:
SDL_OpenAudioDevice: Couldn't connect JACK ports: SDL:sdl_jack_output_0 => system:midi_playback_1
This happens because JACK_OpenDevice in src/audio/jack/SDL_jackaudio.c blindly tries to connect to all input ports without checking whether they are for audio or midi.
The fix is to check port types and ignore all non audio ports. Also I removed devports field from struct SDL_PrivateAudioData, because it's never really used and removing unused ports from it would be PITA.
Jona
The following explains why this bug was happening:
This crash was caused because the audio session was being set as active [session setActive:YES error:&err] when the audio device was actually being CLOSED. Certain cases the audio session being set to active would fail and the method would return right away. Because of the way the error was handled we never removed the SDLInterruptionListener thus leaking it. Later when an interruption was received the THIS_ object would contain a pointer to an already released device causing the crash.
The fix:
When only one device remained open and it was being closed we needed to set the audio session as NOT active and completely ignore the returned error to successfully release the SDLInterruptionListener. I think the user assumed that the open_playback_devices and open_capture_devices would equal 0 when all of them where closed but the truth is that at the end of the closing process that the open devices count is decremented.
(It gets upset at the -2147483648, thinking this should be an unsigned value
because 2147483648 is too large for an int32, so the negative sign upsets the
compiler.)
The concern is that a massive int sample, like 0x7FFFFFFF, won't fit in a
float32, which doesn't have enough bits to hold a whole number this large,
just to divide it to get a value between 0 and 1.
Previously we would convert to double, to get more bits, do the division, and
cast back to a float, but this is expensive.
Casting to double is more accurate, but it's 2x to 3x slower. Shifting out
the least significant byte of an int32, so it'll definitely fit in a float,
and dividing by 0x7FFFFF is still accurate to about 5 decimal places, and the
difference doesn't appear to be perceptable.
Fixes problems launching Firewatch on Linux (which statically links SDL but
also dynamically loads a system-wide copy from a plugin shared library) with
a newer SDL build.
The change makes sure that SDL_vsnprintf() nul terminates if it is
using _vsnprintf() for the job.
I made this patch for Watcom, whose _vsnprintf() doesn't guarantee
nul termination. The preprocessor check can be extended to windows
in general too, if required.
Closes bug #3769.
Daniel Gibson
Sorry, but it seems like Microsoft didn't fix the issue properly.
I just updated my Win10 machine, it now is Version 1803, Build 17134.1
I tested with SDL2 2.0.7 (my workaround was released with 2.0.8) and still got
lots of events that directly undid the prior "real" events - just like before.
(See simple testcase in attachement)
By default it sets SDL_HINT_MOUSE_RELATIVE_MODE_WARP - which triggered (and on my machine still triggers) the buggy behavior. You can start it with -raw, then it'll not set that hint and the events will be as expected.
The easiest way to see the difference is looking at the window title, which shows accumulated X and Y values: If you just move your mouse to the right, in -raw mode the number just increases. In non-raw mode (using mouse warping) it stays around 0.
I also had a WinAPI-only testcase: https://gist.github.com/DanielGibson/b5b033c67b9137f0280af9fc53352c68
It just calls SetCursorPos(320,240); on each WM_MOUSEMOVE event, and it also
logs all those events to a mouseevents.log textfile.
This log indeed looks a bit different since the latest Win10 update: It seems like all those events with x=320 y=240 do arrive - but only after I stopped moving the mouse - even though the cursor seems to be moved back every frame (or so).
So moving the mouse to the right gives X coordinates like
330, 325, 333, 340, 330, ...
and then when stopping movement I get lots of events with X coordinate 320
Olli-Samuli Lehmus
If one creates a window with the SDL_WINDOW_FULLSCREEN_DESKTOP flag, and creates a render target with SDL_SetHint(SDL_HINT_RENDER_SCALE_QUALITY, "linear"), and afterwards sets SDL_SetHint(SDL_HINT_RENDER_SCALE_QUALITY, "nearest"), after minimizing the window, the scale quality hint is lost on the render target. Textures however do keep their interpolation modes.
lectem
The SDL_syswm.h header includes the windows.h header after including begin_code.h which changes the structure packing alignment.
It seems this is not safe as suggested by the following warning :
warning C4121: 'JOBOBJECT_IO_RATE_CONTROL_INFORMATION_NATIVE_V2': alignment of a member was sensitive to packing
Zack Middleton
Running top-level SDL configure on macOS 10.11 resulted in the errors below because automake removed the brackets about the tests.
./configure: line 15756: : command not found
./configure: line 15759: -Iinclude -I/Users/zack/SDL/include -idirafter /Users/zack/SDL/src/video/khronos : No such file or directory
./configure: line 15763: : command not found
Azamat H. Hackimov
When you try use SDL2 2.0.8 in CMake project in Linux, it complains about trailing spaces in sdl2.pc:
CMake Error at CMakeLists.txt:147 (add_executable):
Target "TestSimpleMain" links to item "-L/usr/lib64 -lSDL2 " which has
leading or trailing whitespace. This is now an error according to policy
CMP0004.
Christian Herzig
pthread_mutex_trylock() and by the way, pthread_mutex_lock() do not set errno.
Pthread-methods directly return error code as int. See related man-pages for
details.
Michael Sartain
This is a quick pass at adding Linux RealtimeKit thread priority support to SDL.
It allows me to bump the thread priority to high without root privileges or setting any caps, etc.
rtkit readme here:
http://git.0pointer.net/rtkit.git/tree/README
Previously the include path was {INSTALL_PREFIX}/include,
it is now {INSTALL_PREFIX}/include/SDL2 to be consistent with
the other build and package configuration systems.
Fixes#4128.
Simon Hug
I just wanted to fix a simple compiler warning in SDL_ShowMessageBox on Windows (which Sam fixed recently) and ended up finding some issues.
Attached patch fixes these issues:
- Because Windows only reports the lower 16 bits of the control identifier that was pushed, the button IDs used by SDL (C type int, most likely 32 bits) can get cut off.
- The documentation states (somewhat ambiguously) that the button ID will be -1 if the dialog was closed, but the current code sets 0. For SDL 2.1, I think this should be a return code of SDL_ShowMessageBox itself. That will free up the button ID and it seems a more appropriate place for signaling this event.
- Ampersands in controls will create mnemonics on Windows (underlined letters that, if combined with the Alt key, will push the button). I was thinking of adding a hint or flag to let the users enable it, but that might have unexpected results.
- When the size of the text gets calculated, it doesn't use the same parameters as the static control. This can cut off text or wrap it weirdly.
- On Windows, the Tab key is used to switch between control groups and sometimes between buttons in dialogs. This didn't seem to work correctly.
Attached patch also adds:
- Icons. Just the system ones that can be loaded with the ordinals IDI_ERROR, IDI_WARNING and IDI_INFORMATION.
- A button limit of 2^16 - 101.
- Some more specific error messages, but they never reach the user because how SDL_ShowMessageBox handles them if an implementation returns with an error.
This is commented out in SDLActivity.java, with the note #CURSORIMPLEENTATION because it requires API 24, which is higher than the minimum required SDK
Ozkan Sezer
The following patch defines _WIN32_WINNT_WIN7 if it is not already
defined in core/windows/SDL_windows.c, similar to what is already
there for _WIN32_WINNT_VISTA.
Felix Geyer
Forwarding from https://bugs.debian.org/892087 quoting verbatim:
The SDL2 header SDL_cpuinfo.h generates gcc warnings if the program using
it compiles with the -Wundef warning. (In particular, this means that QEMU
builds using it fail on at least sparc hosts, since QEMU dev builds
use both -Wundef and -Werror.).
/usr/include/SDL2/SDL_cpuinfo.h:63:5: warning: "HAVE_IMMINTRIN_H" is not defined, evaluates to 0 [-Wundef]
#if HAVE_IMMINTRIN_H && !defined(SDL_DISABLE_IMMINTRIN_H)
Eric Wasylishen
This bug was reintroduced by https://hg.libsdl.org/SDL/rev/fcf24b38a28a
The steps to reproduce are the same: run the "testrelative" SDL demo with "--info all",
connect a USB mouse with a scroll wheel, and roll the scroll wheel one "notch". You'll get log output like:
testdraw2[1644:67222] INFO: SDL EVENT: Mouse: wheel scrolled 0 in x and 0 in y (reversed: 1) in window 1
As far as I can tell macOS doesn't have an API for getting the number of "wheel notches"; I get a deltaY of 0.100006 for one "notch", and it's heavily accelerated (if you roll the wheel quickly you'll get large deltas). So NSEvent's deltaY is only meant to be used for scrolling a scroll view, with the given distance in points, not something like selecting an item in a game.
Here's a temporary patch that at restores the foor/ceil in Cocoa_HandleMouseWheel.
Not ideal, but at least it restores the ability to scroll one notch of a mousewheel.
Ozkan Sezer 2018-03-02 20:02:37 UTC
http://hg.libsdl.org/SDL/rev/d702b0c54e52 resulted in an error and
two warnings when compiled with mingw.
1. Error from SDL_windowstaskdialog.h:
In file included from src/video/windows/SDL_windowsmessagebox.c:29:0:
src/video/windows/SDL_windowstaskdialog.h:23:54: error: expected ')' before 'HWND'
This is fixed by removing unnecessary annotations:
2. Warning from SDL_assert.c:
src/SDL_assert.c: In function 'SDL_ExitProcess':
src/SDL_assert.c:138:1: warning: 'noreturn' function does return
Indeed ExitProcess() is prototyped with DECLSPEC_NORETURN, but
TerminateProcess() is not. This can be rectified by adding an
exit() call in there. Do NOTE, however, that requires building
with a libc:
3. Warning from SDL_windowsmessagebox.c:
src/video/windows/SDL_windowsmessagebox.c: In function 'WIN_ShowMessageBox':
src/video/windows/SDL_windowsmessagebox.c:513:9: warning: 'nCancelButton' may be used uninitialized in this function
My lazy solution was manually initializing nCancelButton to 0.
This lets the message box have an icon. Unless the app has opted-in to using
the v6 common controls, though, this will fall back to the usual SDL message
boxes.
"What I have done is use TerminateProcess rather than ExitProcess.
ExitProcess will cause Microsoft's leak detection to continue, TerminateProcess
won't. It is also technically wrong to use ExitProcess in the case of aborting
the application.
Jack Powell
Twitter @jack9267"
This tries to load vulkan.framework or libvulkan.1.dylib before MoltenVK.framework
or libMoltenVK.dylib. In the previous version, layers would not work for applications
run-time loading the default library.
Eric Wasylishen
Patch to support building the tests with cmake.
Disabled by default, use: "cmake .. -DSDL_TEST=YES" to enable the tests.
Tested on macOS 10.13 with the ninja, makefile, and Xcode generators, and Windows 10 with the Visual Studio 2017 generator.
Manuel Sabogal
If SDL is compiled with the Audio subsystem disabled there are some undefined references to the functions ANDROIDAUDIO_ResumeDevices and ANDROIDAUDIO_PauseDevices in the file src/video/android/SDL_androidevents.c.
Eric Wasylishen
The following patch adds Metal.framework to the "link binary with libraries" section of each test program, with "status" set to "optional", which fixes link errors on all of the test programs. I'm not sure if this is a correct fix - the fact that this was necessary might indicate the static SDL2.a library has a hard dependency on Metal.framework (?) - but it gets the test programs working in Xcode again.
It also adds testyuv_cvt.c to the testoverlay2 target, fixing a link error.
With the previous change, I get:
1> Creating library C:\projects\SDL\VisualC\Win32\Debug\SDL2.lib and object C:\projects\SDL\VisualC\Win32\Debug\SDL2.exp
1>LINK : error LNK2001: unresolved external symbol __DllMainCRTStartup@12
Andreas Falkenhahn
In src/SDL.c there is this code:
_DllMainCRTStartup(HANDLE hModule,
...
The comment says that this is needed on Watcom C for some reason but why is it included then when building with Visual C as well? Shouldn't it be only included when compiling on Watcom C then?
I'm asking because this code caused me a lot of headaches because I'm building a DLL that contains SDL and I link using /MT and the _DllMainCRTStartup() symbol obviously led to lots of trouble but it wasn't clear to me where the problem was because all I got from the linker was:
LNK2019: unresolved external symbol _main referenced in function ___tmainCRTStartup
So I had to got through each and every object to see what the culprit was. See here for the full story:
https://stackoverflow.com/questions/25067151/lnk2019-unresolved-external-symbol-main-referenced-in-function-tmaincrtstar/48177067#48177067
So if it isn't necessary on Visual C, please just leave that symbol out on Visual C so that it no longer leads to any trouble. Thanks.
Most pthread functions return 0 on success and non-zero on error, but those
errors might be positive or negative, so checking for return values in the
Unix style, where errors are less than zero, is a bug.
Fixes Bugzilla #4039.
Callum McGing
This patch allows the user to disable the behaviour that blocks the compositor through a new hint: SDL_VIDEO_X11_NET_WM_BYPASS_COMPOSITOR. This allows tools or other windowed applications to behave properly under KWin.
cjacker
After updating from 2.0.5 to 2.0.7, Ibus not work anymore(fcitx still works).
Compare with 2.0.5, there are two issues in SDL_ibus.c.
1, SetupConnection always return SDL_FALSE in 2.0.7.
2, 'SetCapabilities' method should be called on 'ibus_conn'.
Patch attached.
Alexander Larsson
dbus_shutdown() is a debug feature which closes all global resources in the dbus library. Calling this should be done by the app, not a library, because if there are multiple users of dbus in the process then SDL could shut it down even though another part is using it.
For example, i had an issue with this in mGBA, which uses both Qt and SDL, both using libdbus. I had a session bus, but no system bus (this was in a flatpak sandbox), and when SDL_DBus_Init() failed to init the system bus it called dbus_shudown() and continued on. This caused issues for Qt when running due to its session bus connections having disappeared beneath it.
Ozkan Sezer
Configury adds Metal.framework to linkage even if it is not available.
My solution is setting enable_render_metal to no when Metal.framework
is not found
"*(void**)pfn = LoadAddress()" would cast the NULL pointer in pfn to a
void**, and then dereference it, which wasn't what we wanted. Replaced with
a clearer cast operation.
Viacheslav Slavinsky
SDL_rpivideo driver has 60 frames per second hardcoded in it, this is a problem for games that need to keep pace using VSYNC. I believe that I have found a solution to this. It is based on code in tvservice.c in rpi userland:
a1b89e91f3/host_applications/linux/apps/tvservice/tvservice.c (L433)
ayer.3d
I have a DualShock 4 v2 controller with a GUID that's not in the database. There is an existing GUID that is almost identical, with the only difference that I can tell being the reported version string (mine being 8001, database is 8100).
Existing GUID: 050000004c050000cc09000000810000
New GUID: 050000004c050000cc09000001800000
When connected via USB, the GUID matches an existing entry: 030000004c050000cc09000011810000
This is meant to be the desktop-enhanced version of wl_shell. Right now we
just match what the existing wl_shell code does, but there are other areas of
functionality available to us now, that we can fill in later.
This uses the "unstable" API, since this is what ships in Ubuntu 17.10 (as
part of Wayland 1.10), but Wayland 1.12 promotes this to stable with extremely
minor changes. We will add support for the stable version when it makes sense
to do so.
This variable can be set to the following values:
"0" - The indicator bar is not hidden (default for windowed applications)
"1" - The indicator bar is hidden and is shown when the screen is touched (useful for movie playback applications)
"2" - The indicator bar is dim and the first swipe makes it visible and the second swipe performs the "home" action (default for fullscreen applications)
SDL now builds with gcc 7.2 with the following command line options:
-Wall -pedantic-errors -Wno-deprecated-declarations -Wno-overlength-strings --std=c99
Sylvain
armeabi is almost deprecated for android-ndk higher that r13b.
either it doesn't compile (ICE), or it executes wrongly (using long long for instance).
android people advices to use armeabi-v7a (or use r13b).
Anthony
This worked in 2.0.5 as normal, but stopped working in 2.0.7. The monitor's resolution doesn't change, a window is created in full screen mode at the virtual desktop resolution instead.
The EGL_GL_COLORSPACE_KHR is an attribute for eglCreate*Surface.
As written in EGL_KHR_gl_colorspace documentation:
Accepted as an attribute name by eglCreateWindowSurface,
eglCreatePbufferSurface and eglCreatePixmapSurface
EGL_GL_COLORSPACE_KHR 0x309D
(...)
A future SDL release will change the borderless window to act more like a normal window that happens to have no chrome, to support windows that draw their own chrome. In the meantime, those applications should set the "SDL_BORDERLESS_WINDOWED_STYLE" hint.
Ismael Ferreras Morezuelas (Swyter)
As a new year gift I have implemented the Windows version of SDL_GetWindowBordersSize(). I needed it for auto-selecting a cozy window size for the game I'm currently working on and noticed that it only worked under X11, so I thought it could be a good excuse to contribute back more stuff. The Mercurial patch is attached as a .diff file. Let me know what you think.
Happy 2018 to all the SDL2 devs and users!
--
PS: Keep in mind that Windows 10 includes the 8px invisible grip borders as part of the frame. There's a way of detecting if Aero/DWM is being used and ask only for the visible rect, but I believe that GetWindowRect() is doing that for a reason and working as intended, so I haven't changed it. (See [2])
References:
[1]: http://www.firststeps.ru/mfc/winapi/r.php?72
[2]: https://stackoverflow.com/a/34143777/674685
[3]: https://stackoverflow.com/a/431548/674685
[4]: https://wiki.libsdl.org/SDL_GetWindowBordersSize
- Use a single buffer for various non-changing constants accessed by the GPU, instead of multiple buffers.
- Do the half-pixel offset for points and lines using a transform matrix so we don't need a malloc when rendering.
- Don't add a half-pixel offset for other primitives and textures. This matches D3D and GL render behaviour.
- Remove the half-texel texture coordinate offset since it's not needed now that there's no more half-pixel position offset when rendering a texture.
- Don't try to set texture usage on iOS 8 since it doesn't exist there.
"GetVersionExA is deprecated in windows 8.1 and above's SDK, causing a warning
when building against the win10 SDK. Attached patch cleans up the usage for a
warning-free build.
GetVersionExA was being used to test to see if SDL was running on win9x or
winnt. A quick chat with Ryan on twitter suggested that SDL doesn't
officially support win9x anymore, so the call to this can be outright removed.
As an aside, replacing the call to GetVersionExA with VerifyVersionInfoA (the
recommended path) would have been pointless, as VerifyVersionInfoA only
supports VER_PLATFORM_WIN32_NT and doesn't officially support any other value
for dwPlatformId currently. (And it's probable that win9x SDKs didn't have
VerifyVersionInfo* in them anyway.)"
Fixes Bugzilla #4019.
Laurent Merckx
I have a problem with the SDL_ShowCursor method on Raspberry.
Depending on the context, my application hides or show the mouse cursor with SDL_ShowCursor.
But when calling SDL_ShowCursor(true), the cursor is displayed at 0,0 (and not at last position).
After debugging sources by myself, it seems that the problem is in SDL_rpimouse.c - RPI_ShowCursor:
vc_dispmanx_rect_set( &dst_rect, 0, 0, curdata->w, curdata->h);
should be
vc_dispmanx_rect_set( &dst_rect, mouse->x, mouse->y, curdata->w, curdata->h);
For me, it solves the problem.
tomwardio
HAVE_POLL is correctly defined in SDL_config.h when running configure. However, in the only place where it's used, it's undefined at the start of the file.
Dominik Reichardt
As discussed in 2012 the iOS onscreen keyboard hides when you hit RETURN (see https://discourse.libsdl.org/t/on-screen-keyboard-change/19216).
IMO this is a bad idea to not be able to influence this behavior and just recently this was fixed for Android by adding the hint SDL_HINT_ANDROID_RETURN_HIDES_IME in changeset 11768 6ce3bb5e38a5.
Eric wing
There is a tiny bug in the new overscan code for the SDL_renderer.
In SDL_renderer.c, line 1265, the if check for SDL_strcasecmp with "direct3d" needs to be inverted.
Instead of:
if(SDL_strcasecmp("direct3d", SDL_GetCurrentVideoDriver())) {
It should be:
if(0 == SDL_strcasecmp("direct3d", SDL_GetCurrentVideoDriver())) {
This bug causes the "overscan" mode to pretty much be completely ignored in all cases and all things remain letterboxed (as before the feature).
bastien.bouclet
According to this GCC bug report, altivec.h requires building with the gnu extensions: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78263.
As an application developer, I don't want SDL to force me to enable the gnu extensions.
Elis?e Maurer
The attached minimal program sets the SDL_HINT_MOUSE_RELATIVE_MODE_WARP to 1, enables relative mouse mode then logs all SDL_MOUSEMOTION xrel values as they happen.
When moving the mouse exclusively to the right:
* On a Windows 10 installation before Fall Creators update (for instance, Version 10.0.15063 Build 15063), only positive values are reported, as expected
* On a Windows 10 installation after Fall Creators update (for instance, Version 10.0.16299 Update 16299), a mix of positive and negative values are reported.
3 different people have reproduced this bug and have confirmed it started to happen after the Fall Creators update was installed. It happens with SDL 2.0.7 as well as latest default branch as of today.
It seems like some obscure (maybe unintended) Windows behavior change? Haven't been able to pin it down more yet.
(To force-upgrade a Windows installation to the Fall Creators update, you can use the update assistant at https://www.microsoft.com/en-us/software-download/windows10)
Eric Wasylishen
Broken GetCursorPos / SetCursorPos based games on Win 10 fall creators are not limited to SDL.. I just tested winquake.exe (original 1997 exe) and it now has "jumps" in the mouse input if you try to look around in a circle. It uses GetCursorPos/SetCursorPos by default. Switching WinQuake to use directinput (-dinput flag) seems to get rid of the jumps.
Daniel Gibson
A friend tested on Win10 1607 (which is before the Fall Creators Update) and the the bug doesn't occur there, so the regression that SetCursorPos() doesn't reliably generate mouse events was indeed introduced with that update.
I even reproduced it in a minimal WinAPI-only application (https://gist.github.com/DanielGibson/b5b033c67b9137f0280af9fc53352c68), the weird thing is that if you don't do anything each "frame" (i.e. the mainloop only polls the events and does nothing else), there are a lot of mouse events with the coordinates you passed to SetCursorPos(), but when sleeping for 10ms in each iteration of the mainloop, those events basically don't happen anymore. Which is bad, because in games the each iteration of the mainloop usually takes 16ms..
I have a patch now that I find acceptable.
It checks for the windows version with RtlGetVersion() (https://msdn.microsoft.com/en-us/library/windows/hardware/ff561910.aspx) and only if it's >= Win10 build 16299, enables the workaround.
All code is in video/windows/SDL_windowsevents.c
and the workaround is, that for each WM_MOUSEMOVE event, "if(isWin10FCUorNewer && mouseID != SDL_TOUCH_MOUSEID && mouse->relative_mode_warp)", an addition mouse move event is generated with the coordinates of the center of the screen
(SDL_SendMouseMotion(data->window, mouseID, 0, center_x, center_y);) - which is exactly what would happen if windows generated those reliably itself.
This will cause SDL_PrivateSendMouseMotion() to set mouse->last_x = center_x; and mouse->last_y = center_y; so the next mouse relative mouse event will be calculated correctly.
If Microsoft ever fixes this bug, the IsWin10FCUorNewer() function would have to
be adjusted to also check for a maximum version, so the workaround is then disabled again.
Yuri K. Schlesner
When using texture filtering, there are filtering artifacts visible on the edges of scaled textures, where the texture filtering pulls in texels from the other side of the texture. Using clamping texture modes wouldn't completely fix this since source rectangles don't need to cover the whole texture. (See screenshot attached in next post.)
The opengl driver uses clamping on textures and so avoid this at least in the cases where the source rect is the whole texture. The direct3d driver does not and so has problems in every case. I'm not sure if it can actually completely be fixed, but at least enabling clamping for direct3d would be one step in the right direction.
This works better for games where there may be a bunch of simulation logic that needs to be run before the next rendering pass, and prevents blocking if the next drawable is busy.
This isn't complete, but is enough to run testsprite2. It's currently
Mac-only; with a little work to figure out how to properly glue in a Metal
layer to a UIView, this will likely work on iOS, too.
This is only wired up to the configure script right now, and disabled by
default. CMake and Xcode still need their bits filled in as appropriate.
XAudio2 doesn't have capture support, so WASAPI was to replace it; the holdout
was WinRT, which still needed it as its primary audio target until the WASAPI
code code be made to work.
The support matrix now looks like:
WinXP: directsound by default, winmm as a fallback for buggy drivers.
Vista+: WASAPI (directsound and winmm as fallbacks for debugging).
WinRT: WASAPI
Andrey
Seems latest google angle library successfully built & tested under macOS'es.
https://github.com/google/angle
We need to use GLES2 to implement true cross-platform code.
tomwardio
Proposed patch loads eglCreatePbufferSurface in same manner as other 1.1 functors. This allows custom video drivers to create pbuffer surfaces.
Manuel Alfayate Corchete
This fixes a problem with KMSDRM on some graphics hardware where only bigger cursor sizes are supported, such as current Intel gfx. (The kernel-side driver is what limits this: had to look for failing IOCTLs...)
That caused SDL_SetCursor() to fail silently, and we were left with a missing cursor without further explanation.
With this patch, different "standard" sizes are tried and a bigger one is used (with an intermediate and clean buffer only used to write the new cursor to the BO where it will live after) if we get, let's say, 16x16 which is pretty common but our hardware does not support that.
Vitaly Novichkov
Once I ran build of my codecs collection on AppVeyor where my CMake script downloads latest SDL2 from HG repo, failed to link because of math functions conflict:
https://ci.appveyor.com/project/Wohlstand/audiocodecs/build/1.0.44
The revision is b9ff5f8b2303
There are both vanilla MinGW and MinGW-w64 are failed to build.
```
[100%] Linking C shared library libSDL2.dll
c:/mingw/bin/../lib/gcc/mingw32/5.3.0/../../../libmingwex.a(scalbn.o):(.text+0x0): multiple definition of `scalbln'
CMakeFiles\SDL2.dir/objects.a(s_scalbn.c.obj):C:/projects/audiocodecs/build-MinGW-Release-Win32/external/SDL2/src/SDL2HG/src/libm/s_scalbn.c:30: first defined here
C Snover
SDL_AddDisplayMode returns an SDL_bool corresponding to whether or not the given display mode was added or not. It will return SDL_FALSE if a matching display mode already exists in the display's list of display modes, which causes ownership of the mode driverdata to remain with the caller. Some video drivers ignore the return value of SDL_AddDisplayMode, so leak the driverdata memory when SDL_AddDisplayMode returns SDL_FALSE.
Mate Nagy
There is a typo in CMakeLists.txt that makes CMake exit with failure.
Change that causes the problem: (Notice the double ending brackets)
${SDL2_SOURCE_DIR}/src/video/*.c)
+ ${SDL2_SOURCE_DIR}/src/video/yuv2rgb/*.c)
Fix:
Just remove the first ending bracket resulting in:
${SDL2_SOURCE_DIR}/src/video/*.c
${SDL2_SOURCE_DIR}/src/video/yuv2rgb/*.c)
raist66676
Here is the bug in latest SDL 2.0.8 development repo. It is obvious and simple to fix by correcting typos on six lines of code.
In src/video/SDL_yuv.c on lines 217, 249, 280, 321, 353, and 384 the wrong conversion functions are called for SDL_PIXELFORMAT_ABGR8888 and SDL_PIXELFORMAT_BGR888. Instead of ABGR functions, BGRA functions are called. These are typos.
New functions get and set the YUV colorspace conversion mode:
SDL_SetYUVConversionMode()
SDL_GetYUVConversionMode()
SDL_GetYUVConversionModeForResolution()
SDL_ConvertPixels() converts between all supported RGB and YUV formats, with SSE acceleration for converting from planar YUV formats (YV12, NV12, etc) to common RGB/RGBA formats.
Added a new test program, testyuv, to verify correctness and speed of YUV conversion functionality.
tomwardio
Remove static int vm_error and vm_event, use local variables instead.
This fixes unused variable errors when compiling with SDL_VIDEO_DRIVER_X11_XINERAMA undefined.
src/video/x11/SDL_x11modes.c:505:22: error: unused variable 'vm_error' [-Werror,-Wunused-variable]
src/video/x11/SDL_x11modes.c:505:12: error: unused variable 'vm_event' [-Werror,-Wunused-variable]
tomwardio
Add support to be able to set EGL_SURFACE_TYPE bits when creating an EGL config. This is usefule when wanting to create pixel buffer surfaces in custom video drivers.
Alexander Orefkov
In src\joystick\android\SDL_sysjoystick.c in SDL_SYS_JoystickDetect when SDL_GetTicks return number grater 2147483648 (after 24.85 days uptime) SDL_TICKS_PASSED(SDL_GetTicks(), timeout) return FALSE and Android_JNI_PollInputDevices is never calling.
And in JoystickByDeviceId - when search for newly added joystic - after SDL_SYS_JoystickDetect item not reinitilized, and always stay NULL, cause return NULL instead of added joystick.
Sylvain
A listener thread has been added to know when the native thread would end.
But now, it is more easy to only check that after the main function has returned. It's one thread less.
e_pluschauskas
I noticed that after updating SDL to 2.0.6 my application now exports SDL_main.
At GitHub SDL mirror (branch 2.0.5) SDL_main prototyped as
extern C_LINKAGE int SDL_main(int argc, char *argv[]);
but at branch 2.0.6 prototype is
extern C_LINKAGE DECLSPEC int SDL_main(int argc, char *argv[]);
Changing the background color causes the titlebar to blend against it on
modern macOS releases, making all SDL windows look wrong by default. This was
set to make the window not flash white before a GL context is ready, but we
can accomplish this in our window's view's drawRect implementation, too.
Also added native code to the Android gradle project, which allows using gradle or Android Studio to build the entire SDL application without a separate ndk-build step.
Manuel
I noticed that, at least on Intel GPU hardware, passing SDL_RENDERER_PRESENTVSYNC would result on a static console instead of the program graphics.
That was due to the fact that calling drmModePageFlip() only works if we have previously set up CRTC to one of the GBM buffers with a drmModeSetCrtc() call, so now it's done and things work as expected.
The KMSDRM_GLES_SetupCrtc() call is done only one time, only when needed (when egl_swapinterval is not 0: when it's 0, there's no need for it because we flip by calling drmModePageFlip() anyway).
The place where KMSDRM_GLES_SetupCrtc() call is done may look strange, but it's right: it needs EGL completely ready because it needs to call eglSwapBuffers() internally to work (see more comments about it in the code).
Simon Hug
Patch that adds [-1, 1] clamping to the scalar audio type conversions.
This may come from the SDL_Convert_F32_to_X_Scalar functions. They don't clamp the float value to [-1, 1] and when they cast it to the target integer it may be too large or too small for the type and get truncated, causing horrible noise.
The attached patch throws clamping in, but I don't know if that's the preferred way to fix this. For x86 (without SSE) the compiler (I tested MSVC) seems to throw a horrible amount of x87 code in it. It's a bit better with SSE, but probably still quite the performance hit. And SSE2 uses a branchless approach with maxss and minss.
Carlos
Angle supports GLES3 but when using these functions (SDL_CreateWindow and SDL_CreateRenderer), defaults again to GLES2.0.
A current workaround (hack) to retrieve a GLES3.0 context with Angle is:
1) set
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 3);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 0);
after InitSDL AND after calling SDL_CreateWindow (before SDL_CreateRenderer)
2) Comment lines 2032-2044 in SDL_render_gles2.c, funtion GLES2_CreateRenderer
window_flags = SDL_GetWindowFlags(window);
if (!(window_flags & SDL_WINDOW_OPENGL) ||
profile_mask != SDL_GL_CONTEXT_PROFILE_ES || major != RENDERER_CONTEXT_MAJOR || minor != RENDERER_CONTEXT_MINOR) {
changed_window = SDL_TRUE;
SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_ES);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, RENDERER_CONTEXT_MAJOR);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, RENDERER_CONTEXT_MINOR);
if (SDL_RecreateWindow(window, window_flags | SDL_WINDOW_OPENGL) < 0) {
goto error;
}
}
This retrives a GLES3 context as confirmed using glGetString(GL_VERSION). This should be fixed by modifying a few if's.
Ozkan Sezer
In my cross-build environment with cmake-2.8.12.1, cmake does not add
SDL_coreaudio.m to its makefiles and the result is a failure. The fix
is simple: set the language to C for it as it is done at other places
in CMakeLists.txt.
Ozkan Sezer
Since changeset 11607:60cd425a2f14, I am getting the following
error upon quit. Running testsprite2, clicking the mouse, and
quiting it is enough to trigger it. This is on my old Fedora9
x86-Linux:
X Error of failed request: BadCursor (invalid Cursor parameter)
Major opcode of failed request: 2 (X_ChangeWindowAttributes)
Resource id in failed request: 0xb057340
Serial number of failed request: 905
Current serial number in output stream: 906
Reverting https://hg.libsdl.org/SDL/rev/60cd425a2f14 removes
the error.
The audioqueue thread needs to keep running, and processing the CFRunLoop
until the AudioQueue is disposed of, otherwise CoreAudio will hang waiting for
final data to feed the device.
At least, I think this is how it all works. It definitely fixes the bug here!
Since AudioQueueDispose() calls AudioQueueStop() internally, there's no need
for our thread to handle this, either, which is good because the AudioQueue
would be disposed by this point. So now the AudioQueue is disposed first, and
then our thread is joined, and everything works out okay.
Just in case, we mark the device "paused" before setting everything in motion,
so any further callbacks from CoreAudio will write silence and not fire the
app's audio callback again.
Fixes Bugzilla #3868.
Steve Robinson
In my project, the 'uninstall' target is already created by the glew library. I get this error when SDL2 tries to create it:
CMake Error at _build/3rdparty/SDL2/SDL2-2.0.6/CMakeLists.txt:1816 (add_custom_target):
add_custom_target cannot create target "uninstall" because another target
with the same name already exists. The existing target is a custom target
created in source directory
"D:/Code/sdl2-tutorial/_build/3rdparty/glew/glew-2.1.0/build/cmake". See
documentation for policy CMP0002 for more details.
To fix it, go to the bottom of the SDL2 CMakeLists.txt file. Add an if statement to check for the existence of the target before creating it. The end result looks like this:
if(NOT TARGET uninstall)
configure_file(
"${CMAKE_CURRENT_SOURCE_DIR}/cmake_uninstall.cmake.in"
"${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake"
IMMEDIATE @ONLY)
add_custom_target(uninstall
COMMAND ${CMAKE_COMMAND} -P ${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake)
endif()
This is how the glew library deals with this possibility in their CMakeLists.txt file.
Steve Robinson
When I try to build the 'uninstall' target in CMake when SDL2 is added to a subdirectory of my project, I get this error:
1>CMake Error at cmake_uninstall.cmake:2 (message):
1> Cannot find install manifest:
1> "D:/Code/sdl2-tutorial/_build/3rdparty/SDL2/SDL2-2.0.6/install_manifest.txt"
The install_manifest.txt is actually in the top-level binary directory, not the project-specific binary directory.
To fix it, change all instances of:
CMAKE_CURRENT_BINARY_DIR
To:
CMAKE_BINARY_DIR
In:
cmake_uninstall.cmake.in
Trent Gamblin
The documentation for SDL_TouchFingerEvent says that the x and y coordinates are normalised between 0-1. I've found that to be true on Windows, Android and iOS but on X11 they are in pixel coordinates. This patch fixes the issue. This was the cleanest way I could do it with what was available without changing things around a lot but you may know a better way.
(I thought padding size ranged from 5 frames to ~30 frames (based around
RESAMPLER_ZERO_CROSSINGS, which is 5), but it's actually between 512 and
several thousands (based on RESAMPLER_SAMPLES_PER_ZERO_CROSSING)). It gets
big fast when downsampling.
Manuel
I would like this small patch merged that adds support for my GreenAsia Inc. PSX to USB converter, so SDL_IsGameController() returns true when using this adaptor.
It's interesting because PSX/PS2 controllers connected using this model won't be detected as gamecontrollers otherwise, only as joysticks.
Sylvain
There are various YUV-RGB conversion coefficients, according to https://www.fourcc.org/fccyvrgb.php
I choose the first (from Video Demystified, with integer multiplication),
but the current SDL2 Dither functions use in fact the next one, which follows a specifications called CCIR 601.
Here's a patch to use the second ones and with previous warning corrections.
There are less multiplications involved because Chroma coefficient is 1.
Also, doing float multiplication is as efficient with vectorization.
In the end, the YUV decoding is faster: ~165 ms vs my previous 195 ms.
Moreover, if SDL2 is compiled with -march=native, then YUV decoding time drops to ~130ms, while older ones remains around ~220 ms.
For information, from jpeg-9 source code:
jpeg-9/jccolor.c
* YCbCr is defined per CCIR 601-1, except that Cb and Cr are
* normalized to the range 0..MAXJSAMPLE rather than -0.5 .. 0.5.
* The conversion equations to be implemented are therefore
* Y = 0.29900 * R + 0.58700 * G + 0.11400 * B
* Cb = -0.16874 * R - 0.33126 * G + 0.50000 * B + CENTERJSAMPLE
* Cr = 0.50000 * R - 0.41869 * G - 0.08131 * B + CENTERJSAMPLE
jpeg-9/jdcolor.c
* YCbCr is defined per CCIR 601-1, except that Cb and Cr are
* normalized to the range 0..MAXJSAMPLE rather than -0.5 .. 0.5.
* The conversion equations to be implemented are therefore
*
* R = Y + 1.40200 * Cr
* G = Y - 0.34414 * Cb - 0.71414 * Cr
* B = Y + 1.77200 * Cb
Sylvain
Few issues with YUV on SDL2 when using odd dimensions, and missing conversions from/back to YUV formats.
1) The big part is that SDL_ConvertPixels() does not convert to/from YUV in most cases. This now works with any format and also with odd dimensions,
by adding two internal functions SDL_ConvertPixels_YUV_to_ARGB8888 and SDL_ConvertPixels_ARGB8888_to_YUV (could it be XRGB888 ?).
The target format is hard coded to ARGB888 (which is the default in the internal of the software renderer).
In case of different YUV conversion, it will do an intermediate conversion to a ARGB8888 buffer.
SDL_ConvertPixels_YUV_to_ARGB8888 is somehow redundant with all the "Color*Dither*Mod*".
But it allows some completeness of SDL_ConvertPixels to handle all YUV format.
It also works with odd dimensions.
Moreover, I did some benchmark(SDL_ConvertPixel vs Color32DitherYV12Mod1X and Color32DitherYUY2Mod1X).
gcc-6.3 and clang-4.0. gcc performs better than clang. And, with gcc, SDL_ConvertPixels() performs better (20%) than the two C function Color32Dither*().
For instance, to convert 10 times a 3888x2592 image, it takes ~195 ms with SDL_ConvertPixels and ~235 ms with Color32Dither*().
Especially because of gcc vectorize feature that optimises all conversion loops (-ftree-loop-vectorize).
Nb: I put no image pitch for the YUV buffers. because it complexify a little bit the code and the API :
There would be some ambiguity when setting the pitch exactly to image width:
would it a be pitch of image width (for luma and chroma). or just contiguous data ? (could set pitch=0 for the later).
2) Small issues with odd dimensions:
If width "w" is odd, luma plane width is still "w" whereas chroma planes will be "(w + 1)/2". Almost the same for odd h.
Solution is to strategically substitute "w" by "(w+1)/2" at the good places ...
- In the repository, SDL_ConvertPixels() handles YUV only if yuv source format is exactly the same as YUV destination format.
It basically does a memcpy of pixels, but it's done incorrectly when width or height is odd (wrong size of chroma planes). This is fixed.
- SDL Renderers don't support odd width/height for YUV textures.
This is fixed for software, opengl, opengles2. (opengles 1 does not support it and fallback to software rendering).
This is *not* fixed for D3D and D3D11 ... (and others, psp ?)
Only *two* Dither function are fixed ... not sure if others are really used.
- This is not possible to create a NV12/NV12 texture with the software renderer, whereas other renderers allow it.
This is fixed, by using SDL_ConvertPixels underneath.
- It was not possible to SDL_UpdateTexture() of format NV12/NV21 with the software renderer. this is fixed.
Here's also two testcases:
- that do all combination of conversion.
- to test partial UpdateTexture
Steve Robinson
In my existing CMake project, I use add_subdirectory to add the source for SDL2. This worked fine in 2.0.5, but now in 2.0.6 when I build the INSTALL CMake target, I get this error:
file INSTALL cannot find "D:/path/to/SDL2Config.cmake".
Call Stack (most recent call first):
3rdparty/SDL2/cmake_install.cmake:32 (include)
3rdparty/cmake_install.cmake:36 (include)
cmake_install.cmake:32 (include)
To fix this, I changed line 1770 from this:
${CMAKE_SOURCE_DIR}/SDL2Config.cmake
To this:
${CMAKE_CURRENT_SOURCE_DIR}/SDL2Config.cmake
Aaron
As of 2.0.6, all of my games are failing with the following error:
process 31778: arguments to dbus_type_is_basic() were incorrect, assertion "dbus_type_is_valid (typecode) || typecode == DBUS_TYPE_INVALID" failed in file dbus-signature.c line 322.
This is normally a bug in some application using the D-Bus library.
D-Bus not built with -rdynamic so unable to print a backtrace
(patch by Ozkan Sezer)
Evgeny Kapun
Commit 490bb5b49f11 [1], which was a fix for bug #3790, introduced a new bug: now, calling SDL_FreeSurface(surface) deallocates surface->map even if there are other references to the surface. This is bad, because some functions (such as SDL_ConvertSurface) assume that surface->map is not NULL.
Michal
the numbering of the bulletpoints in:
docs/README-ios.md
has been mangled with:
changeset 11365 efd3bc8e5a9b
fix:
12 2. Open SDL.xcodeproj (located in Xcode-iOS/SDL) in Xcode.
13 4. Select your desired target, and hit build.
remove:
28 1. Follow step 1 above.
adapt:
29 2. cd (PATH WHERE THE SDL CODE IS)/build-scripts
30 3. ./iosbuild.sh
Robert Turner
SDL_windowsevents.c contains code to retrieve the x and y coordinate for a requested hit test. It does this as follows:
POINT winpoint = { (int) LOWORD(lParam), (int) HIWORD(lParam) };
LOWORD(lParam) does not correctly mask off high bits that are set if the point is on a second (or third, etc.) monitor. This effectively offsets the x-coordinate by a large value.
MSDN documentation suggests that LOWORD() and HIWORD() are the wrong macros for the task, instead suggesting we should be doing something like the following:
POINT winpoint = { GET_X_LPARAM(lParam), GET_Y_LPARAM(lParam) };
Testing this change on my Windows 10 machine with 2 monitors gives the correct results.
Ozkan Sezer
EMX declares _beginthread() / _endthread() in stdlib.h, not process.h.
The attached patch updates the OS/2 case of SDL_thread.h for it. (It
also tidies the unreadable whitespace in win32 case.)
- Fixing rendering borderless window. Need to force windows to send a WM_NCCALCSIZE then return 0 for non-client area size.
- Adding WS_CAPTION | WS_SYSMENU | WS_MINIMIZEBOX to borderless windows, for reasons noted in comments.
- Fix SetupWindowData() setting SDL_WINDOW_BORDERLESS. This was being cleared at window creation, causing hanlding for the first WM_NCCALCSIZE message to fail
Mark Callow
Xcode 9 emits a warning to validate project settings. The changes it proposes are
1. [iOS] Update the iOS deployment target to 8.0 since Xcode does
not support anything older.
2. [macOS] Target 'Framework' - Automatically Select Archectures.
3. [iOS & macOS] Turns on a bunch more compile warnings, a *lot* more on iOS.
4. [iOS & macOS] Turn on "Missing Localizability".
I want to confirm if it is ok to accept these changes and submit updated project files.
Since Alex Szpakowski has just removed iOS 7 guard ifdef's, I'm guessing 1 isn't a problem.
2 is probably ok for anyone building themselves. I wonder if it may cause problems for building distribution binaries.
3 shouldn't be a problem either provided any newly emitted warnings are fixed.
4 I am unfamiliar with. The description says "This will turn on the static analyzer to check for "Missing Localizability", because this project is localized for multiple languages." I suppose this may cause new warnings.
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,
^
Elis?e Maurer
I scratched my head for a while until I realized there's a typo in the command listed in the instructions for universal Mac builds: https://hg.libsdl.org/SDL/file/3a3a88db1fc2/docs/README-macosx.md#l24
It should say `g++-fat.sh` but instead it says `g++fat.sh`, which makes `./configure` fail with a C++ preprocessor error.
Kai Sterker
Apparently, SDL2 on Haiku does not generate SDL_TEXTINPUT events.
Attached is a patch that adds this functionality.
Tested with SDLs own checkkeys program and different keymaps as well as my own SDL application and German keyboard layout to verify it generates the expected input.
Albert Casals
On a RaspberryPI, it might become convenient to specify the Dispmanx layer SDL uses.
Currently, it is hardcoded to be 10000 to sit above most applications.
This can be specially useful when integrating other graphical apps and frameworks like OMXplayer, QT5 etc.. in order to have more flexibility on their Z-order.
ny00
Unfortunately, simply checking the return codes of "onNativePadDown/Up" as previously done has its own issue:
If an SDL joystick is connected *and* opened, then a proper KeyEvent, say with keycode KEYCODE_BUTTON_1, should lead to an SDL joystick button event as expected.
If, however, the joystick was *not* opened, then "onNativePadDown/Up" will return a negative value, so before the commit from bug 3426, you could unexpectedly get a keyboard event. (In practice, you'll just get a log message, since KEYCODE_BUTTON_1 has no mapping to a proper SDL_ScanCode value, but it's still an problem).
What should still be done, though, is checking the key code itself. We do have the KeyEvent.isGamepadButton method, but according my test, it returns "true" exactly (and only) for the KEYCODE_BUTTON* values, and not for KEYCODE_DPAD* or any other key code.
Here is a possible solution:
- Do check the return codes of "onNativePadDown/Up" as previously done.
- In addition, in "Android_OnPadDown/Up" from src/joystick/android/SDL_sysjoystick.c, 0 should *always* be returned in case the key code can be translated to an SDL_joystick button; Even if no matching joystick can be found.
Philipp Wiesemann
Maybe the fault is in the SDL_VIDEO_DRIVER_WINDOWS section in SDL_InitSubSystem() of "src/SDL.c". Because there only SDL_INIT_JOYSTICK is checked. The flags are adapted for SDL_INIT_GAMECONTROLLER afterwards.
Eric Wasylishen
The patch makes StartTextInput/StopTextInput call Xutf8ResetIC ( https://www.x.org/releases/X11R7.5/doc/man/man3/XmbResetIC.3.html ) on the XIC of all SDL windows.
This fixes my use case in Quakespasm (Ubuntu 16.04, system keyboard layout set to German. Type the '^' dead key, which opens Quakespasm's developer console and calls SDL_StartTextInput, then press 'e'. I expect the dead key to be ignored.)
Also, here is a patch for sdl2's "checkkeys" for testing this: https://bugzilla-attachments.libsdl.org/attachment.cgi?id=2451
Olav Sorensen
After a drag and drop event, any following mouse button input (down/up) doesn't generate an event. Clicking any mouse button a *second* time generates an event like it should.
Further investigation shows that the new SDL_HINT_MOUSE_FOCUS_CLICKTHROUGH logic also causes this issue in other cases, like the first time you open the program and click the mouse.
Simon Hug
There are currently three entry points in the SDL2_main code for windows: main, wmain and WinMain. Only the latter two properly convert the arguments to UTF-8.
Console applications linked with MSVC will always link with the main entry point (wmain has to be selected by manually setting the entry point). This makes it likely that such programs will not have proper unicode arguments.
Sylvain
After a long time, I found out more clearly what was going wrong.
The native libraries should be built with a "APP_PLATFORM" as low as possible.
Ideally, APP_PLATFORM should be equals to the minSdkVersion of the AndroidManifest.xml
So that the application never runs on a lower APP_PLATFORM than it has been built for.
An additional good patch would be to write explicitly in "jni/Application.mk": APP_PLATFORM=android-10
(If no APP_PLATFORM is set, the "targetSdkVersion" of the AndroidManifest.xml is applied as an APP_PLATFORM to the native libraries. And currently, this is bad, because targetSdkVersion is 12, whereas minSdkLevel is 10.
And in fact, there is a warning from ndk: "Android NDK: WARNING: APP_PLATFORM android-12 is larger than android:minSdkVersion 10 in ./AndroidManifest.xml".)
to precise what happened in the initial reported test-case:
Let say the "c" code contains a call to "srand()".
with APP_PLATFORM=android-21, libSDL2.so contains a undef reference to "srand()".
with APP_PLATFORM=android-10, libSDL2.so contains a undef reference to "srand48()".
but srand() is missing on devices with APP_PLATFORM=android-10 (it was in fact replaced by srand48()).
So, if you build for android-21 (where srand() is available), you will really have a call to "srand()" and it will fail on android-10.
That was the issue. The path tried to fix this by in fact always calling srand48().
SDL patches that were applied are beneficial anyway, there are implicitly allowing they backward compatibility of using android-21 on a android-10 platform.
It can be helpful in case you want to target a higher APP_PLATFORM than minSdkVersion to have potentially access to more functions.
Eg you want to have access to GLES3 functions (or other) of "android-21". But, if dlopen() fails (on android-10), you do a fall-back to GLES2.
Robert Folland
When running this little test program with SDL2 on Wayland it often crashes in SDL_Init.
From a backtrace it is apparent that there is a race condition in creating a xkb_context_ref. Sometimes it is 0x0.
By moving the relevant lines higher up in Wayland_VideoInit (in SDL2-2.0.4/src/video/wayland/SDL_waylandvideo.c:302) this seems to get fixed.
I moved the call to WAYLAND_xkb_context_new() up to before the call to WAYLAND_wl_display_connect().
Here is the test program (just a loop of init and quit), and a backtrace from gdb:
#include <cstdio>
#include <stdlib.h>
#include <SDL2/SDL.h>
#include <unistd.h>
#include <iostream>
int main(int argc, char **argv)
{
int count = atoi(argv[1]);
for (int i = 0; i < count; i++) {
std::cout << "Init " << i << std::endl;
if (SDL_Init(SDL_INIT_VIDEO) < 0) {
SDL_LogError(SDL_LOG_CATEGORY_APPLICATION,
"Couldn't initialize SDL: %s\n",
SDL_GetError());
return 1;
}
std::cout << "Quit" << std::endl;
SDL_Quit();
}
return 0;
}
Init 12
Quit
Init 13
Program received signal SIGSEGV, Segmentation fault.
xkb_context_ref (ctx=ctx@entry=0x0) at src/context.c:156
156 ctx->refcnt++;
(gdb) bt
#0 xkb_context_ref (ctx=ctx@entry=0x0) at src/context.c:156
#1 0x00007ffff5e1cd4c in xkb_keymap_new (ctx=0x0, format=XKB_KEYMAP_FORMAT_TEXT_V1, flags=flags@entry=XKB_KEYMAP_COMPILE_NO_FLAGS) at src/keymap-priv.c:65
#2 0x00007ffff5e1c6cc in xkb_keymap_new_from_buffer (ctx=<optimized out>,
buffer=0x7ffff7fd5000 "xkb_keymap {\nxkb_keycodes \"(unnamed)\" {\n\tminimum = 8;\n\tmaximum = 255;\n\t<ESC>", ' ' <repeats 16 times>, "= 9;\n\t<AE01>", ' ' <re
peats 15 times>, "= 10;\n\t<AE02>", ' ' <repeats 15 times>, "= 11;\n\t<AE03>", ' ' <repeats 15 times>, "= 12;\n\t<AE04>", ' ' <repeats 12 times>..., length=48090,
format=<optimized out>, flags=<optimized out>) at src/keymap.c:191
#3 0x00007ffff7b8ea4e in keyboard_handle_keymap (data=0x6169b0, keyboard=<optimized out>, format=<optimized out>, fd=5, size=48091)
at /home/vlab/abs/sdl2/src/SDL2-2.0.4/src/video/wayland/SDL_waylandevents.c:269
#4 0x00007ffff64501f0 in ffi_call_unix64 () from /usr/lib/libffi.so.6
#5 0x00007ffff644fc58 in ffi_call () from /usr/lib/libffi.so.6
#6 0x00007ffff665be3e in wl_closure_invoke (closure=closure@entry=0x61f000, flags=flags@entry=1, target=<optimized out>, target@entry=0x616d20,
opcode=opcode@entry=0, data=<optimized out>) at src/connection.c:949
#7 0x00007ffff6658be0 in dispatch_event (display=<optimized out>, queue=<optimized out>) at src/wayland-client.c:1274
#8 0x00007ffff6659db4 in dispatch_queue (queue=0x617398, display=0x6172d0) at src/wayland-client.c:1420
#9 wl_display_dispatch_queue_pending (display=0x6172d0, queue=0x617398) at src/wayland-client.c:1662
#10 0x00007ffff665a0cf in wl_display_roundtrip_queue (display=0x6172d0, queue=0x617398) at src/wayland-client.c:1085
#11 0x00007ffff7b8faa0 in Wayland_VideoInit (_this=<optimized out>) at /home/vlab/abs/sdl2/src/SDL2-2.0.4/src/video/wayland/SDL_waylandvideo.c:302
#12 0x00007ffff7b7aed6 in SDL_VideoInit_REAL (driver_name=<optimized out>, driver_name@entry=0x0) at /home/vlab/abs/sdl2/src/SDL2-2.0.4/src/video/SDL_video.c:513
#13 0x00007ffff7ae0ee7 in SDL_InitSubSystem_REAL (flags=16416) at /home/vlab/abs/sdl2/src/SDL2-2.0.4/src/SDL.c:173
#14 0x0000000000400b24 in main (argc=2, argv=0x7fffffffebb8) at vplay-init.cpp:13
(gdb)
Eric wing
Sometimes an SDL_assert triggers at RPI_WarpMouseGlobal
src/video/raspberry/SDL_rpimouse.c:232 'update'.
It doesn't always reproduce, but it seems to happen when you really bog down the system and the event loop can't update for awhile.
The first time I hit this, I wasn't even using the mouse. I don't call any warp mouse functions either.
I can usually reproduce with a simple program that runs an expensive blocking CPU series of functions which blocks the main loop until complete (can be up to 10 seconds).
Sometimes this assertion gets triggered after that. I'm not sure if
they are related or coincidental.
Disabling the SDL_asserts when compiling SDL will avoid this problem. I actually haven't seen any problems with the mouse when I do this.
On a Raspberry Pi 2 running Raspbian Jessie.
Call SDL_GL_GetDrawableSize() directly because we may be in the initialization path and SDL_GetRendererOutputSize() will fail because the renderer magic isn't set up yet.
Daniel Gibson
Ok, I followed the simple approach of just making SDL_PIXELFORMAT_RGBA32 an alias of SDL_PIXELFORMAT_RGBA8888/SDL_PIXELFORMAT_ABGR8888, depending on endianess. And I did the same for SDL_PIXELFORMAT_ARGB32, .._BGRA, .._ABGR.
SDL_GetPixelFormatName() will of course return SDL_PIXELFORMAT_RGBA8888 (or SDL_PIXELFORMAT_ABGR8888) instead of SDL_PIXELFORMAT_RGBA32, but as long as that's mentioned in the docs it shouldn't be a problem.
Apparently some systems see "hw:", some see "default:" and some see
"sysdefault:" (and maybe others!). My workstation sees both "hw:" and
"sysdefault:" ...
Try to find a prefix we like and prioritize the prefixes we (think) we want
most. If everything else fails, if there's a "default" (not a prefix) device
name, list that by itself so the user gets _something_ here.
If we can't find a prefix we like _and_ there's no "default" device, report
no hardware found at all.
Weitian Leung
Just moved ibus direct call to SDL_IME_* related functions, and adds fcitx IME support (uses DBus, too),
enable with env: SDL_IM_MODULE=fcitx (ibus still the default one)
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.
x414e54
Wayland will sometimes send empty resize events (0 width and 0 height) to the client. I have not worked out the exact conditions a client would receive these but I can assume it might be if the window is offscreen or not mapped yet.
This causes issues with some SDL clients as they receive the 0x0 event and unexpected resize event or might not request to resize back to the correct size.
As per the wl_shell Wayland spec configure events are only a suggestion and the client is free to ignore or pick a different size (this is how min/max and fixed aspect ratio is supped to be implemented).
A patch is attached but is just the first iteration and I will fix any issues such as checking for FULLSCREEN/MAXIMIZED or RESIZABLE flags unless someone else fixes this first.
I have update to take into account non resizable and fullscreen windows. Also adding in maximize/restore and title functions for Wayland.
Darren Kulp
The dummy video driver is not available on Mac OS X if SDL_VIDEO_OPENGL is set at library compilation time.
In src/video/SDL_video.c, there is a compile-time check in SDL_CreateWindow() for (SDL_VIDEO_OPENGL && __MACOSX__). When it succeeds, SDL_WINDOW_OPENGL is always requested. Since the dummy video driver does not supply an OpenGL implementation, the error "No OpenGL support in video driver" is supplied to the user, and SDL_CreateWindow() is exited early.
Adam M.
When doing a rotated texture copy with the software renderer, where the angle is a multiple of 90 degrees, one or two edges of the image get cut off. This is because of the following line in sw_rotate.c:
if ((unsigned)dx < (unsigned)sw && (unsigned)dy < (unsigned)sh) {
which is effectively saying:
if (dx >= 0 && dx < src->w-1 && dy >= 0 && dy < src->h-1) {
As a result, it doesn't process pixels in the right column or bottom row of the source image (except when they're accessed as part of the bilinear filtering for nearby pixels). This causes it to look like the edges are cut off, and it's especially obvious with an exact multiple of 90 degrees.
Michael Labb?
NVidia has released some pretty nice Tegra profiling tools for their Android devices. The NVidia Tegra Graphics Debugger works by providing an interposer library that intercepts ES2 and EGL calls. You must link against these libraries.
Unfortunately, this quietly fails with SDL2 because libEGL and libGLES2 are dynamically loaded with dlopen().
NVidia offers a secondary approach to using the Tegra Graphics Debugger: root your device and install a global interposer library. Almost no devs will try this first if they don?t have a rooted device.
I propose an update to the Android readme that explains why the static linking approach recommended by NVidia doesn?t work.
Nitz
In function SDLgfx_rotateSurface:
rz_dst =
SDL_CreateRGBSurface(SDL_SWSURFACE, dstwidth, dstheight + GUARD_ROWS,
rz_src->format->Rmask, rz_src->format->Gmask,
rz_src->format->Bmask, rz_src->format->Amask);
Here rz_src get De-referenced without NULL check, which is risky.
Simon Sandstr?m
As stated in Summary. The switch statement will execute the default case and set a SDL error message: "SDL_MixAudio(): unknown audio format".
There are atleast two more problems here:
1. SDL_MixAudioFormat does not notify the user that an error has occured and that a SDL error message was set. It took me awhile to understand why I couldn't mix down the volume on my AUDIO_U16LSB formatted audio stream.. until I started digging in the SDL source code.
2. The error message is incorrect, it should read: "SDL_MixAudioFormat(): unknown audio format".
Daniel Gibson
Currently, SDL_CreateRGBSurface() and SDL_CreateRGBSurfaceFrom() take Uint32 masks for RGBA to "describe" the Pixelformat of the surface.
Internally those value are only used to map to one of the SDL_PIXELFORMAT_* enum values that are used for further processing.
I think it would be both handy and more efficient to be able to specify SDL_PIXELFORMAT_* yourself without using SDL_PixelFormatEnumToMasks() to create masks first, so I implemented functions that do that:
SDL_CreateRGBSurfaceWithFormat() and SDL_CreateRGBSurfaceWithFormatFrom() which are like the versions without "WithFormat" but instead of taking 4 Uint32s for R/G/B/A masks, they take one for a SDL_PIXELFORMAT_* enum value.
Together with https://bugzilla.libsdl.org/show_bug.cgi?id=2923 creating a SDL_Surface* from RGBA data (e.g. from stb_image) is as easy as
surf = SDL_SDL_CreateRGBSurfaceWithFormat(0, w, h, bppToUse*8, SDL_PIXELFORMAT_RGBA32);
Ryan C. Gordon
We still include iconv.h in SDL_stdinc.h, probably because this header might have referenced the native iconv functions and types directly. Since these are hidden behind a stable ABI now and never just a #define for the system iconv, we shouldn't need this header included from a public SDL header anymore, slowing down external apps compiles and pulling tons of stuff into the namespace.
Jan Klass
Not sure if this is limited to the joystick subsystem,
but I created a minimal program for reproducibility,
which is attached.
The issue occurs with my gamepad Razer Onza (an xbox-style gamepad) plugged in.
On initialization, the gamepad is being recognized.
After quitting the subsystem, the poll will receive the joystick added event,
which it instantly handles itself, calling SDL_SYS_JoystickDetect again,
which this time calls IDirectInput8_EnumDevices with dinput = NULL (after it was released on quit).
This seems to lead to an access violation within said function, which I have no source for.
Jan Hellwig
On Windows, you are able to navigate between the buttons on a MessageBox that was created using SDL_ShowMessageBox using the arrow keys. However, if you press the left arrow key, the selection jumps to the button on the right of the currently selected one (and vice versa).
This can be fixed by reversing the order in which the buttons are added to the dialog.
The attached patch files fixes this problem. However the first press of an arrow key leads to the selection of the leftmost or rightmost button on the MessageBox, not to the selection of the button left/right of the one that is selected by default.
Ryochan7
I have been using SDL 2 for a little project that I have been developing for a while. My project is called antimicro and it takes gamepad input and then translates gamepad events into keyboard and mouse events. SDL is used to read the input from an XInput gamepad and it works great for the most part. However, there is one glaring problem that I have encountered.
When a device is unplugged and SDL sends the centered value release events for all axes, buttons, and hats, SDL does not use the proper centered value for the triggers. It pushes an SDL_JOYAXISMOTION event onto the queue with a value of 0 for all axes. That value is converted to around 16,000 for a Game Controller. That value is incorrect for triggers and, in my program, that causes any bindings that are assigned to the triggers to get activated. With most profiles, that will typically mean that a mouse right click and left click will be activated before the device is finally seen as removed and then those bindings are released by antimicro.
Jonas Kulla
At startup time, the single android window is assigned a "windowed" (window->windowed.{w,h}) size based on the current orientation of the mobile device; this size is never updated throughout the lifetime of the app.
This becomes problematic when the app is paused and then resumed in an orientation that it did not start up in. Eventually, 'SDL_OnWindowRestored()' is called, which calls 'SDL_UpdateFullscreenMode()'. This function is very problematic because it is written with a desktop monitor in mind: it tries to find a matching display mode for the windowed size, doesn't find any, and finally applies the windowed size as the fullscreen one. In the end, the windowed size is reported in a RESIZED event, which doesn't correspond to the actual surface size.
To see this in action: Start an orientation aware SDL app in eg. portrait mode, suspend the app, put the device into landscape orientation and resume the app. It will erroneously render in portrait mode (until the device is rotated again).
This tends to be a frequent spot where drivers hang, and the waits were
often unreliable in any case.
Instead, our audio thread now alerts the driver that we're done streaming audio
(which currently XAudio2 uses to alert the system not to warn about the
impending underflow) and then SDL_Delay()'s for a duration that's reasonable
to drain the DMA buffers before closing the device.
This tries to make SDL robust against device drivers that have hung up,
apps don't freeze in catastrophic (but not necessarily uncommon) conditions.
Now we detach the audio thread and let it clean up and don't care if it
never actually runs to completion.
James Zipperer
The problem I was seeing was that the the ALSA hotplug thread would call SDL_RemoveAudioDevice, but my application code was not seeing an SDL_AUDIODEVICEREMOVED event to go along with it. To fix it, I added some code into SDL_RemoveAudioDevice to call SDL_OpenedAudioDeviceDisconnected on the corresponding open audio device. There didn't appear to be a way to cross reference the handle that SDL_RemoveAudioDevice gets and the SDL_AudioDevice pointer that SDL_OpenedAudioDeviceDisconnected needs, so I ended up adding a void *handle field to struct SDL_AudioDevice so that I could do the cross reference.
Is there some other way beside adding a void *handle field to the struct to get the proper information for SDL_OpenedAudioDeviceDisconnected?
James Zipperer
Close the audio device before waiting for the audio thread to complete, which fixes a situation where the audio thread never completes
Add an additional check in the audio thread to see if the device is enabled and bail out if the device is no longer enabled
Joe Thompson
With Direct Input device (MOMO Steering Wheel w/FF)
with SDL 2.0.3,
SDL_HapticOpenFromJoystick() would fail. (Can't set exclusive mode)
Now with 2.0.4 rc1,
SDL_HapticOpenFromJoystick() succeeds but the the returned SDL_Haptic* cannot be used. Calls to SDL_HapticNewEffect() fail with "Haptic error Unable to create effect"
If SDL_HapticOpen() is used instead of HapticOpenFromJoystick(), the device is usable. Calls to HapticNewEffect() succeed with the exact same parameters as the previous failing call.
I have attached a proposed patch for this issue.
When using SDL_HapticOpenFromJoystick(), the original code did not (re)enumerate the axes. This returned a new haptic device with 0 axes. Later, when a new effect is created, SDL_SYS_SetDirection() would set the flags to include DIEFF_SPHERICAL, regardless of what the caller actually set. (see Line 566 in SDL_dinputhaptic.c). This would cause the SDL_HapticNewEffect() to fail (or interpret the coordinates incorreclty.)
The patch moves the call to IDirectInputDevice8_EnumObjects() outside of the if() block so that the axes are (re)enumerated for the new haptic device.
Note: For steering wheels it is common for the joystick to have multiple axes (ie steering, throttle, brake), but the haptic portion of the joystick usually only applies to steering.
Fixes Bugzilla #3441.
"When using internal SDL_vsnprintf(), and source string length is greater
than destination, the final NULL char will be written beyond destination size.
Primary issue that is SDL_strlcpy returns length of source string
(SDL_PrintString()), not how much is written to destination. The destination
ptr is then incremented by this length before the sanity check is done.
Destination string is properly terminated, but an extra NULL char will be
written beyond destination buffer length.
Patch used internally is attached which fixes primary issue with SDL_strlcpy()
in SDL_PrintString() and adjusts sanity checks to increment destination ptr
safely."
Tim McDaniel
Using checkkeys test app:
* Press and hold Caps Lock key.
* checkkeys reports a CapsLock key pressed event and a CapsLock key released event.
* Release Caps Lock key.
* checkkeys reports no further events.
This patch fixes OSX Caps Lock up/down event detection by installing a HID callback.
Ray Molenkamp
When building sdl as shared lib, the version info is lacking in the final binary.
CMake gathers the right resource files into ${VERSION_SOURCES} but then doesn't do anything with them.
Deve
When I'm trying to close on-screen keyboard using SDL_StopTextInput() function by touching the screen (SDL_FINGERUP or SDL_FINGERDOWN event), the screen is flickering. It is white for a while.
Note that it usually works without problems when I use phone's "back" button. I noticed flickering occasionally too, but not that often.
Philipp Wiesemann
The attached patch maybe fixes the flicker but not the actual fault causing it.
Timo Gurr
On cross hosts running autotools for SDL2_gfx-1.0.1 fails to find sdl2.m4:
eautoreconf: running in /var/tmp/paludis/build/media-libs-SDL2_gfx-1.0.1/work/SDL2_gfx-1.0.1 ...
aclocal
aclocal-1.13: warning: autoconf input should be named 'configure.ac', not 'configure.in'
configure.in:128: warning: macro 'AM_PATH_SDL2' not found in library
libtoolize --copy --force --automake
aclocal
aclocal-1.13: warning: autoconf input should be named 'configure.ac', not 'configure.in'
configure.in:128: warning: macro 'AM_PATH_SDL2' not found in library
autoconf
configure.in:128: error: possibly undefined macro: AM_PATH_SDL2
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
* Failed Running autoconf !
SDL2 installs it to /usr/x86_64-pc-linux-gnu/share/aclocal on cross hosts, attached patch makes use of CMAKE_INSTALL_FULL_DATAROOTDIR to support correctly installing to the arch independent location /usr/share/aclocal.
John Wordsworth
While attempting to integrate CEF (Browser) into an SDL application, we noticed that there were problems on OS X where approximately 50% of the input events were essentially being lost - even when we were using off-screen rendering in CEF and passing through input events manually.
It appears that this problem has been around for a while (see: http://www.magpcss.org/ceforum/viewtopic.php?f=6&t=11141).
Please consider the following patch that fixes this issue. Instead of processing events directly after calling [NSApp nextEventMatchingMask:...] we now pass these events down to NSApp, for processing by an overloaded sendEvent: method. Chromium also forwards events to NSApp in the same way, which means we don't miss events, even if they were originally dequeued by CEF.
Daniel
Seems like check of the visibility of renderer (renderer->hidden) is missing in SDL_RenderCopyEx.
In SDL_RenderCopy it should be done much earlier (after checking support for RenderCopyEx, line 1750).
Michael
In SDL_x11modes.c the CalculateXRandRRefreshRate() function performs integer math on values that may return fractional results. This causes a value that would be calculated as 59.99972... to be returned as 59. In Linux the xrandr command returns 60Hz for this particular display mode yet SDL returns 59Hz.
I suggest this function be updated to correctly round the result of the calculation instead of truncating the result.
Machiel van Hooren
In SDL_dxjoystick.c line 349 there is a constant c_dfDIJoystick2.
However, this constant is aparently also defined in dinput8.lib.
I encountered a linking error when statically linking to SDL:
SDL2_static.lib(SDL_dxjoystick.obj) : error LNK2005: _c_dfDIJoystick2 already defined in dinput8.lib
My application is also linking to dinput8.lib because we rolled our own joystick input and are not using the joystick functionality from SDL.
Patrick Gutlich
The mouse cursor gets corrupted when the mouse moves over the screen edges (right and bottom) a weird type of scaling seems to occur and you end up with a blank square.
tvc
I've spent the last few days implementing touchscreen support in core/linux/SDL_evdev.c. It's fairly rudimentary at the moment, as can be seen from the multiple TODO's and FIXME's littered throughout, but I'm mainly submitting this patch for review. I've tested this patch on my Raspberry Pi 2 with the official touchscreen and it works fantastically, reporting all 10 multitouch points. I'm happy to work on this further, the evdev logic also needs a bit of a cleanup I think (I may have included a few changes). But if it's good enough in its current state to be committed then I'm sure there'd be plenty of people pleased, as currently the only other framework/library that supports touchscreens on the Raspberry Pi is Kivy.
Fritzor
Source Suface is ABGR and Destination Surface is ABGR. We use software blending. In the Switch-Case statement for SDL_COPY_BLEND (Line 126) the alpha-channel is not calculated like in every SDL_blit_auto - function. So if the destination Surface has alpha - channel of zero the resulting surface has zero as well.
Add: ?dstA = srcA + ((255 - srcA) * dstA) / 255;? to code and everything is okay.
Marcel Bakker
Observed when resizing or moving a window in Windows 7.
Depending on how you resize/move your window
, you may receive none or a lot of SDL_WINDOWEVENT_EXPOSED events
, at the moment you release the mouse button.
Maybe add this event to an already existing list of overflow candidates ?
C.W. Betts
Swift is very strict with types, so much that those of different signedness/size must be cast. Most of the defines are imported as 32-bit signed integers, while the corresponding field in a struct is a 32-bit unsigned integer. Appending a "u" would cause the defined types to be imported as 32-bit unsigned integers.
Yann Dirson
When attempting to force use of opengles2 renderer with:
int wanted_renderer = -1;
for (int i = 0; i < numrenderers; i++) {
SDL_RendererInfo renderer_info;
if (SDL_GetRenderDriverInfo(i, &renderer_info) != 0) {
SDL_LogError(SDL_LOG_CATEGORY_APPLICATION, "Couldn't get renderer driver info: %s\n",
SDL_GetError());
quit(2);
}
std::cerr << "Renderer " << i << " '" << renderer_info.name << "': flags=0x"
<< std::hex << renderer_info.flags << std::dec
<< ", " << renderer_info.num_texture_formats << " texture formats, max="
<< renderer_info.max_texture_width << "x"
<< renderer_info.max_texture_height << "\n";
if (!strcmp(renderer_info.name, "opengles2")) {
std::cerr << " selecting!\n";
wanted_renderer = i;
}
}
renderer = SDL_CreateRenderer(window, wanted_renderer, 0);
... on banana pi or raspberry pi I get an error like the following (the actual
context profile value varies, being used uninitialized)
ERROR: Couldn't create renderer: Unknown OpenGL context profile 900
With this patch I get the following, which should help more pointing to a real problem:
ERROR: Couldn't create renderer: Failed getting OpenGL glGetString entry point
I pushed a patch (based on master branch of unofficial git mirror):
550389c89f
I'll be opening a different bug for the underlying issue.
Evgeny Vrublevsky
Original code in the video/windows/SDL_windowsevents.c registers obsolete WNDCLASS (not WNDCLASSEX). As the result only one icon size is used as the small and normal icons. Also original code doesn't specify required size of an icon. As the result when 256x256 icon is available, the program uses it as a default icon, and it looks ugly.
We have to use WNDCLASSEX and load icons with proper sizes which we can get using GetSystemMetrics.
Better idea. We could use the first icon from resources, like the Explorer does. Patch is included. It also correctly loads large and small icons, so it will look nice everywhere.
ny00
Using the OpenGL ES 1.1 renderer, after updating a texture with SDL_UpdateTexture (or SDL_UnlockTexture), a following call to SDL_RenderFillRect draws a rectangle with the wrong color (which appears to be the same as the texture's top-left pixel).
Comparing SDL_render_gles.c:GLES_UpdateTexture to SDL_render_gl.c:GL_UpdateTexture, a missing call to glDisable appears to be the cause. After adding it back, the bug is resolved.
ny00
On Android, the keycodes KEYCODE_BUTTON_1..16 (actual values 188-203) are translated to SDL_Joystick buttons no. 20-35. These are currently ignored in SDL_gamecontroller.c.
The attached patch fixes this, by increasing k_nMaxReverseEntries from 20 to another arbitrary bound of 48.
Side-note: Maybe some log should be emitted in case of going over any such bound?
jfverdon
Genie (https://github.com/bkaradzic/genie) is a well known premake fork which uses internally Lua 5.3 (as opposed to version 5.1 used in premake4).
As there is some Lua's API breaks in Lua 5.2, SDL premake scripts do not works with premake.
The two incompatibilities I noticed were:
* unhandle modes "rt" and "wt" for io.open. Has io.open opens files in text mode by default, the "t" flag is not needed (this flag is not supported in Genie).
* os.execute signature change, the return value is a tuple from Lua 5.2, before it was just the called program exit code.
winterknight
The showrev.sh script shows the tip, instead of the current hg revision. This can be mismatched if one were to use hg update -r ??? to revert to a previous revision.
Patch uses parents instead of tip, which will show the revision that the source is compiled with, instead of the latest revision that the user who is compiling has downloaded.
joe.gsoc16
I recently looked into Unicode support in SDL2 and realized that
SDL_TEXTEDITING doesn't get triggered at all (Japanese IME).
According to others on IRC it works fine on Windows/Mac but not
for me on (arch)Linux.
When compiling SDL with autotools, IBus support is enabled by
default but not so with CMake.
I never used CMake before but got it working and also included
that pkg-config determines flags for dbus (FIXME in CMakeLists).
Diego
The keyboard on iPads has a dismiss button that hides the keyboard. When the keyboard was hidden using that button, instead of the return key, SDL was still reporting IsTextInputActive as true. This patch adds an extra SDL_StopTextInput when iOS reports the keyboard will hide.
Simon Hug
I'm proposing some changes to the IME test program test/testime.c. The patch includes support for the GNU Unifont hex file, making the SDL_ttf dependency optional. There were also one or two bugs that prevented the text and underline from showing up poperly.
Simon Hug
There's a call to the POSIX function random in test/testqsort.c. Naturally, Windows doesn't do that. The attached patch changes the call to the SDLtest framework random functions and adds some seed control.
Looking at SDLTest_RandomInitTime, I just want to say that 'srand((unsigned int)time(NULL)); a=rand(); srand(clock()); b=rand();' is an absolutely terrible way to initialize a seed on Windows because of its terrible LCG.
Simon Hug
The SDLmain file src/main/windows/SDL_windows_main.c defines both entry points for console applications, main and wmain. This seems to confuse MSVC. It outputs a LNK4067 warning and then chooses main, which is a shame because only wmain has the unicode handling. Using SDLmain.lib provided on libsdl.org, the linker also goes for main.
I'm proposing to not define the main entry point at all. wmain should be supported well enough with MSVC.
Simon Hug
The two tests test/testaudioinfo.c and test/testaudiohotplug.c are missing error checking when they call SDL_GetAudioDeviceName. This function can return NULL which the tests pass straight to SDL_Log.
Eric Wasylishen
The bug here is that a dead keys pressed before calling SDL_StartTextInput() carries over into future text input, so the next key pressed will have the deadkey applied to it.
This in undesirable, imho, and doesn't occur on OS X (haven't check Linux or elsewhere). It's causing a problem for Quakespasm on German keyboard layouts, where we use the ^ deadkey to toggle the console (which enables/disables text input), and ^ characters are showing up in the TEXTINPUT events.
Simon Hug
The function console_wmain in src/main/windows/SDL_windows_main.c does not null terminate the argument list it is creating. As specified by the C standard, "argv[argc] shall be a null pointer."
The SDLTest framework makes use of that null pointer and some test programs can cause an access violation because it's missing.
Simon Hug
The description of the SDL_RenderClear function in the SDL_render.h header says the following:
"This function clears the entire rendering target, ignoring the viewport."
The word "entire" implies that the clipping rectangle set with SDL_RenderSetClipRect also gets ignored. This is left somewhat ambiguous if only the viewport is mentioned. Minor thing, but let's see what the implementations actually do.
The software renderer ignores the clipping rectangle when clearing. It even has a comment on this: /* By definition the clear ignores the clip rect */
Most other render drivers (opengl, opengles, opengles2, direct3d, and psp [I assume. Can't test it.]) use the scissor test for the ClipRect and don't disable it when clearing. Clearing will only happen within the clipping rectangle for these drivers.
An exception is direct3d11 which uses a clear function that ignores the scissor test.
Simon Hug
When updating the viewport in GLES_UpdateViewport, the OpenGL ES renderer doesn't flip the projection matrix for target textures. The lines, rectangles and textures (if drawn with glDrawArrays) are upside down when drawing to target textures.
Simon Hug
The OpenGL ES 2 renderer does not check the target texture format when using SDL_RenderReadPixels and just always uses ABGR8888. This can result in swapped or wrong colors.
The attached patch adds a check and selects the target texture format, if a texture is set as the target.
Simon Hug
All OpenGL renderers always flip the rows of the pixels that come from glReadPixels. This is unnecessary for target textures since these are already top down.
Also, the rect->y value can be used directly for target textures for the same reason. I don't see any code that would handle the logical render size for target textures. Or am I missing something?
The attached patch makes the renderers only the flip rows if the data comes from the default framebuffer.
Simon Hug
The current SDL_SaveBMP_RW function that saves surfaces to a BMP uses an old bitmap header which doesn't officially support alpha channels. Applications just ignore the byte where the alpha is stored. This can easily be extended by using a newer header version and setting the alpha mask.
The attached patch has these changes:
- Extending the description of the function in the SDL_surface.h header with the supported formats.
- Refining when surfaces get stored to a 32-bit BMP. (Must have bit depth of 8 or higher and must have an alpha mask or colorkey.)
- Fixing a small bug that saves 24-bit BGR surfaces with a colorkey in a 24-bit BMP.
- Adding code that switches to the bitmap header version 4 if the surface has an alpha mask or colorkey. (I chose version 4 because Microsoft didn't lose its documentation behind a file cabinet like they did with version 3.)
- Adding a hint that can disable the use of the version 4 header. This is for people that need the legacy header or like the old behavior better. (I'm not sure about the hint name, though. May need changing if there are any rules to that.)
Simon Hug
The GL_SetBlendMode and GLES_SetBlendMode functions of the opengl and opengles renderers call the glTexEnvf to set the texture env mode to either GL_MODULATE (the default) or GL_REPLACE for the NONE blend mode. Using GL_REPLACE disables color and alpha modulation for textures.
These glTexEnv calls were put in the SetBlendMode function back in 2006 [1], but there the NONE code still used the GL_DECAL mode. The GL_REPLACE mode came in 2008 [2]. I'm a bit confused why that wasn't always GL_MODULATE and a bit surprised nobody reported that yet (unless I missed it). I guess only a few use the gles renderer and the newish shaders mask the issue.
Simon Hug
The GL_CreateTexture function doesn't have any checks for the case where the driver doesn't support the framebuffer object extension. It will call into GL_GetFBO which will call the non-existent glGenFramebuffersEXT.
Also, for some reason GL_CreateContext always sets the SDL_RENDERER_TARGETTEXTURE info flag, even if it is not supported. Changeset cc226dce7536 [1] makes this change, but doesn't explain why. It seems to me like the code would already have taken care of this [2].
The attached patch adds some checks and stops SDL from reporting render target support if there is none. The application can then properly inform the user instead of just crashing.
Simon Hug
When the SDL_Blit_Slow function compares the pixel to the color key it does so without removing the alpha component from the pixel value and the key. This is different from the optimized 32-bit blitters which create a rgb mask and apply it to both to filter the alpha out. SDL_Blit_Slow will only skip the pixels with the exact alpha value of the key instead of all pixels with the same color.
The attached test case blits a surface with a color key and prints the pixel values to the console. The third row is expected to be skipped.
Simon Hug
It seems not everyone implemented glDrawTexfOES the same. Intel and Mesa ignore the viewport entirely, whereas the Raspberry Pi implementation offsets the coordinates and does viewport clipping.
The glDrawTexfOES extension text [1] for the function says "Xs and Ys are given directly in window (viewport) coordinates." I guess this wasn't clear enough.
Alex Szpakowski
Honestly I'd probably remove that codepath from SDL_Render entirely. It's an OpenGL ES 1-specific extension that isn't likely to give huge performance gains and adds additional maintenance overhead to SDL_Render while also having bugs in some drivers (as seen here).
SFC30 controller: http://www.8bitdo.com/sfc30/
The SFC30 controller can present itself in a variety of modes and it offers up
different names in each. This patch captures data for three modes (one USB and
two Bluetooth) on three platforms (Mac OS X, Windows, Linux).
However, USB mode on Linux and Windows is missing as the button events did not
make it through to SDL's controllermap tool on Fedora 24/Linux 4.5.5 nor Steam
Big Picture mode on Windows. The two Bluetooth modes were indistinguishable on
Windows. Two modes on OS X were indistinguishable.
There exists a similar controller called the SNES30 (And some others) that are
very likely identical except for the name, but I have not verified this yet so
haven't synthesized lines for those controllers until I can.
Kai Sterker
There are already patches available from mingw64 that fix the issue
https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-SDL2
With those applied, I could compile SDL2 without problems. But of course, it would be preferable if SDL built cleanly from source.
Vitaly Novichkov
Line 124
====================================================================
const DWORD flags = thread->stacksize ? STACK_SIZE_PARAM_IS_A_RESERVATION : 0;
====================================================================
Error of compiler:
====================================================================
CC build/SDL_systhread.lo
src/thread/windows/SDL_systhread.c: In function 'SDL_SYS_CreateThread':
src/thread/windows/SDL_systhread.c:124:45: error: 'STACK_SIZE_PARAM_IS_A_RESERVA
TION' undeclared (first use in this function)
const DWORD flags = thread->stacksize ? STACK_SIZE_PARAM_IS_A_RESERVATION :
0;
^
src/thread/windows/SDL_systhread.c:124:45: note: each undeclared identifier is r
eported only once for each function it appears in
make: *** [build/SDL_systhread.lo] Error 1
====================================================================
Fixing when I adding into begin of the file:
====================================================================
#ifndef STACK_SIZE_PARAM_IS_A_RESERVATION
#define STACK_SIZE_PARAM_IS_A_RESERVATION 0x00010000
#endif
====================================================================
ny00
This report is going to cover three issues, with a suggestion for fixes. For reference, tests were done using an installation of android-x86-5.1-rc1.iso within a VirtualBox session. I've actually used an adapter that accepts up to two Playstation 1/2 controllers.
A ZIP file should be attached, with the following contents:
- The patch file itself.
- Outputs of joysticks lists from testjoystick with different orders (before fixing bug).
- Game controllers database entries (for reference).
--- Different outputs for different platforms may stem from different tools being used; The Android mapping was manually constructed using a previously available mapping as a base.
--- Note that it turns out the Linux mapping is already out there in some form: https://github.com/gabomdq/SDL_GameControllerDB/blob/master/gamecontrollerdb.txt
And so, let's begin listing the issues:
1. While changeset https://hg.libsdl.org/SDL/rev/9b540bea3cf1 has good intentions, it appears to make various input devices being mistakenly detected as SDL joysticks. I got lists of the devices from joysticktest, given in the ZIP file. "badordering.txt" is what I get if the device has been plugged since a reboot of the virtual machine, while I've gotten "goodordering.txt" after hot-plugging the USB adapter. As expected, only in the latter case I could use the controller in the test program (assuming it isn't modified).
To take care of this, I updated pollInputDevices and added the function SDLActivity.isDeviceSDLJoystick, in order to have a better filter. Note that it also checks that the device id is non-negative, since VIRTUAL_KEYBOARD appears to include a SOURCE_DPAD, and I should probably keep accepting it as an SDL_joystick (good if you want, say, to support multiple independent d-pad devices).
I hope the device id filter does not break support for the virtual remote (mentioned in the changeset above).
2. So there's a weird glitch here, where the game controller is reported to have SOURCE_KEYBOARD and SOURCE_JOYSTICK, while each controller button press/release emits a KeyEvent with SOURCE_KEYBOARD only. So obviously any test going over the event's own sources is expected to fail.
It is possible to try and filter by the key code, but then there are the dpad key codes, which can also be emitted by actual PC keyboard's key presses/releases (the arrow keys).
So instead, I just call the newly added isDeviceSDLJoystick function again and check if the input device (not the event) has any source considered to be a joystick/gamepad for us.
3. Finally, if SDL2 properly detects an SDL_Joystick being connected, but it is not opened, then whenever a KeyEvent is received after a button press/release from the same controller, SDLActivity.onNativePadDown/onNativePadUp returns a negative value. In such a case, the onKey handler continues to check for SOURCE_KEYBOARD (and possibly also SOURCE_MOUSE), which is clearly not desired.
And so, in the given patch, the return values of onNativePadDown and onNativePadUp are ignored and "true" is returned either way.
(Note: Maybe the native functions should be modified to have the return value of "void".)
Finally, as another side-note, I've noticed that the various bitwise tests for sources are wrong. For instance, to check if an InputDevice 'device' has source SOURCE_JOYSTICK, the value (device.getSources() & SOURCE_JOYSTICK) should be compared to SOURCE_JOYSTICK, not 0.
However, I think there's enough that this patch covers. At the least, isDeviceSDLJoystick partially solves this.
neoaggelos
It is common for Mac OS X to use the SDL2.framework instead of the classic UNIX dynamic lib.
Therefore, it makes sense for AM_PATH_SDL2() to be able to locate it. Attached is a patched sdl2.m4 (updated for that purpose).
Changes:
* look for SDL2.framework ONLY if pkg-config and sdl2-config tests failed (this is to ensure compatibility with the old behaviour)
* adds option ('--disable-sdlframework') to retreat to the old behaviour
* adds variable 'SDL2_FRAMEWORK' for the user to specify the exact path to SDL2.framework (e.g. if it is installed in a non-standard location)
Open to suggestions for further improvements
The Apple TV remote is currently exposed as a joystick with its touch surface treated as two axes. Key presses are also generated when its buttons and touch surface are used.
A new hint has been added to help deal with deciding whether to background the app when the remote's menu button is pressed: SDL_HINT_APPLE_TV_CONTROLLER_UI_EVENTS.
Previously when the canvas was scaled up and the pointer was locked,
motion corresponding to less than one pixel was lost. Therefore,
slow mouse motion resulted in no motion. This fixes that.
Browsers don't have the functionality to fully support the generic
SDL_ShowMessageBox(), but this handles the likely most-common case.
Without this, you'd return immediately with a proper error result and no UI,
but probably no one checks that for SDL_ShowSimpleMessageBox. And if they
did: what would they do to handle this anyhow?
We'd need to lobby for an HTML spec of some sort that allows customizable
message boxes--that block!--to properly support SDL message boxes on
Emscripten, but this is probably Good Enough for now.
AudioQueues are available in Mac OS X 10.5 and later (and iOS 2.0 and later).
Their API is much more clear (and if you don't mind the threading tapdance
to get its own CFRunLoop) much easier to use in general for our purposes.
As an added benefit: they seemlessly deal with format conversion in ways
AudioUnits don't: for example, my MacBook Pro's built-in microphone won't
capture at 8000Hz and the AudioUnit version wouldn't resample to hide this
fact; the AudioQueue version, however, can handle this.
Generate the C protocol files from the protocol XML files installed by
wayland-protocols, and use them to implement support for relative pointer
motions and pointer locking.
Note that at the time, the protocol is unstable and may change in the future.
Any future breaking changes will, however, fail gracefully and result in no
regressions compared to before this patch.
Since we are loading shared objects dynamically, build our own version of the
core protocol symbols, so that we in the future can include protocol
extensions.
This will be used by Wayland compositors to match the application ID and
.desktop file to the SDL window(s).
Applications can set the SDL_VIDEO_WAYLAND_WMCLASS environemnt variable
early in the process to override using the binary name as a fallback.
Note that we also support the SDL_VIDEO_X11_WMCLASS in the Wayland
backend so that if a program correctly associated the desktop file with
the window under X11, only a newer SDL would be needed for it to work
under Wayland.
https://bugzilla.libsdl.org/show_bug.cgi?id=3376
Author: James Zipperer <james.zipperer@synapse.com>
Date: Sun Aug 21 01:19:19 2016 -0700
bugfix for controller / joystick add / remove being in the event queue at the same time
The repro steps were this:
1. run an sdl2 winrt/uwp app, on Win10, v10.0.10586.0 or higher
2. hide the cursor, via a call to SDL_ShowCursor(0)
3. make the Win10 game bar appear, by pressing the Windows + G hotkey
4. observe that the mouse cursor appears, in order to interact with the
game bar (this is expected behavior)
5. make the Win10 game bar disappear, either by pressing the Windows + G hotkey
again, or clicking somewhere in the app
EXPECTED RESULT: cursor disappears, as game bar disappears
ACTUAL RESULT: cursor didn't always disappear
Moved this code from winmm into core so both can use it.
DirectSound (at least on Win10) also returns truncated device names, even
though it's handed in as a string pointer and not a static-sized buffer. :/
The Windows 10 Anniversary Update (1607) breaks the method uses that SDL uses to
detect XInput devices. That is, on Windows 10 Anniversary Update, it is no longer
possible to query RAWINPUT for HID devices, and check for "IG_" in the device name.
Presumably, this will be fixed in the future.
This patch works around the issue by adding the Xbox One controller series to the
well-known device list.
This skips the more expensive RAWINPUT check for those devices, and causes them to
be detected as XInput devices once again.
Otherwise, if you had a massive, one-time queue buildup, the memory from that
remains allocated until you close the device. Also, if you are just using a
reasonable amount of space, this would previously cause you to reallocate it
over and over instead of keeping a little bit of memory around.
I think this was important for SDL 1.2 because some targets needed
special device memory for DMA buffers or locked memory buffers for use in
hardware interrupts or something, but since it just defines to SDL_malloc
and SDL_free now, I took it out for clarity's sake.
- It's now always called if device->hidden isn't NULL, even if OpenDevice()
failed halfway through. This lets implementation code not have to clean up
itself on every possible failure point; just return an error and SDL will
handle it for you.
- Implementations can assume this->hidden != NULL and not check for it.
- implementations don't have to set this->hidden = NULL when done, because
the caller is always about to free(this).
- Don't reset other fields that are in a block of memory about to be free()'d.
- Implementations all now free things like internal mix buffers last, after
closing devices and such, to guarantee they definitely aren't in use anymore
at the point of deallocation.
Turns out that libartsc isn't thread-safe, so if we run a capture and playback
device at the same time, it often crashes in arts's internal event loop.
We could throw mutexes around the read/write calls, but these are meant to
block, so one device could cause serious latency and stutter in the other.
Since this audio target isn't in high-demand (Ubuntu hasn't offered a libartsc
package for years), I'm just backing out the capture support. If someone needs
it, they can pull it out of the revision history.
(We probably never noticed because this is meant to block until it fully
writes a buffer, and would only trigger an issue if we had a short write
that wasn't otherwise an error condition.)
This workaround, unfortunately, requires that apps directly link to a set of
Win32-style cursor resource files (that contain a transparent cursor image).
Copies of suitable resource files are in src/core/winrt/, and should be
included directly in an app's MSVC project.
A rough explanation of this workaround/hack, and why it's needed (and
seemingly can't be done through programmatic means), is in this change's code.
This allows us to set an explicit stack size (overriding the system default
and the global hint an app might have set), and remove all the macro salsa
for dealing with _beginthreadex and such, as internal threads always set those
to NULL anyhow.
I've taken some guesses on reasonable (and tiny!) stack sizes for our
internal threads, but some of these might turn out to be too small in
practice and need an increase. Most of them are simple functions, though.
Win10's 'GamepadAdded' event seems to need to have something registered with it
in order for Xinput-based gamepad detection to work. This 'fix' simply causes
a dummy event-handler to be added for this event, in case an app wants to use
gamepads on Xbox One (most likely).
This is kind of nasty, because ALSA reports dozens of "devices" that aren't
really things you'd ever want, or things that should be listed this way, but
the default path still works as before, and it at least allows these devices
to be available to apps.
This does not handle hotplugging yet. You get a device list at init time
and that's it.
- Cache the _NET_FRAME_EXTENTS data locally, so we don't have to query
the X server for them (instead, we update our cached data when PropertyNotify
events alert us to a change).
- Use our cached extents for X11_GetWindowBordersSize(), so it's a fast call.
- Window position was meant to refer to the client area, not the window
decorations, so adjust appropriately when getting/setting the position.
We now only raise the magic exception that names the thread when
IsDebuggerPresent() returns true. In such a case, Visual Studio will
catch the exception, set the thread name, and let the debugged process
continue normally. If the debugger isn't running, we don't raise an exception
at all.
Setting the name is a debugger trick; if the debugger isn't running, the name
won't be set if attached later in any case, so this doesn't lose functionality.
This lets this code work without assembly code, on win32 and win64, and
across various compilers.
The only "gotcha" is that if you have something attached that looks like a
debugger but doesn't respect this magic exception trick, the process will
likely crash, but that's probably a deficiency of the attached program.
Fixes Bugzilla #2089.
The returned value is currently not used by the caller. The instance id would
also not be needed on Java side and providing it just complicated the function.
Partially fixes Bugzilla #3234.
This assert triggers when run under XMonad. It's safe to pass a zero here
anyhow, as this will still work "well enough" and the original
problem--GNOME printing a warning message--is still fixed because GNOME's
window manager gives us a chance to grab a non-zero user-time value before
this code is run.
(and thanks to Cengiz for many of the previous Unreal-related
patches! They were generically credited to Epic Games, but a large
amount of that work was his contribution.)
Fixes Bugzilla #3067.
This is for corner cases where a multi-window app is activated and wants to
make a decision about where focus should go.
This patch came from Unreal Engine 4's fork of SDL, compliments of Epic Games.
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.
This lets windows know when they are dropping a mouse event because their
hit test reported something other than SDL_HITTEST_NORMAL. It lets them know
exactly where in the event queue this happened.
This patch is based on work in Unreal Engine 4's fork of SDL,
compliments of Epic Games.
This is currently implemented for X11, Cocoa, Windows, and DirectFB.
This patch is based on work in Unreal Engine 4's fork of SDL,
compliments of Epic Games.
This allows an app to know when a set of drops are coming in a grouping of
some sort (for example, a user selected multiple files and dropped them all
on the window with a single drag), and when that set is complete.
This also adds a window ID to the drop events, so the app can determine to
which window a given drop was delivered. For application-level drops (for
example, you launched an app by dropping a file on its icon), the window ID
will be zero.
Specifically: always on top, skip taskbar, tooltip, utility, and popup menu.
This is currently only implemented for X11.
This patch is based on work in Unreal Engine 4's fork of SDL,
compliments of Epic Games.
Notably: it sets the error string to inform you that your custom SDL is built
without xrandr support, which apparently has been a support issue for
Unreal Engine 4 developers.
This is often useful for SDL apps that aren't meant to be games: the
integrated GPU starts up faster, uses less power, and is often more than
fast enough.
Note that even with this change, the app will still default to the more
powerful, discrete GPU if one is available; an app that prefers the integrated
GPU will still need the NSSupportsAutomaticGraphicsSwitching key properly
set in its Info.plist and Mac OS X 10.7 or later.
https://developer.apple.com/library/mac/qa/qa1734/_index.html
Martin Gerhardy
According to https://msdn.microsoft.com/de-de/library/2kzt1wy3%28v=vs.120%29.aspx when one is using /MT for msvc compilations the libcmt.lib is already linked to the binary. This lib includes the symbol that is now guarded (see attached patch) by the #ifndef _MT.
I don't know if any joysticks report those usages for any buttons in practice, but other prominent Mac gaming software exposes them, so we might as well too.
xaudio2 is not linked against sdl but the sdk already handles dynamically loading (XAudio2Create is inlined and just loads a com object). Updated SDL_xaudio2.c
DXGI fails to report any displays in at least one of the
"Windows App Certification Kit 10.0"'s tests for Store Apps. This was
causing SDL's video initialization code to fail, when the suspect test
("Direct3D Feature Test") was run, as DXGI was unable to report a
display-output at adapter-index 0, output-index 0.
The workaround that is applied here attempts to detect this case, then
use a hopefully-reasonable alternative means to calculate at least one
display output.
"UWP" appears to be Microsoft's new name for WinRT/Windows-Store APIs.
This set of changes updates SDL's WinRT backends to support the Win10 flavor
of WinRT. It has been tested on Win10 on a desktop. In theory, it should
also support Win10 on other devices (phone, Xbox One, etc.), however further
patches may be necessary.
This adds:
- a set of MSVC 2015 project files, for use in creating UWP apps
- modifications to various pieces of SDL, in order to compile via MSVC 2015 +
the Win10 API set
- enables SDL_Window resizing and programmatic-fullscreen toggling, when using
the WinRT backend
- WinRT README updates
WinRT 8.0 (Phone and non-Phone) didn't offer an API to set an already-created
thread's priority. WinRT 8.1 offered this API, along with several other
Win32 thread functions that were previously unavailable (in WinRT).
This change makes WinRT 8.1+ platforms use SDL's Win32 backend.
This change-set fixes a lot of windowing related bugs, especially with
regards to Windows 8.x apps running on Windows 10 (which was the driver for
this work). The primary fixes include:
* listed display modes were wrong, especially when launching apps into a
non-fullscreen space
* reported window flags were often wrong, especially on Windows 10
* fullscreen/windowed mode switches weren't failing (they are not
programmatically possible in Win 8.x apps).
This change has also been tested as buildable + runnable on Win32 + MSVC 2015,
2013, 2012, and 2010. It may fix similar build errors (in XInput code) that
are appearing in MingW builds (on buildbot).
This conversation came from Joshua Granick on Twitter, starting here:
https://twitter.com/singmajesty/status/653640543675641857
"We found an issue where certain Android keyboards (like the S6 with
predictive text) wouldn't work ... Certain keyboards use a predictive text
mode that does not dispatch a traditional onKey events, which is troublesome
... but telling the OS to use a "visible password" keyboard helps deal with
this problem ... perhaps there's some other way (onKeyPreIme?) to do
"textediting" events, but for now, this should be a fast fix ...
I hear it affects the Galaxy Tab A 8.0", Galaxy S6, Asus ZenPhone 2, maybe
others"
They were not needed internally since the switch to the common EGL backend.
Thanks to the SDL mailing list for pointing out that the functions seem unused.
It was redundant because SDLActivity already inherits an empty method from the
base class SurfaceView (which does not implement it but inherits it from View).
Visibility of onDraw() in SDLActivity is now protected again instead of public.
The Y coordinate is flipped in Cocoa, so if you change the height, the window
will move and maybe clip against the screen edge if you don't adjust its Y
coordinate to match.
Possibly fixes Bugzilla #3066.
Unity's window manager is (legitimately, since it moves the client window's
position) sending one, and SDL was incorrectly trying to mask it out. Other
window managers (KWin, apparently) don't move the window and would hang here
indefinitely.
Fixes Bugzilla #3052.
Martin Gerhardy
Just a minor thing, but a huge outcome. All the other jni related functions already have those flags, but the nativeInit function lacks them - so it might be stripped away.
In extremely rare cases, probably due to misconfigured drivers, one might
see this happen, and rather than terminate the process, we try to recover
by reporting an error to the app.
Fixes Bugzilla #3068.
Note that extra steps must be taken when using glReadPixels to read the contents of the main OpenGL ES framebuffer on iOS, if multisampling is used. See the OpenGL ES section of README-ios.md for details.
There are platforms it isn't implemented on (and currently can't be
implemented on!), and there's currently no way for an app to know this.
This shouldn't break ABI on apps that moved to a revision between 2.0.3 and
2.0.4.
This relies on a successful SDL_Init(SDL_INIT_VIDEO) to work, since it's
silly to reproduce all the Xinerama/XRandR code in the message box parts. If
X11 is available but SDL hasn't been initialized, the message box will center
in the primary screen, which will be positioned weirdly on multi-head setups,
but this should fix the most significant common case.
Author: Benoit Pierre <benoit.pierre@gmail.com>
Date: Fri Jul 3 02:17:10 2015 +0200
fix 14dd48ae5bc43b61b2a0dd0b3177d22edec707ef regression
The window manager detection code in X11_HasWindowManager does not work
with Awesome (http://awesome.naquadah.org/). Remove it, and reuse the
result of the more correct checks in X11_CheckWindowManager.
Elise Maurer
When inputting text, dead-keys are currently not handled correctly on Windows with the latest SDL2 tip as well as the 2.0.3 release.
Using a French AZERTY keyboard, when I type the `^` key followed by `e` key to compose the `` character, I erroneously get two SDL_TEXTINPUT events, one with the `^` character and one with the `e` character.
I've looked at the history for SDL_windowsevents.c and there's been some back-and-forth with several methods for handling text input:
* r8142 removed any handling of WM_CHAR because keyboard input was being handled through WM_KEYDOWN along with ToUnicode since r7645.
* But using ToUnicode actually breaks dead-keys (googling for "ToUnicode dead keys" reports many horror stories of people trying to work around that and failing).
* It seems like r7645 introduced a double-fix: it fixed WM_CHAR to properly handle Unicode, and also (unnecessarily?) added text input handling to WM_KEYDOWN. Later, r8142 removed the WM_CHAR stuff instead of the WM_KEYDOWN stuff.
The attached patch restores handling of text input through WM_CHAR and removes it from WM_KEYDOWN. I've tested it with French, English and Russian layouts and it seems to do its job. Obviously, with such matters, it's still a risky change.
Sometimes, on removal SDL_EVDEV_udev_callback() gets called with zero udev_class. This in turn seems to be caused the SDL_udev.c:guess_device_class() failing to find the attributes of the parent device.
Apparently this is normal, attributes are not guaranteed to be in place during removal, depending on timing. This lack of attributes causes guess_device_class() to return zero.
This fix mimics the code in linux/SDL_sysjoystick.c:joystick_udev_callback() which effectively has the same fix already in place.
- disable compiling in XAudio2 support. We both need the DX SDK to make this code plus we need to work out the runtime dependency problem this code bring in on windows (needing the DX runtime installed).
CR: SamL
- do the scancode to keyboard code lookup for the grave key, so that we can show users the correct keyface for the key, rather than forcing it to "`". Note that if a game is using SDLK_* for its KB mapping then after this change on some keyboards the top left key will no longer be mapped correctly with the old data.
CR: SamL
Adam M.
It loses the title and icon when window recreation fails. For instance, this may happen when trying to create an OpenGL ES window on a system that doesn't support it. But at that point, the title and icon have already been lost.
The internal function SDL_EGL_LoadLibrary() did not delete and remove a mostly
uninitialized data structure if loading the library first failed. A later try to
use EGL then skipped initialization and assumed it was previously successful
because the data structure now already existed. This led to at least one crash
in the internal function SDL_EGL_ChooseConfig() because a NULL pointer was
dereferenced to make a call to eglBindAPI().
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).
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)
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.
Requirements: Mac OS X v10.5 or later and the iPhone SDK.
Instructions:
1. Open SDL.xcodeproj (located in Xcode-iOS/SDL) in XCode.
2. Select your desired target, and hit build.
There are three build targets:
- libSDL.a:
Build SDL as a statically linked library
- testsdl
Build a test program (there are known test failures which are fine)
- Template:
Package a project template together with the SDL for iPhone static libraries and copies of the SDL headers. The template includes proper references to the SDL library and headers, skeleton code for a basic SDL program, and placeholder graphics for the application icon and startup screen.
FIXME: This needs to be updated for the latest methods
Here is the easiest method:
1. Build the SDL libraries (libSDL.a and libSDLSimulator.a) and the iPhone SDL Application template.
1. Install the iPhone SDL Application template by copying it to one of XCode's template directories. I recommend creating a directory called "SDL" in "/Developer/Platforms/iOS.platform/Developer/Library/XCode/Project Templates/" and placing it there.
2. Start a new project using the template. The project should be immediately ready for use with SDL.
Here is a more manual method:
1. Create a new iPhone view based application.
2. Build the SDL static libraries (libSDL.a and libSDLSimulator.a) for iPhone and include them in your project. XCode will ignore the library that is not currently of the correct architecture, hence your app will work both on iPhone and in the iPhone Simulator.
3. Include the SDL header files in your project.
4. Remove the ApplicationDelegate.h and ApplicationDelegate.m files -- SDL for iPhone provides its own UIApplicationDelegate. Remove MainWindow.xib -- SDL for iPhone produces its user interface programmatically.
5. Delete the contents of main.m and program your app as a regular SDL program instead. You may replace main.m with your own main.c, but you must tell XCode not to use the project prefix file, as it includes Objective-C code.
SDL for iPhone supports polling the built in accelerometer as a joystick device. For an example on how to do this, see the accelerometer.c in the demos directory.
The main thing to note when using the accelerometer with SDL is that while the iPhone natively reports accelerometer as floating point values in units of g-force, SDL_JoystickGetAxis reports joystick values as signed integers. Hence, in order to convert between the two, some clamping and scaling is necessary on the part of the iPhone SDL joystick driver. To convert SDL_JoystickGetAxis reported values BACK to units of g-force, simply multiply the values by SDL_IPHONE_MAX_GFORCE / 0x7FFF.
Your SDL application for iPhone uses OpenGL ES for video by default.
OpenGL ES for iPhone supports several display pixel formats, such as RGBA8 and RGB565, which provide a 32 bit and 16 bit color buffer respectively. By default, the implementation uses RGB565, but you may use RGBA8 by setting each color component to 8 bits in SDL_GL_SetAttribute.
If your application doesn't use OpenGL's depth buffer, you may find significant performance improvement by setting SDL_GL_DEPTH_SIZE to 0.
Finally, if your application completely redraws the screen each frame, you may find significant performance improvement by setting the attribute SDL_GL_RETAINED_BACKING to 1.
Each application installed on iPhone resides in a sandbox which includes its own Application Home directory. Your application may not access files outside this directory.
Once your application is installed its directory tree looks like:
MySDLApp Home/
MySDLApp.app
Documents/
Library/
Preferences/
tmp/
When your SDL based iPhone application starts up, it sets the working directory to the main bundle (MySDLApp Home/MySDLApp.app), where your application resources are stored. You cannot write to this directory. Instead, I advise you to write document files to "../Documents/" and preferences to "../Library/Preferences".
More information on this subject is available here:
Full-size, single window applications only. You cannot create multi-window SDL applications for iPhone OS. The application window will fill the display, though you have the option of turning on or off the menu-bar (pass SDL_CreateWindow the flag SDL_WINDOW_BORDERLESS).
Textures:
The optimal texture formats on iOS are SDL_PIXELFORMAT_ABGR8888, SDL_PIXELFORMAT_ABGR8888, SDL_PIXELFORMAT_BGR888, and SDL_PIXELFORMAT_RGB24 pixel formats.
Loading Shared Objects:
This is disabled by default since it seems to break the terms of the iPhone SDK agreement. It can be re-enabled in SDL_config_iphoneos.h.
Game Center integration requires that you break up your main loop in order to yield control back to the system. In other words, instead of running an endless main loop, you run each frame in a callback function, using:
int SDL_iPhoneSetAnimationCallback(SDL_Window * window, int interval, void (*callback)(void*), void *callbackParam);
This will set up the given function to be called back on the animation callback, and then you have to return from main() to let the Cocoa event loop run.
e.g.
extern "C"
void ShowFrame(void*)
{
... do event handling, frame logic and rendering
}
int main(int argc, char *argv[])
{
... initialize game ...
#if __IPHONEOS__
// Initialize the Game Center for scoring and matchmaking
InitGameCenter();
// Set up the game to run in the window animation callback on iOS
// so that Game Center and so forth works correctly.
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.
