The Orx 2D game engine will be ported to the Pandora


atomicthumbs

I am the king of the collectors, with hospital bed
Joined
Apr 17, 2006
Messages
2,827
Age
31
Location
XK-Masada
Website
printeronfire.org
http://orx-project.org/index.php?option ... 3&catid=12

Woot! I think I'll develop my game using this.

iarwain said:
Hi and welcome atomicthumbs!

There will definitely be a pandora version of orx. That's why I stopped focusing on the GP2X version lately (lacking of time and having debug trouble because of the GP2X-F200 poor design for developpers).

I applied for a pandora-MK0 back then but wasn't selected.
I'll get a pandora when it's released and porting orx on it will probably (hopefully) just be a matter of days.

Till then the next version to expect will be the iPhone one.

More about Orx:

Here is a list of its main "common" features:
extremely easy to use: all objects have simple accessors that allow you to change all properties in one line of code (graphic, animation, sound, physics, visual FX, and much more)

Automatic sprite rendering using 3D hardware acceleration allowing: translations, anisotropic scale, rotation, transparency (alpha blending), coloring, tiling and mirroring

camera/viewport system allowing multiple views on one screen with camera translation, zoom and rotation

sound and music handling where you can tweak volume and pitch

collision handling and rigid body physics

easy to use animation system

event management

being data-driven means you only need to write one line of code to create a full featured object, as all of its properties can be defined through config files and changed without any need to recompile. For example, you can add graphics, collision and physics on an object without having to write a single line of code for it!

powerful configuration system, featuring inheritance, direct random control and history reload, allowing you to tweak almost everything without having to change a single line of your code

And also more unusual and powerful features:
clock system allowing you to keep time consistency everywhere and, more important, giving you the ability of doing local or global time stretching. Slowing down (or speeding up) time for a bunch of monsters or your background music has never been easier!

animation chaining graph: you define in the config files all possible transitions for your characters, and you simply have to ask the animation you want to play without having to bother with the current running animation and all the chaining. For example, if you want to run, in your code you simply need to ask for the run animation and the engine will take car of all transitions for you, using the graph you defined in the config files. Your character was walking? Then he'll go directly to the run animation. Was it lying down? It'll first get up, then start running without having you to write all the code needed.

all of your game objects have 3D hierarchical positions, meaning that you can easily make groups of objects and move, rotate and/or scale all of them at once

visual FX: you define, as usual in config files, curves based on sine, sawtooth or linear shape and you can combine them into complex effects that can be applied on object color, alpha, position, translation or rotation. This is very handy for all the hit, fade in, fade out or even more complex eye-candy visual effects.

Differential scrolling upon request with an unlimited number of planes. Having objects scroll with different speed matching their depth from the camera is more than simple: you merely need to add one property in your config file telling that the object will use differential scrolling or even that it should scale relatively to its depth for a full 2.D rendering!

Its architecture is plugin based, which means that you can easily port it to new platforms and extend/customize it easily with your own plugins.



It can't be stressed enough: orx's main purpose is to allow fast and easy development and prototyping. Tasks such as creating a full differential scrolling sky filled with random sized and colored stars or clouds requires only a couple of lines of code in itself and less than 10 lines of config (.ini file).

Orx is mostly written in C (with some plugins in C++) but allows you to develop with it with any language that can interface to C (like C++ for example). Orx comes with a generic executable allowing you to prototype your code in a plugin but it also let you easily create your stand alone executable.
 
Is there any information about collision detection methods? And does it use its own physics, or an external one?
 
Thanks for the post, atomicthumbs! (and thanks for the referer for letting me know about this site!).

Note that I'll update the feature list in a couple of days as I'm releasing the v1.0rc0 which has a couple of new things, such as fragment shader support or the generic input system.

Esn said:
This sounds neat.

I wonder if he means that he has a preorder, or that he'll order from the second batch.

No preorder for me unfortunately, I'll order one from the next batch.

Hessiess said:
From the screen shots it appears to be resolution dependent.

Orx is actually resolution independent, if I understood what you meant. Object scales are computed depending on the camera size (frustum) and the size of the viewport and of the display surface. Just being curious, what made you think otherwise from the screenshots?

hybrid said:
Is there any information about collision detection methods? And does it use its own physics, or an external one?

Collision bodies are defined as compounds made of boxes, circles and convex polygons. Orx relies on a physics plugin to process collisions (and physics). So far I only wrote a plugin using Box2D but it's easy to add plugins based on any other libraries or even on your own code.


Here's a small particle test I've been updating lately showing what you can do with very few lines of code and orx's config system: http://orx-project.org/orx/particle-test.zip.

You can change presets with mouse left&right clicks or with up&down arrows. Presets are defined in the config files, you can change them and even add your own without having to restart the executable.

The source is also present in the archive, but I only included the windows executable so far. I might soon update it with linux and MacOS X binaries. You can also find the 2 "template" files that will give you info about which properties can be accessed directly from the config.

The version of orx which is used in this test is the latest svn one (v1.0rc0) in embedded mode. In this mode, all the plugins are embedded in orx.dll instead of being separated and loaded on the fly.

Any feedback if welcomed! :)
 
Orx is actually resolution independent, if I understood what you meant. Object scales are computed depending on the camera size (frustum) and the size of the viewport and of the display surface. Just being curious, what made you think otherwise from the screenshots?

The maximize button is greyed out, which means the window is non resizeable, which means that it IS resolution dependent in that it won't run maximized on different sized monitors.
 
Hessiess said:
Orx is actually resolution independent, if I understood what you meant. Object scales are computed depending on the camera size (frustum) and the size of the viewport and of the display surface. Just being curious, what made you think otherwise from the screenshots?

The maximize button is greyed out, which means the window is non resizeable, which means that it IS resolution dependent in that it won't run maximized on different sized monitors.

I think that we're dealing with two different kinds of "resolution dependence".

What Iarwain's talking about is that orx can use different resolutions of screen with no/minimal configuration changes. It would take a very small change to make the resolution user-changable, and that's up to the game designer.

Edit:

Looking at the code gives me an incentive to dig out one of my previously-abandoned books on C (unless there's a way to use python with orx). I gave up trying to learn C eight months ago, but maybe I'll try again. :)
 
atomicthumbs said:
Hessiess said:
Orx is actually resolution independent, if I understood what you meant. Object scales are computed depending on the camera size (frustum) and the size of the viewport and of the display surface. Just being curious, what made you think otherwise from the screenshots?

The maximize button is greyed out, which means the window is non resizeable, which means that it IS resolution dependent in that it won't run maximized on different sized monitors.

I think that we're dealing with two different kinds of "resolution dependence".

What Iarwain's talking about is that orx can use different resolutions of screen with no/minimal configuration changes. It would take a very small change to make the resolution user-changable, and that's up to the game designer.

If it runs in a fixed size window then logic says that it will appear smaller on a monitor with a higher DPI, hence fixed size window = resolution dependent. Fixed size windows should be disabled *NOT* enabled by default.
 
Hessiess said:
The maximize button is greyed out, which means the window is non resizeable, which means that it IS resolution dependent in that it won't run maximized on different sized monitors.

I fail to see any relations between these 2 statements. The fact one doesn't want the user to resize its application during runtime doesn't mean it can't run maximised and/or fullscreen on screen with different resolutions. It's up to the user to choose the resolution he wants (if the developper gave him this choice, of course), and that's what config files are for, as atomicthumbs stated.
It can even be chosen to hide window decorations for aesthetic purpose as, on the opposite, it can be chosen to run maximised on any computers, whichever resolution their display is set to.

If it runs in a fixed size window then logic says that it will appear smaller on a monitor with a higher DPI, hence fixed size window = resolution dependent. Fixed size windows should be disabled *NOT* enabled by default.

Same comment here. It's not because one will run it in 800x600 that another one can't run it in 1440x900.

I really don't see the link you're trying to express between runtime resize and resolution dependency.
As far as games are concerned, I don't think giving a runtime resize option is something very interesting considering UI objects placement and visual artefacts that can appear, especially for pixel art games with no antialiasing. It reminds me of a post from Jonathan Blow who was explaining Braid was always rendered at a fixed resolution, then the result was downsampled according to the user choice.

atomicthumbs said:
Looking at the code gives me an incentive to dig out one of my previously-abandoned books on C (unless there's a way to use python with orx). I gave up trying to learn C eight months ago, but maybe I'll try again. :)

I'm sure C won't give you too much trouble if you're motivated enough, atomicthumbs. :)
As for python, I think writing a wrapper would be pretty straightforward from what I read. However I never wrote a single line of python and I'm really lacking time with E3 coming soon. If you'd like to give a try at writing such a wrapper, feel free to let me know! :)
 
MistaGiggles said:
This looks like a very nice 2d engine, I'm tempted to start using it for my own projects.

Thanks for your appreciation! :)

If you have any questions, feel free to ask! I try to give as much support as possible to those who want to try it. :)
 
looks interesting
dont know whether ill be using it though,

however one thing which would make this very attractive is the ability for concave shapes, obviously translated to convex before any processing
its been discussed on box2d forums
 
emcp said:
looks interesting
dont know whether ill be using it though,

however one thing which would make this very attractive is the ability for concave shapes, obviously translated to convex before any processing
its been discussed on box2d forums

Yes you're totally right, using concave shapes would be a big relief. Right now you have to manually decompose them in compounds of convex shapes, which can be a bit tedious.
However, as you wrote, there are algorithms to make this decomposition for you, someone could always add one to orx's physics plugin. I probably won't do it myself, though, lacking of time.
 
Back
Top