It looks like you're new here. If you want to get involved, click one of these buttons!
As you've seen, orx's only usable with C/C++ right now but in a couple of months C# and Python might also be available.
I'll take this opportunity to give an update on the current status on PyOrx (still not completely sure about the name :P). I think I am going to use Cython, rather than communicating directly with the Python API--that was a horrible experience. Holiday's over, so it'll be quite a few months before I have something to show.
I now have a question for you: would you mind telling us for how long you've been looking into orx, what do you like/dislike about and any other feedback you'd have? User feedbacks is precious and I'm afraid we don't get enough of them.
So here it goes.
I was looking for a gfx library supporting accelerated 2D graphics. Went through pretty much everything on the list that has native C/C++ support, downloaded it and tested provided samples, looked at the code, etc. I decided ORX is what I need for several reasons.
1. No scripting language - no python/ruby/fancy_new_lang lockdown
2. No XML (I'm a strong believer that INIs are easier to edit/understand than XMLs are for so called avg person)
3. Accelerated 2D with little fluff (e.g. no support for 3D models)
4. Pretty good samples
5. Documentation that makes sense and is easy to follow.
6. Native C bindings instead of C++ classes
7. Shader support (well, as it turned out - kinda ;])
8. Code (lib/inc) organized in a way that allowed me to build standalone EXE using ORX in about a minute. (we'll see how easy/hard it is to hack ORX code itself, but based on my experience so far I'm hoping it will be fun too)
At this point I don't care about animation, physics or audio. It's nice they are there but what's even better is that they don't get in the way at all. I wanted something basic to play around with, not another 800 pound gorilla I have to learn for hours to get a Hello World-quality results. INI based configuration is fun to play with and encouraged me to stick to ORX.
Now to the negatives.
1. Per object shaders don't work and that's what I was hoping for the most. The good news is - no other sane library supports that. But that's no excuse. :P
2. I understand why it's good to have multi-platform support, but right now I don't really see any point in maintaining two separate display drivers (SDL/SFML). ORX would IMO benefit from less, well tested code paths. Audio files and images can be easily converted nowadays, there's no need in doing everything for everyone.
3. I was hoping ORX has its own display implementation (not depending on SDL/SFML) and not knowing the truth was one of the reasons I kept playing with it. I would love to see display implemented without external dependencies.
Overall I'm very hapy with ORX and plan on using it.I need per object shaders to work so I'm going to focus on implementing that feature. INI based configuration is too cool to drop ORX and start using something else.
Points 1, 2, 3 and 6 are usually turn downs for people who decide not to use orx. I'm glad it's the exact opposite for you! As for the INI, I thought I was the only one left alive in the world one with this preference.
Only the low level functions are deferred to external libraries (like blitting a bitmap). The rendering logic is homemade, in a plugin without any external dependency.
I'd like orx to be as easy to use as possible, and with a reduced developper team of 1 for the core as for the last 2 years, I have to prioritize and make compromises. In the end I want also to use orx, not only to develop it, as I plan to make a living out of indie games done with it. That's my escape plan from the mainstream industry before it turns out I've been working there for 10 years. And this milestone is drawing near...
I'm really happy to see that and see your motivation. If at some point you discover that orx is lacking features or anything that will get you less motivated about the project, please let me know as it might be fixed whereas if you don't say anything I won't be able to help. Of course, this works for all orx users.
You're not. In fact I used to work with people who simply hate XML. It's great in theory and there are cases where it makes sense. But the moment people started storing binary data in XML it was evident that hype is clouding ppls judgement. XML is easy to reverse engineer, but for someone who's only proficient with word processor, INIs are much easier to grasp. Extensions to INI ORX uses are easy to understand yet pretty powerful at the same time. I like it. For me that's the number one reason why I don't want to switch.
3D models should be an easy to add plugin if people feel like it's needed in the future. Scripting language is unnecessary since building ORX based code is super easy and all of the core functionality one would like to tweak can be exposed in INI. Perhaps the importance of INIs should be stressed more? I for one started by looking at the code and only when I realized there isn't any for some of the samples, I started looking at the config files.
I know. I looked at the 37 functions that display plugins have to implement and that's why I think it's possible for me (as in: I don't have to spend my whole life on it) to implement it in pure OGL*) without any dep on SDL/SFML.
*) I'd rather do it in DX, but if I'm going to code something, community would probably benefit more from OGL implementation
Better do it sooner than later. Indie is getting dangerously mainstream these days.
I'm trying to convince a bunch of friends to create a pretty simple 2D game using ORX. I have an idea for a pretty neat technology that would make this game stand out in terms of graphics, but I need per object shaders to prototype it. So yeah, back to cleaning up my place and then some more coding.
Greetings to the ORX forum users.
I am an indie game developer who has been using the FlatRedBall game engine for the last few years (I recently finished a game with the FRB engine) and am considering moving to a different game engine.
Although I am very pleased with the FRB engine the need for MacOS support has started this search for a new engine.
My next game will be a 2.5d side-scroller. (I'd like the characters to be 2d, the game play 2d, but have the background and the terrain be 3d (boxes, pyramids etc.) or more speifically speaking have a 3d effect).
I read a bit about ORX in the wiki but I have a few questions which I'd like to ask.
1. To create a game for several platforms (specifically Windows, Mac, Linux & IPhone) can I use the same source code or do I need to rewrite the code with a different plugin for each targeted OS?
2. What is the meaning of "no 3d rendering"? Does this mean that you can only place sprites at a 90 degrees angle from the camera? I suppose not but I didn't quite understand.
3. Does the engine use directx? Can it? (For several reasons I prefer using directx graphics over OpenGL)
4. How can I use the engine with C++ code (it is easier for me)
5. Have any 2.5d games used the ORX engine?
Thanks in advance, I look forward to creating games with this engine.
Wow! You really answered quickly!
Regarding the 3d effect - I think I didn't quite explain myself properly.
What I'm looking to do in that aspect is very similar to the following link (the relevant gameplay starts around 2:15 minutes):
Generally speaking, I'd like to make a platformer with 3d depth (while the gameplay is 2d, the look is 3d).
Can this currently be done using ORX? How?
Thanks again for the quick response. This engine really feels right for me. If my 2.5d platformer is doable I think I'll do it here regardless the lack of directx.