The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

Presenting the 2.0.4 RELEASE CANDIDATE 1
http://www.libsdl.org/tmp/download-2.0.php

We plan to release this soon, so please try it out and report any issues with your applications:
http://bugzilla.libsdl.org/

Here are the major changes in this release:

General:

* Added support for web applications using Emscripten, see docs/README-emscripten.md for more information

* Added support for web applications using Native Client (NaCl), see docs/README-nacl.md for more information

* Added an API to queue audio instead of using the audio callback:

    SDL_QueueAudio(), SDL_GetQueuedAudioSize(), SDL_ClearQueuedAudio()

* Added events for audio device hot plug support:

    SDL_AUDIODEVICEADDED, SDL_AUDIODEVICEREMOVED

* Added SDL_PointInRect()

* 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

* You can distinguish between real mouse and touch events by looking for SDL_TOUCH_MOUSEID in the mouse event "which" field

* 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

* Improved support for WAV and BMP files with unusual chunks in them


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

* SDL_SysWMinfo now contains the window HDC

* Added support for Unicode command line options

* Prevent beeping when Alt-key combos are pressed


Mac OS X:

* Implemented drag-and-drop support

* Improved joystick hot-plug detection

* Fixed relative mouse mode when the application loses/regains focus

* 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


Android:

* Added a hint SDL_HINT_ANDROID_SEPARATE_MOUSE_AND_TOUCH to prevent mouse events from being registered as touch events


Raspberry Pi:

* Added support for the Raspberry Pi 2

Hi.

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.

Regards
Martin

Am 13.06.2015 um 22:32 schrieb Sam Lantinga:

So still no news about CMake scripts in SDL2? It is a pity compiling on windows with cmake generates 5/6 MB binary while the official binary is much smaller, also Emscripten "binaries" are corrupted if not all libraries are built with same optimization flags (so basically, where do I check wich optimization does SDL use? XD ), the flags used during compilation of SDL should be in a separed script so that users could adjust them to make SDL2 build with same optimization flags of their projects (for a web build it needs to be tested if a project gets benefits from being built with Os or O2 or something different because in Javascript code size sometimes impact performance).

I tried to put my hands in build scripts but it's a mess.. If I don't rembmer correctly I'm not the only asking for that (and that's not my first post). Also why maintain dozen of different build systems? Cmake should be the official one (could also generate Visual studio solution) and visual studio solution should be provided just as "commodity".

SDL2.0.4 actually don't compile on Windows with CMake (SDL2.0.3 compiled "fine"): (tested with GCC from 4.6 to 4.9 and emscripten)

The script I used to compile:


In particular in my CMake:


No longer works (the directories are correct, infact the script is found and runned, but it fails.. the output of the error log is 200KB I don't think you want to dig into that.

I don't see a fix for SDL_GL_CreateContext when a window is created from an outside ID.
Is it possible to know when it will be fixed ?
Thanks

That requires a new API, and we plan to add that for 2.0.5.

Cheers!


On Mon, Jun 15, 2015 at 6:05 PM, Alundra wrote:

Does this RC intentionally omit the docs directory mentioned in INSTALL.txt and README.txt? Maybe your packaging script wasn't updated to include docs/*?

Is it possible to know when an OpenGL ES 3 (and 3.1) header will be there ?
Thanks

Congratulations! I looked at the bugs and asked for your patches, so I get the changes right.

Cheers!


On Tue, Jun 16, 2015 at 3:21 AM, Sylvain Becker wrote:

I put on hold ES3 support work back when 2.0.4 release was "imminent"...a year ago :)

Now that it's finally going to come out, I'll get started on it again.


2015-06-16 23:16 GMT-03:00 Alundra:




--
Gabriel.

Well, SDL does support OpenGL ES 3.0 and 3.1 now (including when EGL is used for context creation) – although the OpenGL ES 3.x function and enum declarations aren't included with any SDL_opengles* file at the moment.

To test whether OpenGL ES 3.0 functions and enums have been #included, you can check for the GL_ES_VERSION_3_0 and GL_ES_VERSION_3_1 defines, e.g.:

#ifdef GL_ES_VERSION_3_1
// …
#endif

Hey Sam,

How comprehensive is this changelist?  I'm diffing my way through 2.0.4 and seeing a bunch of Android changes that seem to allow RWops to read from expansion APK files.  I haven't tested it yet, but removing a 50MB filesystem limit is a major upgrade!


Also, didn't we apply a bunch of Alex's changes to iOS?  Or is that "support for iOS8" in a nutshell?


I think there might be more major things in here than you're giving the release credit for. :)


I hope to spend time this weekend heavily testing it; linking it to multiple shipping codebases on nearly all supported platforms and running it through Valgrind on my test servers.


Michael Labbé

On Sat, Jun 13, 2015 at 1:32 PM, Sam Lantinga wrote:

The changelog doesn’t seem to go into too much detail in some areas – all of my iOS changes (and more) were indeed merged into the repository.

I could update the iOS section of the changelog file in the repository to be a bit more comprehensive, if Sam’s ok with that?


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I noticed the docs subdir is missing from the archive.  On hg, docs/ contains all of the readme.mds, but all of the second tier readmes are not there.

On Sat, Jun 13, 2015 at 1:32 PM, Sam Lantinga wrote:

Feel free to call out things that you think should be in the patch notes. Single line summary format would be great.

Thanks!


On Wed, Jun 17, 2015 at 12:53 PM, Michael Labbe wrote:

Yes, go for it!

On Wed, Jun 17, 2015 at 12:57 PM, Alex Szpakowski wrote:

I did a very quick spot check today (e4f04633f291) on OS X, iOS, and
Android. Things seem to be okay for me. I am using the SDL 2D
renderer.

I also got to try a Raspberry Pi (2) for the very first time today. I
was very happy with how well SDL worked. Some minor nitpicks
though...I don't think these are show stoppers.

- Windowed mode doesn't seem to work (I'm running in the default X on
Raspbian). It always kicks into to fullscreen for me.

- If I manually toggle to windowed mode, the view shrinks, but the
rest of the screen is black, instead of showing my desktop.

- When I quit my program, I noticed all my keyboard input I entered
while playing my game appears in the window terminal that I used to
launch the game. (This does not happen when in non-X mode.)

- I've tried several ways of video recording the screen (all failed).
It feels like SDL is rendering to a different area that screen
grabbing software and VNC clients can't see.



I will probably give x64 Linux desktop and Windows a quick test tomorrow.

Thanks,
Eric
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I made the iOS list a bit more detailed (and added a couple missing things to the OS X list) – I still didn’t list every single little change for iOS though, since there are so many and the changelog hasn’t listed every small change in the past either.

Is it possible to know what is the include needed to use OpenGL ES 3 ?
I looked in 2.0.4 headers and didn't found where the OpenGL ES 3 is included.
I looked on khronos site : https://www.khronos.org/registry/gles/#headers31
The result is : <GLES3/gl31.h>, <GLES2/gl2ext.h> and <GLES3/gl3platform.h>
For IPHONEOS it's the same change as GLES2 ?
If it's the same, the result is : <OpenGLES/ES3/gl31.h> and gl3platform.h not used.
About the context once these included, has to be set like that if i'm correct :
SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_ES);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 3);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 1);
Thanks

I assume we're favoring a virtual terminal over X11 on the RPi, but I'd
have to check to be sure. These sound like symptoms of that.

--ryan.



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On 06/17/2015 03:57 PM, Alex Szpakowski wrote:

Well, it was like 100+ changesets, and "iOS support sucks about a
thousand times less now" didn't seem like an appropriate summary. :P

--ryan.


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Anyone who worked on, used or merged the Android Expansion APK want to take a crack at this?
I only read the source and inferred the functionality, so I’m wary of misrepresenting the change in a shipping changelog.
Michael Labbé

Yep, support for the RPi is for terminal apps and it uses direct access to the VideoCore hardware.

I never tested it, but X11 should work under the general umbrella of Linux+X11 support we have, provided the correct video backend is selected.





2015-06-18 15:57 GMT-03:00 Ryan C. Gordon:




--
Gabriel.

Gabriel, should we favor X11 on the Pi if an X server is available? Not sure what the trade offs are here, but it seems like it would cause less confusion.


--ryan.



On Jun 18, 2015, at 3:18 PM, Gabriel Jacobo wrote:

Does X11/GLX on the Pi support hardware-accelerated OpenGL ES contexts?

On Jun 18, 2015, at 10:17 PM, Ryan C. Gordon wrote:

On 6/18/15, Alex Szpakowski wrote:

I actually don't know the answer for sure, but Raspbian ships with
Minecraft Pi included and has a preset menu option in the default X
desktop. It runs in a window. (Though it is a little weird and runs in
a borderless window. I couldn't figure out if the bordless was by
intent or a bug because it became tricky to quit the game.) But I'm
inferring this means it is OpenGL ES accelerated in the X server.



I think that would reasonable. (Perhaps an SDL hint could be used to
specify the direct renderer if they really need to override it?)

Being able to run in a window is useful for debugging.

Also, I sometimes trigger unfortunate behavior where my first usable
keystrokes are 'up arrow' and 'return'. When I quit my game, the
terminal then goes up to the last command in the history and runs it
causing my game to relaunch.

I'm also realizing if the game has password fields, it would be bad
form to see them in clear text on your terminal when you quit the
game.

And if there is a way to get screenshots, video recording, or VNC,
this is really useful for creating marketing material.


Thanks,
Eric
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

From what I’ve heard, Minecraft on the Pi does some hacky stuff (using the videocore API combined with X11 in some manner) in order to get hardware-accelerated GLES while still being in a window. I don’t think just using SDL’s X11/GLX backend out of the box on the RPi will be a good idea if people expect hardware accelerated GLES – but I could be wrong.


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I didn't notice audio input being listed in the announcement. Is that
set for post 2.0.4?
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On 6/19/15 1:38 AM, Jared Maddox wrote:

This is not in 2.0.4.

--ryan.



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On 6/18/15, Alex Szpakowski wrote:



I actually believed you and had not planned on testing this, but I
accidentally hit this code path and confirmed the X11 backend won't
work.

I was trying to build Qt on Pi for a different task. Two attempted 14
hour build times and a forced SD card upgrade later, I discovered that
Qt Quick won't work because it uses OpenGL to render everything now
and it can't intermix non-fullscreen widgets or something and
basically calls exit(). (If I needed fullscreen stuff, I would just
use SDL, and that only takes under 5 minutes to build and won't eat up
my entire SD card.)

Any way, to build Qt, I had to install multiple dozens of
dependencies. So next time I built SDL, it's configure script picked
up these things and I believe it built the X11 backend.

When I ran SDL, I would briefly see some windows get created and
immediately close. Then I would see errors on my console that a
renderer could not be created. It did not fallback to the direct
fullscreen display one for some reason.


Anyway, I recommend two things be added to the instructions:

First, there is no mention of building SDL on the Pi itself, just
cross-compiling instructions.
It is actually pretty easy, just run ./configure (with switches) and make.

On a default installation, things will work.

But if you installed extra crap like I did to build some other library
like Qt (I hate doing that because it is hard to know what to
uninstall later), then it is required to force disable X11. (I think
xcb is the relevant component that triggered this.) So I think the
instructions should look like:

./configure --disable-pulseaudio --disable-esd --disable-video-x11

I'm actually using the following, due to remnants from David Gow's
Linux build guide I based things from. But I think the remaining
switches are unnecessary.
./configure --disable-pulseaudio --disable-esd --disable-video-x11
--disable-rpath --enable-sdl-dlopen


Thanks,
Eric
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org