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.

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.

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:


--
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

_______________________________________________
SDL mailing list

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

2012/3/19 Forest Hale


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.

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:
_______________________________________________
SDL mailing list

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


Good luck!

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

2012/3/19 Jeremy Jurksztowicz


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.

On Mon, Mar 19, 2012 at 7:03 AM, gabomdq wrote:


Not interested.


 

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:

On Monday 19 March 2012, at 13.03.25, "gabomdq" wrote:

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.


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

.--- Games, examples, libraries, scripting, sound, music, graphics ---.
| http://consulting.olofson.net http://olofsonarcade.com |
'---------------------------------------------------------------------'
_______________________________________________
SDL mailing list

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