Added SDL_HasAVX2() to detect CPUs with AVX2 support
Added SDL_SetWindowHitTest() to let apps treat parts of their SDL window
like traditional window decorations (drag areas, resize areas)
Added SDL_GetGrabbedWindow() to get the window that currently has input
grab, if any
Added SDL_RenderIsClipEnabled() to tell whether clipping is currently
enabled in a renderer
Added SDL_CaptureMouse() to capture the mouse to get events while the
mouse is not in your window
Added SDL_WarpMouseGlobal() to warp the mouse cursor in global screen
space
Added SDL_GetGlobalMouseState() to get the current mouse state outside of
an SDL window
Added a direction field to mouse wheel events to tell whether they are
flipped (natural) or not
Added GL_CONTEXT_RELEASE_BEHAVIOR GL attribute (maps to
[WGL|GLX]_ARB_context_flush_control extension)
Added EGL_KHR_create_context support to allow OpenGL ES version selection
on some platforms
Added NV12 and NV21 YUV texture support for OpenGL and OpenGL ES 2.0
renderers
Added a Vivante video driver that is used on various SoC platforms
Added an event SDL_RENDER_DEVICE_RESET that is sent from the D3D
renderers when the D3D device is lost, and from Android’s event loop when
the GLES context had to be recreated
Added a hint SDL_HINT_NO_SIGNAL_HANDLERS to disable SDL’s built in signal
handling
Added a hint SDL_HINT_THREAD_STACK_SIZE to set the stack size of SDL’s
threads
Added SDL_sqrtf(), SDL_tan(), and SDL_tanf() to the stdlib routines
Improved support for WAV and BMP files with unusual chunks in them
Renamed SDL_assert_data to SDL_AssertData and SDL_assert_state to
SDL_AssertState
Windows:
Added support for Windows Phone 8.1
Timer resolution is now 1 ms by default, adjustable with the
SDL_HINT_TIMER_RESOLUTION hint
SDLmain no longer depends on the C runtime, so you can use the same .lib
in both Debug and Release builds
Added SDL_SetWindowsMessageHook() to set a function to be called for
every windows message before TranslateMessage()
Added a hint SDL_HINT_WINDOWS_ENABLE_MESSAGELOOP to control whether
SDL_PumpEvents() processes the Windows message loop
You can distinguish between real mouse and touch events by looking for
SDL_TOUCH_MOUSEID in the mouse event “which” field
SDL_SysWMinfo now contains the window HDC
Added support for Unicode command line options
Prevent beeping when Alt-key combos are pressed
SDL_SetTextInputRect() re-positions the OS-rendered IME
Mac OS X:
Implemented drag-and-drop support
Improved joystick hot-plug detection
The SDL_WINDOWEVENT_EXPOSED window event is triggered in the appropriate
situations
Fixed relative mouse mode when the application loses/regains focus
Fixed bugs related to transitioning to and from Spaces-aware
fullscreen-desktop mode
Fixed the refresh rate of display modes
SDL_SysWMInfo is now ARC-compatible
Linux:
Enabled building with Mir and Wayland support by default.
Added IBus IME support
Added a hint SDL_HINT_IME_INTERNAL_EDITING to control whether IBus should
handle text editing internally instead of sending SDL_TEXTEDITING events
Added support for multiple audio devices when using Pulseaudio
Fixed duplicate mouse events when using relative mouse motion
iOS:
Added support for iOS 8
Added support for the hint SDL_HINT_ACCELEROMETER_AS_JOYSTICK
Added sRGB OpenGL ES context support on iOS 7+
Added native resolution support for the iPhone 6 Plus
The SDL_WINDOW_ALLOW_HIGHDPI window flag now enables high-dpi support,
and SDL_GL_GetDrawableSize() or SDL_GetRendererOutputSize() gets the window
resolution in pixels
SDL_GetWindowSize() and display mode sizes are in the “DPI-independent
points” coordinate space rather than pixels (matches OS X behavior)
SDL_SysWMinfo now contains the OpenGL ES framebuffer and color
renderbuffer objects used by the window’s active GLES view
Fixed various rotation and orientation issues
Fixed memory leaks
Android:
Added a hint SDL_HINT_ANDROID_SEPARATE_MOUSE_AND_TOUCH to prevent mouse
events from being registered as touch events
Docs/README-macosx.md mentions a ‘build-scripts/fatbuild.sh’ shell script for building a 32-/64-bit library, but this file doesn’t exist. Please advise on how to build a fat library on OS X.
Gamepad support seems to have been broken in my application on Windows between SDL-2.0.3 and SDL-2.0.4-RC2. SDL detects and reports the gamepad (Logitech RumblePad 2), but my application doesn’t receive any gamepad input anymore. Keyboard and mouse do work. SDL-2.0.3 worked fine.
Compiling both 2.0.3 and 2.0.4 on 32-bit MinGW and running with the release binaries from the website.
Compiling both 2.0.3 and 2.0.4 on 32-bit MinGW and running with the release binaries from the website.
I tested some more, with a self-compiled 2.0.4-RC2 DLL and with a second gamepad type, but still no dice. This is on Windows 7 64-bit. Gamepads (connected at startup) are detected and list their names correctly, but no input seems to be passed to the application at all. Works correctly on OS X.
Simply replacing the 2.0.4 DLL with any 2.0.3 DLL makes the gamepads work again.
There’s a g++-fat.sh too, but there’s no C++ code in SDL2, so that’s
optional.
Use it like this, from the Terminal
cd /where/i/cloned/SDL
mkdir mybuild
cd mybuild
CC=/where/i/cloned/SDL/build-scripts/gcc-fat.sh ../configure
make
“configure” and “make” think they’re talking to GCC, but gcc-fat.sh
actually calls gcc multiple times: for x86 and x86_64, and glues the
resulting binaries together into a Universal binary.
(The PowerPC support is still in there, although SDL2 doesn’t compile
out of the box on PowerPC Mac OS X anymore.)
–ryan.On 06/21/2015 09:09 AM, RobLM wrote:
Docs/README-macosx.md mentions a ‘build-scripts/fatbuild.sh’ shell
script for building a 32-/64-bit library, but this file doesn’t exist.
Please advise on how to build a fat library on OS X.
Ryan, can you update the documentation?On Mon, Jun 22, 2015 at 3:50 PM, Ryan C. Gordon wrote:
On 06/21/2015 09:09 AM, RobLM wrote:
Docs/README-macosx.md mentions a ‘build-scripts/fatbuild.sh’ shell
script for building a 32-/64-bit library, but this file doesn’t exist.
Please advise on how to build a fat library on OS X.
It’s build-scripts/gcc-fat.sh now.
There’s a g++-fat.sh too, but there’s no C++ code in SDL2, so that’s
optional.
Use it like this, from the Terminal
cd /where/i/cloned/SDL
mkdir mybuild
cd mybuild
CC=/where/i/cloned/SDL/build-scripts/gcc-fat.sh …/configure
make
“configure” and “make” think they’re talking to GCC, but gcc-fat.sh
actually calls gcc multiple times: for x86 and x86_64, and glues the
resulting binaries together into a Universal binary.
(The PowerPC support is still in there, although SDL2 doesn’t compile out
of the box on PowerPC Mac OS X anymore.)
Does your application window have focus? You need to send the hint
SDL_HINT_JOYSTICK_ALLOW_BACKGROUND_EVENTS if you want to get joystick
events when your application doesn’t have focus.On Sun, Jun 21, 2015 at 8:18 AM, RobLM <rob.l.molenaar at gmail.com> wrote:
RobLM wrote:
Compiling both 2.0.3 and 2.0.4 on 32-bit MinGW and running with the
release binaries from the website.
I tested some more, with a self-compiled 2.0.4-RC2 DLL and with a second
gamepad type, but still no dice. This is on Windows 7 64-bit. Gamepads
(connected at startup) are detected and list their names correctly, but no
input seems to be passed to the application at all. Works correctly on OS X.
Simply replacing the 2.0.4 DLL with any 2.0.3 DLL makes the gamepads work
again.
I just did a rebuild and very quick spot check on the following
systems. Everything worked. Using the SDL 2D API. No problems to
report.
OS X (10.10.3) 64-bit.
iOS 8.3 (iPad mini 1st gen armv7, 64-bit iOS simulator)
Android (tested on Nexus 7 2013 4.4.4)
Linux (Ubuntu 12.04 LTS, 64-bit)
Windows classic, 64-bit (tested on Win 8.1)
Raspberry Pi 2 (Raspbian, activating cortex-a7 and NEON compiler flags
on SDL and my stuff)
I just found a problem on Raspberry Pi. I have a benchmark test
program that sometimes triggers an SDL_assert at RPI_WarpMouseGlobal
src/video/raspberry/SDL_rpimouse.c:232 ‘update’.
I don’t yet understand the reason for this or how to reproduce it
reliably. The first time I hit this, I wasn’t even using the mouse. I
don’t call any warp mouse functions either.
My program 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.
Thanks,
EricOn 6/23/15, Eric Wing <@Eric_Wing> wrote:
I just did a rebuild and very quick spot check on the following
systems. Everything worked. Using the SDL 2D API. No problems to
report.
OS X (10.10.3) 64-bit.
iOS 8.3 (iPad mini 1st gen armv7, 64-bit iOS simulator)
Android (tested on Nexus 7 2013 4.4.4)
Linux (Ubuntu 12.04 LTS, 64-bit)
Windows classic, 64-bit (tested on Win 8.1)
Raspberry Pi 2 (Raspbian, activating cortex-a7 and NEON compiler flags
on SDL and my stuff)
SDL draws the mouse pointer for you since there’s no windows manager doing
that, so there may well be a bug there. It would be great to narrow it down.
2015-06-23 22:39 GMT-03:00 Eric Wing :> On 6/23/15, Eric Wing wrote:
I just did a rebuild and very quick spot check on the following
systems. Everything worked. Using the SDL 2D API. No problems to
report.
OS X (10.10.3) 64-bit.
iOS 8.3 (iPad mini 1st gen armv7, 64-bit iOS simulator)
Android (tested on Nexus 7 2013 4.4.4)
Linux (Ubuntu 12.04 LTS, 64-bit)
Windows classic, 64-bit (tested on Win 8.1)
Raspberry Pi 2 (Raspbian, activating cortex-a7 and NEON compiler flags
on SDL and my stuff)
Thanks,
Eric
I just found a problem on Raspberry Pi. I have a benchmark test
program that sometimes triggers an SDL_assert at RPI_WarpMouseGlobal
src/video/raspberry/SDL_rpimouse.c:232 ‘update’.
I don’t yet understand the reason for this or how to reproduce it
reliably. The first time I hit this, I wasn’t even using the mouse. I
don’t call any warp mouse functions either.
My program 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.
Okay, I think I can reliably reproduce the problem now.
I do the startup with an SDL_Init() and all my normal initialization stuff.
Then right before I enter my main while() loop, I do an SDL_Delay(6000).
Then I start clicking around and moving the mouse.
So far this has reliably triggered the assertion.
I did this in both the console and in the GUI desktop.
Also a note: The SDL_assert will not allow me to enter any input when
in the console. (I see a Abort/Break/Retry/Ignore/AlwaysIgnore
prompt.) My keyboard presses have no effect. (I have to kill via ssh
from another machine.)
In the desktop mode, I can enter keys only if the display has not yet
been taking over to show (fullscreen) SDL.
Thanks,
EricOn 6/23/15, Gabriel Jacobo wrote:
SDL draws the mouse pointer for you since there’s no windows manager doing
that, so there may well be a bug there. It would be great to narrow it
down.
Does your application window have focus? You need to send the hint SDL_HINT_JOYSTICK_ALLOW_BACKGROUND_EVENTS if you want to get joystick events when your application doesn’t have focus.
I found the culprit: apparently 2.0.4 on Windows requires SDL_INIT_JOYSTICK to be supplied to SDL_Init() for game controllers to work. I’m not sure why just (SDL_INIT_VIDEO | SDL_INIT_GAMECONTROLLER) doesn’t work anymore since I don’t have any interest in regular joysticks.
2015-06-24 10:11 GMT-03:00, RobLM <rob.l.molenaar at gmail.com>:
I found the culprit: apparently 2.0.4 on Windows requires SDL_INIT_JOYSTICK
to be supplied to SDL_Init() for game controllers to work. I’m not sure why
just (SDL_INIT_VIDEO | SDL_INIT_GAMECONTROLLER) doesn’t work anymore since I
don’t have any interest in regular joysticks.
Don’t you need the Joystick API to open the joysticks?
Sounds like a bug though since I recall SDL_INIT_GAMECONTROLLER
including the SDL_INIT_JOYSTICK flag implicitly. Huh.
2015-06-24 10:11 GMT-03:00, RobLM <@RobLM>:
Don’t you need the Joystick API to open the joysticks?
No, I only use SDL_GameController*() functions. Game controllers in SDL are not “joysticks” (as a API user, I shouldn’t have to care about its internals). In 2.0.3 everything worked without explicitly using the SDL_INIT_JOYSTICK flag.
Anyway. I think I found another minor bug in 2.0.4: on OS X (10.10.3) the right analog stick’s vertical (Y) axis seems to be returning values smaller than 0 (“up”) right after system startup instead of 0 like in 2.0.3. One I pull the stick in my application, the value properly resets to 0.
It only appears to affect the first startup of the application after system boot. Subsequent unplugging and plugging-in of the game controller doesn’t cause the issue to reappear.
I think I just found a bug while testing the hot swapping of controllers.
When an SDL_CONTROLLERDEVICEADDED event is found, sdlEvent.cdevice.which reports the wrong controllers.
Example: Two controllers are plugged in. I remove one and plug it back in a few moments later. sdlEvent.cdevice.which then gives the index of the other controller, not the one just plugged in.