Does anyone here have an idea about how Orx would get along with Emscripten
? Seems like Emscripten has built-in support for GLFW and OpenGL (they claim it converts OpenGL calls to WebGL calls). So it seems like a theoretically possible target platform for Orx.
Of course, Emscripten might have to convert all of orx's dependencies... maybe? I don't know.
Most of it looks rather straightforward, however there are a couple questions left for me:
- I was thinking of only supporting its virtual file system (with preloaded package) along with their wrappers for the LibC functions. But in this case, it doesn't support writing. How would we handle this?
- No multi-threading with shared memory support, that means that I should probably add a no-threading mode that would work without having to change any caller code. Or should I look into the web tasks (but that sounds rather complicated due to their no memory-sharing restriction)?
Do you have any experience with Emscripten? If so, would you like help adding support for it? We could start an emscripten branch for this and work with pull requests. If anyone else would like to contribute, they're welcome to do so.
It's not currently high on my priority list, but if some of you would like to work on this, I'll be happy to help if I can, no matter how soon it is.
Based on this link, I have the impression that it does support write access and persistence. Am I missing something?
iarwain wrote: Where exactly do we need/have concurrency in Orx? Could you provide a few pointers so that I can study the current state?
As I've mentioned at the beginning, I'm far from being experienced in emscripten, but I've really been looking forward to getting seriously into it. I'd be glad to do my best. That said, I'd first like to bring the animation editor to a less transient state. After that, I can start looking into emscripten.
Threads are used in orx for all the asynchronous resource handling, music streaming and any user code that either use orxThread_Start() or orxThread_RunTask(). The latest uses an internal thread where worker tasks are dispatched (some parts of orx uses this as well, such as async file writes).
In a first time, I'd need to provide a way to work mono-threaded without having to change any client code. Shouldn't be too bad, I just need to be careful about not breaking any sequential ordering as orx isn't using any mutexes but lighter weight semaphores + carefully planned memory accesses, for performances.
Article dated Nov 2014.
I think this could be a nice starting point. Maybe, we could first try to get the orxConfig module to work.
I see, I think going from multi-threaded to single-threaded should be much easier than the other way round. IMHO, the only problem could be a set of threads acting like coroutines, so that they wait for each other back-and-forth at different points. This would require the availability of multiple stacks. Except for the user code calling orxThread_Start, the obstacles you've mentioned don't sound like they would require coroutines. They sound more like subroutines that need to be stored in a task queue that gets handled at the end of the game loop. I'm sure the effort would be quite big, but hopefully it wouldn't require any architectural changes.
Anyway, I don't want to sound like I underestimate the task.
sausage wrote: Wow, that's a really nice catch!