ORX vs Allegro

edited January 2015 in Help request
Any guys on here come from Allegro to ORX? I've used Allegro in the past and got on well with it, but that was some time ago. I'm not keen on the mobile platforms using it though, hence my looking at ORX in earnest now.

Any one done a similar thing, maybe care to share their experiences?




  • edited January 2015
    It's not probably going to help much, but I used to be an Allegro user in the 90s. :)
    I used it for quite a few years before switching to SDL (which had hardware-accelerated support long before Allegro did) and finally started working on my own solution back in 2001, which turned into orx in 2002 (back then, I had plugins both based on Allegro and SDL, then I retired them over the years in favour to something that was more adapted to my needs and had better performances: GLFW).

    The main difference between Allegro and Orx are that one is a library exposing systems whereas the other one is an engine. With a library you often need to handle many things yourself in code, even down to your game loop or render loop (I don't know if Allegro has evolved pas that point, I haven't checked it in years), whereas in an engine, the whole loops are already there and you basically supply it with data to process (with extra code for logic and driving it, obviously).
    A library can be considered lower level than a game engine, and most game engine use those game libraries as foundations in one way or the other.

    A more concrete difference, with a simple example: drawing a character on screen.

    With Allegro (again, there might be more available now, but that's how it used to be), you only have a bitmap/sprite feature. You'll need to find the right bitmap to use based on the current animation (that you would handle yourself), load the bitmap yourself, do the bookkeeping, compute the physics yourself, query the input at the peripheral level, issue the draw calls yourself, etc.

    With orx, you need to write data that describes an object that can use components such as graphic, sound, animation, physics, etc.
    But in the end the object will be created with a single line of code (or sometime less, when using object groups or hierarchies) and placed in a world. Its rendering will happen automatically based on camera/viewport couples that are also placed in the world. In your code, all you'll have to do is to query the virtual input (which can be rebound to any peripheral either offline in config or at runtime in code) and modify your object state (speed, current/target animation, ...). There's no bitmap (or shaders, for more advanced cases), physics, sound, animation frames bookkeeping to be made on your side: you focus on the actual logic and the game itself, not on the components that will interact in order to provide a game framework.

    I've probably been in the game industry for a bit too long to give a simple explanation though, so hopefully someone with a more recent experience will be able to provide a better picture. :)
  • edited January 2015
    Actually I think the tutorial #1, which is very simple, can help to illustrate the whole thing when toying around inside its config file.
    There are basically two calls in this tutorial: one create a viewport, the other one create an object.
    Based on those two calls only, you can end up having simply a static image (that you will see when running it), but you can end up with something more evolved that would contain a whole scene, particle emitters, effects, animations, sound/music, shaders, post-processing, render-to-texture, and even input interaction or some limited logic, simply based on the data described in the config file.
  • edited January 2015
    Ok, a last example then I stop, I promise! :P

    Here's a simple test I wrote a while ago to show some examples of what could be done using the config system.

    The actual code is here.
    And the config data (with comments) here.
  • edited January 2015
    Very useful stuff! I was clearly thinking of this in the wrong way. I'm used to writing my own engines, things have clearly moved on quite a bit!

    I'll go through your samples next and see if I can drag my ancient brain around to using a new approach ;-)

  • edited January 2015
    Don't hesitate if you have any questions, sometimes it can help saving quite a lot of time. ;)
Sign In or Register to comment.