Well, it was like 100+ changesets, and “iOS support sucks about a
thousand times less now” didn’t seem like an appropriate summary. 
–ryan.On 06/17/2015 03:57 PM, Alex Szpakowski wrote:
The changelog doesn?t seem to go into too much detail in some areas
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?> On Jun 17, 2015, at 11:20 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 <@Michael_Labbe mailto:Michael_Labbe> wrote:
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 <slouken at libsdl.org <mailto:slouken at libsdl.org>> wrote:
Presenting the 2.0.4 RELEASE CANDIDATE 1
http://www.libsdl.org/tmp/download-2.0.php http://www.libsdl.org/tmp/download-2.0.phpWe plan to release this soon, so please try it out and report any issues with your applications:
http://bugzilla.libsdl.org/ 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
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
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 :> > 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.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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
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:
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 <@icculus>:
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.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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org–
Gabriel.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Does X11/GLX on the Pi support hardware-accelerated OpenGL ES contexts?> On Jun 18, 2015, at 10:17 PM, Ryan C. Gordon wrote:
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:
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 :
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.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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org–
Gabriel.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Does X11/GLX on the Pi support hardware-accelerated OpenGL ES contexts?
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.On 6/18/15, Alex Szpakowski wrote:
On Jun 18, 2015, at 10:17 PM, Ryan C. Gordon wrote:
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.
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
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.
Does X11/GLX on the Pi support hardware-accelerated OpenGL ES contexts?
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.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.
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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org> On Jun 18, 2015, at 11:27 PM, Eric Wing wrote:
On 6/18/15, Alex Szpakowski <@Alex_Szpakowski> wrote:On Jun 18, 2015, at 10:17 PM, Ryan C. Gordon wrote:
I didn’t notice audio input being listed in the announcement. Is that
set for post 2.0.4?
This is not in 2.0.4.
–ryan.On 6/19/15 1:38 AM, Jared Maddox wrote:
I didn’t notice audio input being listed in the announcement. Is that
set for post 2.0.4?
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,
EricOn 6/18/15, Alex Szpakowski wrote:
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.
