SDL 2.0.9 prerelease

slouken · September 28, 2018, 9:25am

Thanks to all the people who contributed code and feedback, SDL 2.0.9 is now available as a PRERELEASE build!
http://www.libsdl.org/tmp/download-2.0.php

In addition to lots of bug fixes and build improvements, here are the major changes in this release:
General:

Added a new sensor API, initialized by passing SDL_INIT_SENSOR to SDL_Init(), and defined in SDL_sensor.h
Added an event SDL_SENSORUPDATE which is sent when a sensor is updated
Added SDL_GetDisplayOrientation() to return the current display orientation
Added an event SDL_DISPLAYEVENT which is sent when the display orientation changes
Added HIDAPI joystick drivers for more consistent support for Xbox, PS4 and Nintendo Switch Pro controller support across platforms. (Thanks to Valve for contributing the PS4 and Nintendo Switch Pro controller support)
Added support for many other popular game controllers
Added SDL_GameControllerRumble() and SDL_JoystickRumble() which allow simple rumble without using the haptics API
Added SDL_GameControllerMappingForDeviceIndex() to get the mapping for a controller before it’s opened
Added the hint SDL_HINT_MOUSE_DOUBLE_CLICK_TIME to control the mouse double-click time
Added the hint SDL_HINT_MOUSE_DOUBLE_CLICK_RADIUS to control the mouse double-click radius, in pixels
Added SDL_HasColorKey() to return whether a surface has a colorkey active
Added SDL_HasAVX512F() to return whether the CPU has AVX-512F features
Added SDL_IsTablet() to return whether the application is running on a tablet
Added SDL_THREAD_PRIORITY_TIME_CRITICAL for threads that must run at the highest priority

Mac OS X:

Fixed black screen at start on Mac OS X Mojave

Linux:

Added SDL_LinuxSetThreadPriority() to allow adjusting the thread priority of native threads using RealtimeKit if available.

iOS:

Fixed Asian IME input

Android:

Updated required Android SDK to API 26, to match Google’s new App Store requirements
Added support for wired USB Xbox, PS4, and Nintendo Switch Pro controllers
Added support for relative mouse mode on Android 7.0 and newer (except where it’s broken, on Chromebooks and when in DeX mode with Samsung Experience 9.0)
Added support for custom mouse cursors on Android 7.0 and newer
Added the hint SDL_HINT_ANDROID_TRAP_BACK_BUTTON to control whether the back button will back out of the app (the default) or be passed to the application as SDL_SCANCODE_AC_BACK
Added SDL_AndroidBackButton() to trigger the Android system back button behavior when handling the back button in the application
Added SDL_IsChromebook() to return whether the app is running in the Chromebook Android runtime
Added SDL_IsDeXMode() to return whether the app is running while docked in the Samsung DeX

rtrussell · September 28, 2018, 10:35am

Can I assume that a SDL_WINDOWEVENT_RESIZED event will also be sent in these circumstances, as was previously the case (unless the display happens to be square!)?

Shouldn’t the default be to maintain compatibility with earlier versions of SDL, i.e. to pass SDLK_AC_BACK to the application?

es5804 · September 28, 2018, 11:35am

I got this build error only when I enable video-mir:

In file included from /usr/include/mirclient/mir_toolkit/events/input/input_event.h:26:0,
                 from /usr/include/mirclient/mir_toolkit/events/event.h:91,
                 from /usr/include/mirclient/mir_toolkit/client_types.h:24,
                 from ***/SDL2-2.0.9/src/joystick/../events/../video/./khronos/vulkan/./vk_platform.h:101,
                 from ***/SDL2-2.0.9/src/joystick/../events/../video/./khronos/vulkan/vulkan.h:31,
                 from ***/SDL2-2.0.9/src/joystick/../events/../video/SDL_vulkan_internal.h:61,
                 from ***/SDL2-2.0.9/src/joystick/../events/../video/SDL_sysvideo.h:30,
                 from ***/SDL2-2.0.9/src/joystick/../events/SDL_events_c.h:26,
                 from ***/SDL2-2.0.9/src/joystick/SDL_joystick.c:33:
***/SDL2-2.0.9/src/joystick/controller_type.h:28:16: error: expected identifier before numeric constant
typedef enum { false, true } bool;
               ^

Values of the enum seem to be used only in a commented out assert in SDL_joystick.c line 1518 and the enum itself is only used one function in controller_type.h. Including SDL_stdinc.h and replacing bool by SDL_bool fixe the problem.

sezero · September 28, 2018, 1:49pm

Then the mir headers are somehow including stdbool.h which defines false and true to numeric values.

Solution should be replacing those bool stuff with SDL_bool.

sezero · September 28, 2018, 2:03pm

I pushed https://hg.libsdl.org/SDL/rev/9a334644da3e to the hg repo: should fix that boolean issue.

vygr · September 28, 2018, 9:07pm

Hi folks, new here but have an issue showing up with the 2.0.9 pre release that you might be able to help with.

I’ve been using SDL2 for about 3 years on a hobby OS project called ChrysaLisp, https://github.com/vygr/ChrysaLisp, and after an upgrade from High Sierra to Mojave I had problems building and running.

Now I saw the issue about the black screen on startup problem, and saw the fix for that was in the pre-release 2.0.9 so I’ve tried that, but no joy.

What I can tell you is that using the 2.0.9 pre-release compiled on High Sierra the resulting executable will work fine on Mojave ! Both using the 2.0.9 or 2.0.8 in the frameworks folder.

But if I compile on Mojave then the app launches and I only ever see a full red window. I know my OS is running inside that window via various debug outputs, but I never see anything but full red screen.

Running ‘otool -L’ on the exe I can see that the only difference is the stdlib dylib version number. Clearly the code may be different due to the Mojave compiler etc.

A small example code in C I tried to just do a simple filled rectangle test does work, compiled on Mojave. So this has left me a little puzzled.

I know that ChrysaLisp is far removed from your normal C/C++ applications as it’s uses it own assembler and compiler and Lisp, but things have been working fine up till this point. And the fact that the version compiled on High Sierra works fine on both is interesting.

Full source and build instructions are up on Github, only takes 2 seconds (literally) to do a build and try it out if anyone would care to investigate with me. I’m stumped after a whole day looking into it, so time to call in the SDL experts.

Regards to all

Chris

vygr · September 28, 2018, 9:24pm

Additional info. I just thought to try the Mojave executable, that shows red screen only, on High Serra (luckily I didn’t yet upgrade my older MacBbook !) and lo, it runs fine over there !

So that eliminates any issue with the code produced by the Mojave compiler clang difference as the cause and points at the difference in the stdlib dylib !

This is the output of otool -l on the main exe’s.

High Sierra built:

/Users/Chris/Desktop/main:
@rpath/SDL2.framework/Versions/A/SDL2 (compatibility version 1.0.0, current version 10.0.0)
@rpath/SDL2_ttf.framework/Versions/A/SDL2_ttf (compatibility version 15.0.0, current version 15.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)

Mojave built:

obj/Darwin/x86_64/main:
@rpath/SDL2.framework/Versions/A/SDL2 (compatibility version 1.0.0, current version 10.0.0)
@rpath/SDL2_ttf.framework/Versions/A/SDL2_ttf (compatibility version 15.0.0, current version 15.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.200.5)

Regards

Chris

blacktm · September 29, 2018, 1:59am

Awesome, I’ve been testing the default branch on macOS 10.14 and Ubuntu 18.04.1. Everything looking good except 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". I even tried rebuilding with --enable-sensor with no luck. SDL_Init(SDL_INIT_SENSOR) also reports the same error. I can’t find anything abnormal in the build system, but I’ll keep looking.

blacktm · September 29, 2018, 4:41am

@slouken Just saw your commit (231245d461a2), pulled and retested. Works great, thanks!

slouken · September 29, 2018, 9:02am

Great, thanks for checking!

flibitijibibo · September 29, 2018, 3:37pm

Will be interesting to see how all the HIDAPI stuff pans out!

There are a couple things I’m still concerned about in other parts of SDL, but thankfully they’re all really small and have patches:

#1. WASAPI is extremely fussy and expects a specific update period size, and if SDL doesn’t allow programs to find this, it can sometimes be problematic if the update sizes vary too much. The SDL_AudioStream fallback covers most cases, but not all, and I dunno if that’s something AudioStream can fix, so for us the easiest fix is SDL_AUDIO_ALLOW_SAMPLES_CHANGE:

https://bugzilla.libsdl.org/show_bug.cgi?id=4157

For Xbox in particular this is definitely a must-have. Right now FAudio is doing this, and it’s as stable as it looks:

github.com

FNA-XNA/FAudio/blob/05a554f9bab222c623cfc03d22040f611d8cecf9/src/FAudio_platform_sdl2.c#L160


		/* FIXME: SDL's WASAPI implementation does not overwrite the
		 * samples value when it really REALLY should. WASAPI is
		 * extremely sensitive and wants the sample period to be a VERY
		 * VERY EXACT VALUE and if you fail to write the correct length,
		 * you will get lots and lots of glitches.
		 * The math on how to get the right value is very unclear, but
		 * this post seems to have the math that matches my setups best:
		 * https://github.com/kinetiknz/cubeb/issues/324#issuecomment-345472582
		 * -flibit
		 */
		if (FAudio_strcmp(SDL_GetCurrentAudioDriver(), "wasapi") == 0)
		{
			FAudio_assert(want.freq == 48000);
			want.samples = 528;
		}
		else
		{
			want.samples = 1024;
		}


		/* Open the device, finally. */

#2. Haptic magnitude ranges aren’t consistent across platforms; on Linux it expects 0-65535 when everyone else wants 0-32768. There’s a patch and I think it might still apply cleanly after the HIDAPI stuff, but even then it’s a whopping 5 lines…

https://bugzilla.libsdl.org/show_bug.cgi?id=4120

Without this, programs have to do something like this:

github.com

FNA-XNA/FNA/blob/b5821ddad8afdfb36be9768f08a112aefee11579/src/FNAPlatform/SDL2_FNAPlatform.cs#L143


			 * finally broke. Interestingly this may also be wrong
			 * for LeftRightMacHack, but that was someone else's
			 * custom driver and they wrote that path so :shrug:
			 *
			 * For now, we're going to keep using u16 on Linux, and
			 * s16 > 0 everywhere else. Remove this when 2.0.9 is
			 * out, and go back to u16 when 2.1 is out and bases its
			 * magnitudes on XInput rather than DirectInput.
			 * -flibit
			 */
			if (OSVersion.Equals("Linux"))
			{
				HapticMaxWorkaround = 65535.0f;
			}
			else
			{
				HapticMaxWorkaround = 32767.0f;
			}


			/* Mount TitleLocation.Path */
			string titleLocation = GetBaseDirectory();

github.com

FNA-XNA/FNA/blob/b5821ddad8afdfb36be9768f08a112aefee11579/src/FNAPlatform/SDL2_FNAPlatform.cs#L2176




			if (haptic == IntPtr.Zero)
			{
				return false;
			}


			if (leftMotor <= 0.0f && rightMotor <= 0.0f)
			{
				SDL.SDL_HapticStopAll(haptic);
			}
			else if (type == HapticType.LeftRight)
			{
				INTERNAL_leftRightEffect.leftright.large_magnitude = (ushort) (HapticMaxWorkaround * leftMotor);
				INTERNAL_leftRightEffect.leftright.small_magnitude = (ushort) (HapticMaxWorkaround * rightMotor);
				SDL.SDL_HapticUpdateEffect(
					haptic,
					0,
					ref INTERNAL_leftRightEffect
				);
				SDL.SDL_HapticRunEffect(
					haptic,

3. Resize events and size change events are capable of conflicting each other if they happen within the same frame; it’s unlikely in the surface-level case (user resizes the window at the exact same time they hit “OK” in a video settings menu?!) but some very subtle cases like toggling SDL_WINDOW_FULLSCREEN_DESKTOP actually run into OS resize events that can conflict with a program’s size change events. Again, there’s a patch and it’s pretty small:

https://bugzilla.libsdl.org/show_bug.cgi?id=4227

Without that, you basically have to ignore OS resizes or risk having your viewport get screwed up. In FNA we have this check, which is also as nice as it looks:

github.com

FNA-XNA/FNA/blob/b5821ddad8afdfb36be9768f08a112aefee11579/src/FNAPlatform/SDL2_FNAPlatform.cs#L861


							SDL.SDL_EnableScreenSaver();
						}


						// Window Resize
						else if (evt.window.windowEvent == SDL.SDL_WindowEventID.SDL_WINDOWEVENT_SIZE_CHANGED)
						{
							// This is called on both API and WM resizes
							Mouse.INTERNAL_WindowWidth = evt.window.data1;
							Mouse.INTERNAL_WindowHeight = evt.window.data2;
						}
						else if (evt.window.windowEvent == SDL.SDL_WindowEventID.SDL_WINDOWEVENT_RESIZED)
						{
							/* This should be called on user resize only, NOT ApplyChanges!
							 * Sadly some window managers are idiots and fire events anyway.
							 * Also ignore any other "resizes" (alt-tab, fullscreen, etc.)
							 * -flibit
							 */
							if (GetWindowResizable(game.Window.Handle))
							{
								((FNAWindow) game.Window).INTERNAL_ClientSizeChanged();
							}

4. Android really likes stubbing functions instead of saying they’re not supported, so for debug contexts we sometimes run into scenarios where ARB_debug_output isn’t supported, and their debug printf gets interpreted as an error and the context creation fails instead of just rejecting the one flag. Maik patched this but it’s a Git patch, not a Hg patch, though it’s relatively small either way:

https://bugzilla.libsdl.org/show_bug.cgi?id=4220

Without this we’re basically screwed and have to either disable debugging on all Android builds or edit the FNA source every time we want to switch between debug and not debug, depending on the device in question. That said, this probably borders on “hack for a hack” so I dunno if there’s a better route for this.

Apologies for the super long post but I wanted to be sure these got looked at before the official tag. I’m subscribed to all of these bugs so we can use those for discussion to avoid getting sidetracked.

rtrussell · September 29, 2018, 5:01pm

Has 2.0.9 taken account of the several ‘The key you just pressed is not recognized by SDL’ reports posted here? I suspect that these reports don’t result in formal bugs being filed, and I wouldn’t want them to be forgotten.

David_Ludwig · September 29, 2018, 9:14pm

@vygr, I see a lot of docs up on ChrysaLisp’s Github site, but at a glance, I am unsure how to build and run it in a way, that demonstrates this bug.

Might you be able to either point to some specific steps that demonstrate building + running ChrysaLisp and reproducing this bug, or better, provide a short, concise, C or C++ app that demos this issue (using SDL 2.0.9)?

icculus · September 29, 2018, 10:42pm

If you move the window, does it start rendering?

8bitbubsy · September 30, 2018, 11:02am

Sad to see that WASAPI will most likely still be broken in 2.0.9, which is not good because it’s the default for SDL2 on Windows. It’s completely useless for some people because it can have random buffer problems when using the callback.

rtrussell · September 30, 2018, 12:04pm

I have never understood why WASAPI is the default. In my app I have:

#ifdef __WINDOWS__
	SDL_setenv("SDL_AUDIODRIVER", "directsound", 1);
#endif

Can I expect this to fail in any circumstances?

8bitbubsy · September 30, 2018, 12:20pm

It can fail if directsound is not available, though I can’t think of any scenario where it wouldn’t.
In my programs I scan through the available drivers (#ifdef _WIN32) to select directsound if it’s available, if not then I try winmm. If that fails too, I go for WASAPI after all (yuck).

EDIT: Checked my sources, I was a bit wrong, edited the post.

AntTheAlchemist · September 30, 2018, 12:57pm

Can anyone confirm it’s working on Android 4.2.2 (possibly all pre-Kitkat versions)? I’m getting a run-time error about missing libs. Trying to find more info before posting more…

vygr · September 30, 2018, 2:43pm

No, that was the first thing I tried

vygr · September 30, 2018, 2:57pm

Hi David, thanks for the interest.

A quick build and setup intro is in the doc/INTRO.md file, well worth a read.

However, if you have your SDL frameworks installed on MacOS you should be able to just clone the repo, go into the folder, and type ‘make’.

Now this will currently use a version of the High Sierra ‘main’ bootstrap and create a main-d which is the actual version you just compiled.

With the High Sierra version of main, running ./run.sh (launch the GUI) should work fine. If you look in the Makefile you will see the line where it creates ‘$@-d’, switch that back to say ‘$@’ and re-make with ‘make’ and relaunch with ./run.sh and you should see the non working GUI. This is assuming your building on Mojave.

Makefile line 16:
cc -o $@-d $@.o -F/Library/Frameworks -Wl,-framework,SDL2 -Wl,-framework,SDL2_ttf
Change back to:
cc -o $@ $@.o -F/Library/Frameworks -Wl,-framework,SDL2 -Wl,-framework,SDL2_ttf

I only get the none working situation with the compiled on Mojave, run on Mojave. Both versions work on High Sierra and the High Sierra version works fine on Mojave.

The place where the window gets setup and the renderer is created is in the file gui/gui/class.vp starting at line 98.

Regards

Chris