Native Client backend for SDL2

Hi list! I’ve made an experimental backend that allows SDL2 apps to work
under NaCl, using the OpenGL ES2 renderer. It’s based on the SDL 1.2 NaCl
port and parts of the SDK code,plus a lot of tears and blood courtesy of
the almost non existent debug support!

Anyway, currently the biggest problem with the port is that it is slow,
VERY slow. This is because NaCl is in essence an event driven single
threaded system similar to javascript.
So, to adapt SDL apps with an endless main loop what the port does is run
it in a thread. This does not seem so bad in principle, however, there’s a
key NaCl limitation: all Pepper API and OpenGL ES2 calls need to happen on
the main thread.
I’ve worked around this limitation by adding wrappers on the SDL_Renderer
functions, which then call the actual functions on the main thread and
block the worker thread until the function is executed, a mechanism that is
fairly transparent to the end user…but as I said, the end result is a
slow app, because the RPC system used for this is inherently slow.

I’ll be happy to hear who else is interested in this backend, ideas on how
to improve speed (I can’t think of nothing else but wait for Google to
allow Open GL calls from threads, or refactor apps with a different main
loop), etc.

I was going to make a patch and submit it to the tracker as agreed with
Sam, however I’ll just point you to my experimental repo instead
https://bitbucket.org/gabomdq/sdl-1.3-experimental/changesets
For a working patch that applies on the official repo I would need to
remove the RenderCopyEx changes, so that will need a bit of work on my
side, work that I would rather not do if there’s not too much traction in
the community on this subject.

I’ll close with an extract of the README file I’ve added at test/nacl

  • Requires Pepper 18 or higher

Edit prepare_nacl_env and set the NACL_SDK and optionally the PREFIX32/64
paths
Run buildsdl, this will build SDL for the two versions (x86 32 and 64 bits)
Run buildtest, this will create a basic test based on testspriteminimal.c
Run httpd.py to start the web server
Run runchrome to view the example in Chrome.

Notes:

  • The NaCL backend uses the OpenGL ES2 renderer
  • Because all PPAPI and GLES2 calls need to happen on the main thread, SDL
    apps will behave slowly…(for now!)
  • You can alternatively modify your app to run entirely in the main thread,
    thus gaining a speed bump,
    the problem with doing this is that you have to retool the main loop to
    behave in an event driven fashion
  • Fully static linking with the glibc toolchain does not work
  • In this example, SDL is statically linked against the example, the NaCl
    libraries are dynamically loaded.
  • Debug facilities in NaCl are severly lacking, some output is available at
    /tmp/nacl*

TODO:

  • Sound
  • RWops
  • etc,etc–
    Gabriel.

gabomdq wrote:

Hi list! I’ve made an experimental backend that allows SDL2 apps to work under NaCl, using the OpenGL ES2 renderer. It’s based on the SDL 1.2 NaCl port and parts of the SDK code,plus a lot of tears and blood courtesy of the almost non existent debug support!

It seems no one else is interested in this? Should I let it go? I find it strange as there seemed to be some interest back in August when this was discussed in the list.

Gabriel.

I’m very interested in it but lack the time to do anything to help. :(On 03/19/2012 05:03 AM, gabomdq wrote:

gabomdq wrote:

Hi list! I’ve made an experimental backend that allows SDL2 apps to work under NaCl, using the OpenGL ES2 renderer. It’s based on the SDL 1.2 NaCl port and parts of the SDK code,plus a lot of tears
and blood courtesy of the almost non existent debug support!

It seems no one else is interested in this? Should I let it go? I find it strange as there seemed to be some interest back in August when this was discussed in the list.

Gabriel.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

2012/3/19 Forest Hale

I’m very interested in it but lack the time to do anything to help. :frowning:

That’s ok, the thing is that the chance this has of getting accepted on the
official repo and getting maintained and bug fixed, etc is proportional to
the amount of people interested in it.> On 03/19/2012 05:03 AM, gabomdq wrote:


Gabriel.

I am also interested in that.And it would be nice in having it
integrated to the main SDL repo.But first it has to run ok.On Mon, Mar 19, 2012 at 2:12 PM, Gabriel Jacobo wrote:

2012/3/19 Forest Hale

I’m very interested in it but lack the time to do anything to help. :frowning:

On 03/19/2012 05:03 AM, gabomdq wrote:

That’s ok, the thing is that the chance this has of getting accepted on the
official repo and getting maintained and bug fixed, etc is proportional to
the amount of people interested in it.


Gabriel.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I like the idea too. SDL in the browser without plugins would be a very
attractive platform for web and game development. However, only Chrome
does it without a plugin and I don’t know how well-supported the plugins
are for the other browsers.

Jonny D

Color me interested, but of course like many others, my plate is quite full.

Just curious, perhaps it’s ignorant of me, but wouldn’t it be a tad faster
to queue all render calls and then execute them once at frame refresh? That
way you could avoid blocking the caller, and the order would be preserved.
Just a thought.

I’d say that I’ll take a look at the code, but I might not have time :slight_smile:

Good luck!On Mon, Mar 19, 2012 at 10:01 AM, Jonathan Dearborn wrote:

I like the idea too. SDL in the browser without plugins would be a very
attractive platform for web and game development. However, only Chrome
does it without a plugin and I don’t know how well-supported the plugins
are for the other browsers.

Jonny D


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

2012/3/19 Jeremy Jurksztowicz

Color me interested, but of course like many others, my plate is quite
full.

Just curious, perhaps it’s ignorant of me, but wouldn’t it be a tad faster
to queue all render calls and then execute them once at frame refresh? That
way you could avoid blocking the caller, and the order would be preserved.
Just a thought.

I’d say that I’ll take a look at the code, but I might not have time :slight_smile:

Good luck!

A render queue could certainly work with some exceptions for the case where
the user wants to read information from textures (in which case you’d need
to flush the queue and block the worker thread until the flushing is
finished), and I would hope it would be noticeably faster. However, we
would be breaking a basic premise of SDL, that of synchronous
execution…what possible downsides are to that?–
Gabriel.

**

gabomdq wrote:

Hi list! I’ve made an experimental backend that allows SDL2 apps to work
under NaCl, using the OpenGL ES2 renderer. It’s based on the SDL 1.2 NaCl
port and parts of the SDK code,plus a lot of tears and blood courtesy of
the almost non existent debug support!

It seems no one else is interested in this? Should I let it go? I find it
strange as there seemed to be some interest back in August when this was
discussed in the list.

Not interested. :|On Mon, Mar 19, 2012 at 7:03 AM, gabomdq wrote:

Gabriel.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Good point, but I suspect that for most applications drawing would be far
more common than accessing textures. Somehow I also suspect that
shoehorning the classic desktop model on such a different one will require
some compromises. I doubt that straight portability is going to be possible
in the short run.

Thanks for the effort, I’ll be checking out the code when I’ve got a free
evening, and who knows, there’s a slight chance I’ll get hooked!On Mon, Mar 19, 2012 at 11:18 AM, Gabriel Jacobo wrote:

2012/3/19 Jeremy Jurksztowicz <@Jeremy_Jurksztowicz>

Color me interested, but of course like many others, my plate is quite
full.

Just curious, perhaps it’s ignorant of me, but wouldn’t it be a tad
faster to queue all render calls and then execute them once at frame
refresh? That way you could avoid blocking the caller, and the order would
be preserved. Just a thought.

I’d say that I’ll take a look at the code, but I might not have time :slight_smile:

Good luck!

A render queue could certainly work with some exceptions for the case
where the user wants to read information from textures (in which case you’d
need to flush the queue and block the worker thread until the flushing is
finished), and I would hope it would be noticeably faster. However, we
would be breaking a basic premise of SDL, that of synchronous
execution…what possible downsides are to that?


Gabriel.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Well, like many others, I’m having a hard time keeping up already, and even
though I’m actually planning on porting Kobo II to NaCl, the timing is not
right; I need to focus on content and gameplay, while doing contract work to
make ends meet.

Also, I’m still using SDL 1.2 - and I’m doing all rendering with OpenGL 1.4 in
a single window anyway. Planning on porting to OpenGL ES 2.0, but still not
entirely certain that this is a viable option on all platforms, and I don’t
want to maintain multiple backends if I don’t have to. (Was thinking I might
have to add one for Direct3D, but haven’t had a single request for that so
far, actually…)

Anyway, in my case, event based vs “main loop” etc is no big deal. My
scripting engine could trivially be made to run the entire app coroutine style
if desired; for example, wire gl.SwapBuffers() to halt the VM and return to
the native side; next suitable NaCl event goes back in for another frame, etc.
Or, I switch my game executive from the current main() entry point to an event
based model. Either way is fine by me.

As to the actual API, I’m mostly interested in the SDL events, SDL software
surfaces (for preparing textures), and all the “little details” like that. My
beef is really with OpenGL, which I’ll have to use directly anyway; that is,
porting from 1.4 to ES 2.0.

So in short, it would be nice and handy if I could at least reuse some parts
of my SDL binding for the NaCl port, but 100% compatibility is not needed, as
it (the language binding) is not really that much code to mess with anyway.On Monday 19 March 2012, at 13.03.25, “gabomdq” wrote:

gabomdq wrote:

Hi list! I’ve made an experimental backend that allows SDL2 apps to work
under NaCl, using the OpenGL ES2 renderer. It’s based on the SDL 1.2
NaCl port and parts of the SDK code,plus a lot of tears and blood
courtesy of the almost non existent debug support!

It seems no one else is interested in this? Should I let it go? I find it
strange as there seemed to be some interest back in August when this was
discussed in the list.


//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
’---------------------------------------------------------------------’