Hey guy. First of all I have been browsing your documents and tutorials, and your engine looks amazingly simple while still allowing the developer coding control! That is just brilliant.
I have had experience in coding in flash and decided I'd love to make a great game. I've got a couple of ideas and a friend who is great at graphic design to help me. We're in the process of completing this flash game... well it'll be done after my exams ending the 28th Jan!
However I wanted a simpler system to develop a game with for the future (after the flash game :P). I looked at things like Unity, but, I felt that because I couldn't see the code and so much of it was drag and drop with a bit of scripting, I wouldn't be able to control enough. However when I looked at designing my own game engine, especially the graphics side, I almost died with fright. I'm not that an experienced coder. All the amazing indie games such as Osmos and World of Goo seem to have home brewed engines.
I think in ORX I have finally found and adaptable engine that I could build on if I found I needed more functions or libraries.
Another consideration was re usability of the engine. Without designing my own engine or porting another I couldn't do cross platform, Windows, Linux, Android and iPhone development.
I really want to create a game which could really show of this engine. If it could be published on steam, all the better! But we'll have to see about that.
I have a few questions about the engine. For sprites etc, what file formats are supported/recommended?
Is openAL supported for audio?
Which is better use Box2d which you have integrated or edit the engine to work with Open Dynamics Engine.
As far as I know, ode is oriented to 3d physical world. while the box2d is 2d-oriented. for a game engine of 2d-oriented. it haven't integrated with ode yet.
openal support for orx in windows, linux,mac iphone but android version do not support it, resulting from hardware openal is not supported by android.
I also wish one day orx will be ported to flash. But I have little knowledge about flash.
I believe iarwain will be very happy that you are fond of this game engine. In fact me too.
I was not aware that openAL was not supported by android. What a shame. I assume that I'll have to make a couple of versions of the game now.
ODE is supported in a 2d environment. In fact that is what World of Goo uses.
I'd love to port to flash, but I don't believe I have sufficient experience to do so. One reason I wanted to find a game engine was that I didn't feel I could make my own.
So yesterday I got my C++ book out to look over the syntax etc. The first 8 hrs in this 24 hour book were covered in 1 hour of reading. So far minor differences in select pieces of syntax, but not to much. I've yet to read about the way C++ deals with classes.
Second thing, don't assume you'll have to make multiple versions, I know there's a lot going on in the svn currently, and it's quite possible some of it may help with the 'android problem' so to speak.
And, more importantly, worst case scenario: You won't have to make multiple versions, but instead 'simply' write a single audio plugin specifically for the android build. (Not quite as scary as it sounds.)
Third, feel free to ask if you'd like some help or advice, we're a quiet lot, but we tend to be quick to answer. (And iarwain is a work-a-holic so it's almost certain he'll be ready to throw in some help at the drop of a hat )
First of all, thanks for all your kind words about orx, it's really appreciated. I'm also glad to see that you already got some good replies.
As Laschweinski said, no OpenAL support on Android unfortunately.
Using a software-only port of OpenAL proved to be very slow, from what Laschweinski told me as he's our Android expert and did all the work of porting orx for Android.
From what he told me, version 2.3 brings an alternative which could be a solution but is only compatible with 2.3 and not with previous versions. So you can expect orx 1.4 in mid-2011 to have a better sound support than 1.3 which should be released in January. We don't want to rush for the sound plugin right now as it'll take a while before 2.3 is installed everywhere.
As Grey said, when using orx you write your game once and you can then compile for different targets: windows, linux, mac, iPhone, iPad and soon Android. The only changes you might want to make might concern inputs and graphic/sound quality/resolution.
This along its data driven design allow for a very fast game creation. It's probably not that relevant, but Mushroom Stew on mac/win/linux was made in 20-25h of work, including all the code and level design. All the sound and graphic assets already existed.
I spent long hours working on the title and water shaders so it's not that representative of what you can do in a small time frame.
As for ODE, it can support 2D, I also considered writing a plugin for it (and Bullet too), but I decided to take a 2D only physics engine at first as, from my readings by then, it'd be more adapted (better simulation/performances). Chipmunk was another candidate but I simply didn't have the time to work on multiple physics plugins.
As a side note, I've added joints support in orx a week or two ago and this will be available with v1.3.
Concerning sprites, when using the GLFW plugin (default display plugin for win/linux/mac) you can load BMP, TGA, DDS, PNG and JPG. You can, however, only save images in BMP, TGA or DDS.
Note also that you can create textures on the fly at runtime so you can add your own image loader and feeds orx with the result.
There's a bunch of hidden/extra/unusual features in orx which I found to be hard to advertise so as Grey said, don't hesitate to ask if you have any questions, there'll be someone around to give you an answer in usually pretty short delays.
Also, v1.2 is getting really outdated, a lot of things have changed since the last release (big performance boosts in rendering, new features, new platform, bug fixes, ...) so expect to have even a better engine available in about a month.
Or if you're up for it, there's anonymous read access to the svn!
Oh great! The main thing at the moment is getting my head around the c syntax. Some of it is very similar and then other parts are so different such as the bizzarre capitalisation and ways of stating class relationships. I never really used classes much in as3 , but I'm sure they were eadier to understand.
In addition what anime character is that in your avatar Grey? I honestly am scared be her... I love my family...
If you'd like I can dump a bunch of C/C++ development references in your direction. (pm or something, to save on spamming the forums et al) I've not done any actions script stuff before, so can't really offer any specific pointers otherwise. Happy to answer any specific questions however. Even syntax/c++ stuff not directly related to Orx.
Edit: Never mind, I've found it in the other tutorial source files from the download section.
I understand them, however I can honestly not see the point in them, pun intended :laugh:!
As far as I am aware pointers don't exist in AS3, not even sure if they do in java. But if they did, I wouldn't have used them because I wouldn't have known where to use them.
So to pass the return value of one function to another you must use the pointer of that function?
Rather than try to explain with my half-asleep brain, I've done a very quick hit of google-fu and hit on a (thankfully appropriate) stack overflow page:
This doesn't really cover the 'why', so much as the 'what', but does it in a (I find) very clear and 'real world use' kind of way. Please note this is almost certainly not an exhaustive list, and what with being half asleep I can't be absolutely certain there's nothing wrong with it, but from an initial glance it's a -lot- better than I would manage right now. If that doesn't help, drop some more messages here and I will read them after I've slept.
*edit2* ... sometimes I fail >.<
(Full disclosure, I'm 'stealing' the theme from my above posted link, and also half asleep, so there may be errors or inconsistencies! I'll try to avoid them!)
Why use pointers comes down to this: If you make a variable and want to use it inside a function, it is --much-- cheaper to copy only the -address- of the variable, (ie: a pointer) and make your changes like that, than trying to copy the entire data from your variable into a function, make changes, then copy it back out as a return value.
*edit* whoops, yay for double-post :P