Orx - Portable Game Engine
Come and chat with us on Gitter! Print
Written by Wayne Johnson   
Friday, 04 September 2015 02:32

If you want to ask questions or chat about orx, or about projects you are working on, we can now be contacted via

We are closing down the IRC channel on freenode as a result. All chat will now happen over at Gitter. You're very welcome to come and join us.

Last Updated on Monday, 07 September 2015 23:44
New host and a new look Print
Written by Wayne Johnson   
Wednesday, 12 August 2015 14:19

The site has moved to a new host, and to go with it, we have a new coat of paint. Hope you like the new design!

Commands and TimeLine tutorials Print
Written by iarwain   
Monday, 10 November 2014 04:42

Hi all,


Sausage just added two very useful tutorials about commands and timeline. They can be found here:




Those complements nicely the information already available on the orx-dev group:

- Commands and TimeLines (basic)

- Using immediate commands in config files

- Discussion on future commands/timeline improvements



- iarwain

Last Updated on Monday, 10 November 2014 04:44
Happy New Year and 1.6 release Print
Written by iarwain   
Thursday, 15 January 2015 04:35

Hi all,


Everything is in the title: we wish you an excellent year 2015 and the belated v1.6 was finally released.

More info on the forum.



- iarwain


Last Updated on Thursday, 15 January 2015 04:36
Multi-threading/asynchronous resources Print
Written by iarwain   
Sunday, 10 August 2014 03:19

Hi all,

First, as you've noticed, the website never went down and there was no follow up from my host. So I guess so far, so good. ;)


Yesterday, I finally finished the iOS version of asynchronous resources handling (texture/sound) and merged the "thread" branch (which I have been using for over 10 months for my own projects now) into the "default" one.

That means a few things:

- orx now support asynchronous resource accesses.

You'll notice that saving a screenshot or loading textures and sounds won't block the main thread anymore, which used to result in the rendering being paused for a short duration. The immediate side effect is that there might be a slight delay when playing a sound for the first time or a white rectangle being displayed while a texture is getting loaded (though that temporary texture can be redefined at will if you'd rather have, say, a transparent temporary texture). In most cases you won't notice those, especially in release builds. However if that becomes an issue, one can easily pre-load assets with a simple loop and even render a progress bar as the engine execution won't be stopped while loading anymore. Config files are still load/saved asynchronously.

Lastly, if you were handling your own resources manually, you can either have synchronous calls or asynchronous ones by simply passing a callback to the read/write function: no callbacks -> synchronous, callbacks -> asynchronous.


- orx supports multithreading and exposes a unified API to create, pause, delete, enable, ... threads as well as semaphores for synchronization primitives. There's also a memory barrier macro available for those of you that would need it. Only a full blown read/write one has been added for now. There's no unified thread local storage support yet due to the annoying lack of standard around the __thread() keyword.


- profiler markers are correctly handled over multiple threads. And so is the profiler in-game display. By default, page up and page down allows one to display info about other threads.


- orx does have more than one thread running. Resources calls are all done in their own thread, same for sound streaming and lastly a generic purpose worker thread is available for tasks created with orxThread_RunTask(). I should probably add a tutorial on this function at some point as it has some interesting properties regarding sequencing (and helps removing the need for explicit synchronization primitives).


- most important of all: orx's API is *NOT* thread safe, for the most part. So if you were to use the aforementioned orxThread_RunTask(), make sure your tasks are not calling any orx functions. So far the only module that has a thread safe API if the orxThread one itself. orxProfiler is also mostly thread-safe. But that's about it. So please don't do any orxConfig_* calls in an asynchronous task. I'll add thread safety later on when I've settled on a good performance/safety compromise.


In addition to all this, another important news about the "default" branch is that the MinGW32 version now uses gcc 4.8.1: I've retired the good ol' gcc 4.6.2.


I should be releasing orx 1.6 officially shortly, unless any big issue is uncovered. Don't hesitate if you have any questions! :)



- iarwain


Last Updated on Sunday, 10 August 2014 03:20

Page 1 of 15