SDL 2.0.9 prerelease

Getting a lockup when app loses focus for 5+ seconds on Windows 10 when using SDL_INIT_JOYSTICK. Only happens when running the .exe from file manager. Reported the bug here:

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

Not yet. I plan to do a pass and go through all of these, but not for 2.0.9.

Thanks for taking the time to write this up. I went through and reviewed the patches and accepted them all for 2.0.9.

Do you have specific bugs that aren’t already reported?

I went ahead and commented on the two WASAPI bugs in bugzilla:
https://bugzilla.libsdl.org/show_bug.cgi?id=4171
https://bugzilla.libsdl.org/show_bug.cgi?id=4066

No I don’t, but the issue is that I’m getting some buffering problems (most likely underrun) in some rare occasions when using the callback. This is not acceptable, since I’m developing a music program.
On some machines it happens way more often. Increasing the buffer size doesn’t decrease the cracks/pops at all, which is very strange! Since I read that other people had glitchy problems with WASAPI on SDL2 as well, I concluded that it’s an SDL2 problem and not my code (which has no issues when using directsound, by the way).

Some bugzilla entries that might be of interest for 2.0.9, some
of which have proposed patches:
https://bugzilla.libsdl.org/show_bug.cgi?id=2954
https://bugzilla.libsdl.org/show_bug.cgi?id=3589
https://bugzilla.libsdl.org/show_bug.cgi?id=4066
https://bugzilla.libsdl.org/show_bug.cgi?id=4171
https://bugzilla.libsdl.org/show_bug.cgi?id=4231
https://bugzilla.libsdl.org/show_bug.cgi?id=4236
https://bugzilla.libsdl.org/show_bug.cgi?id=4238
https://bugzilla.libsdl.org/show_bug.cgi?id=4241
https://bugzilla.libsdl.org/show_bug.cgi?id=4242
https://bugzilla.libsdl.org/show_bug.cgi?id=4244
https://bugzilla.libsdl.org/show_bug.cgi?id=4246
https://bugzilla.libsdl.org/show_bug.cgi?id=4255

And some very recently reported ones, some of which may already
be under investigation:
https://bugzilla.libsdl.org/show_bug.cgi?id=4272
https://bugzilla.libsdl.org/show_bug.cgi?id=4278
https://bugzilla.libsdl.org/show_bug.cgi?id=4284
https://bugzilla.libsdl.org/show_bug.cgi?id=4285
https://bugzilla.libsdl.org/show_bug.cgi?id=4286
https://bugzilla.libsdl.org/show_bug.cgi?id=4287

1 Like

Great. I’ve updated my Go language bindings at

Could you please add them to the list of Go bindings on the page

https://www.libsdl.org/languages.php

MSB

Changeset 12286 seems to have broken compiling on the Raspberry Pi. Eariler changesets compile fine.

> /usr/src/SDL-75abb8e13a91/src/render/software/SDL_render_sw.c: In function ‘SW_CreateRendererForSurface’:
> /usr/src/SDL-75abb8e13a91/src/render/software/SDL_render_sw.c:154:13: error: ‘SDL_Renderer {aka struct SDL_Renderer}’ has no member named ‘SetTextureColorMod’
>      renderer->SetTextureColorMod = SW_SetTextureColorMod;
>              ^~
> /usr/src/SDL-75abb8e13a91/src/render/software/SDL_render_sw.c:155:13: error: ‘SDL_Renderer {aka struct SDL_Renderer}’ has no member named ‘SetTextureAlphaMod’
>      renderer->SetTextureAlphaMod = SW_SetTextureAlphaMod;
>              ^~
> /usr/src/SDL-75abb8e13a91/src/render/software/SDL_render_sw.c:156:13: error: ‘SDL_Renderer {aka struct SDL_Renderer}’ has no member named ‘SetTextureBlendMode’; did you mean ‘SupportsBlendMode’?
>      renderer->SetTextureBlendMode = SW_SetTextureBlendMode;
>              ^~
> /usr/src/SDL-75abb8e13a91/src/render/software/SDL_render_sw.c:161:13: error: ‘SDL_Renderer {aka struct SDL_Renderer}’ has no member named ‘UpdateViewport’; did you mean ‘UpdateTexture’?
>      renderer->UpdateViewport = SW_UpdateViewport;
>              ^~

Thank you!

Anyone else noticed that vsync doesn’t work with SDL2.0.8 on macOS Mojave? Is it because of lack of OpenGL, and can it be fixed?

Hi @slouken!

I’m very happy to see a dedicated sensor API that I needed for my future games. I’m in hurry to test.

However I’m always wondering why SDL only bump the patch version when adding new features like that. The minor version should be updated instead. For example SDL 2.1.

Cheers!

1 Like

the minor version is not bumped as long as the API and ABI isn’t broken (changed in in a backwards-incompatible way)

We usually bump minor version when API changed are made in backward compatible way (e.g. new features). And patch versions mostly refer to bugfixes. ABI breakage is another stuff that is handled at shared library level (using SONAME) and not at the version at all. This is the most common versioning system.

This was off on a branch, which happened to be the “tip” revision if you pulled at the wrong time.

(but that branch should now work on the Raspberry Pi again, too.)

–ryan.

Excellent, thank you for looking into this.

I take the view that if only the ‘patch’ figure is stepped there ought to be a very high likelihood that an application requires no code changes in order to work with the new version of SDL2. But that’s not the case in 2.0.9: for example according to the prerelease announcement the default behavior of the Android ‘back’ button has been changed, necessitating the addition of a hint to restore the previous behavior. It has been true of earlier releases too, such as when the default Windows audio driver was changed to WASAPI. They deserve a change to the ‘minor version’, in my opinion.

The default behavior of the Android back button hasn’t changed - you can just now specify a hint to get the back button as a key press event.

The WASAPI change was intended to be transparent, and any case where that isn’t true is a bug.

I get the back button as an SDL_KEYDOWN event now, using SDL 2.0.5, (ev.key.keysym.sym = SDLK_AC_BACK as documented here) so I’m confused about what the new hint actually changes.

The iOS Demo xcode project Demos.xcodeproj is missing the information to link against the CoreBluetooth.Framework.
Same probably in the Template example project file.

Also Xcode 10 complains about “Traditional headermap style is no longer supported; please migrate to using separate headermaps and set ‘ALWAYS_SEARCH_USER_PATHS’ to NO.”
If you set this to no, it compiles fine.

made two patches at https://bugzilla.libsdl.org/show_bug.cgi?id=4324