Orx and Emscripten

edited January 2015 in General discussions
Hi Everyone,

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.

Imagine running your Orx game inside a web page! Being a very efficient C library, Orx might actually become a very nice web game framework, even more efficient than native javascript frameworks.

Comments

  • edited January 2015
    That would open exciting possibilities to be able to run orx projects and applications in a modern browser.

    Of course, Emscripten might have to convert all of orx's dependencies... maybe? I don't know.
  • edited January 2015
    Sure, everything needs to be compiled to javascript, but that's not a big problem as long as the dependencies themselves don't do anything coupled to the platform. Given that orx runs on a variety of platforms, I'd expect most of its dependencies to be largely platform independent (except for GLFW, which emscripten has built-in support for).
  • edited January 2015
    Interesting timing you have there: even if added added a task for this in orx's issue list quite a while ago, it was only two nights ago that I started reading about all the constraints and requirements. :)

    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.
  • edited January 2015
    Just been reading through catching up on LLVM and Emscripten. There is an impressive list of engines that have been ported already, like Unity, Torque 2D, etc.
  • edited January 2015
    First of all, my only experience with Emscripten is having tried a few examples with it and being amazed at how they just worked. I've also read a bit about what people have been doing with it and how.

    iarwain wrote:
    Interesting timing you have there: even if added added a task for this in orx's issue list quite a while ago, it was only two nights ago that I started reading about all the constraints and requirements. :)

    Nice coincidence :)

    iarwain wrote:
    - 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?

    Based on this link, I have the impression that it does support write access and persistence. Am I missing something?

    iarwain wrote:
    - 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)?
    Where exactly do we need/have concurrency in Orx? Could you provide a few pointers so that I can study the current state?

    iarwain wrote:
    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.

    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.
  • edited January 2015
    From what I read in different places of the official doc, to get persistence you need to mount an IDBFS folder into the virtual file system. I'm just not entirely clear how the path system works in that case and if there's any way to query files that already exist on the hard drive.

    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.
  • edited January 2015
    I assume that Emscripten's IDBFS will be using browser LocalStorage. Anything saved here stays within the browser because javascript is sandboxed.
  • edited January 2015
    Alternative games have an excellent overview of how to tackle the Emscripten porting process as their frontpage feature here:

    http://www.alternativegames.net/

    Article dated Nov 2014.
  • edited January 2015
    Nice find, thanks! :D
  • edited January 2015
    iarwain wrote:
    From what I read in different places of the official doc, to get persistence you need to mount an IDBFS folder into the virtual file system. I'm just not entirely clear how the path system works in that case and if there's any way to query files that already exist on the hard drive.

    I think this could be a nice starting point. Maybe, we could first try to get the orxConfig module to work.

    iarwain wrote:
    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.

    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:
    Alternative games have an excellent overview of how to tackle the Emscripten porting process as their frontpage feature here:
    Wow, that's a really nice catch!
  • edited February 2015
    Has there been any more research on this?
  • edited February 2015
    Not yet on my side, sorry!
  • edited February 2015
    Nothing here yet also, left to myself, I'll probably find the time to seriously look into this in a few months' time.
Sign In or Register to comment.