i just found orx a few weeks ago. I think, its a good engine. It has many features i need (including animation, good event-system, FX and physics). Before orx, i used SFML (good library btw
) but i had to develop many features that orx already has. So, i switched to orx :P
Now to my problem. Physics is a great playground for me
I am just experimenting with Joints. In the box2d documentation, there is this example:
jointDef.Initialize(myBody1, myBody2, myBody1->GetWorldCenter());
How do i do this in orx? I found nothing about joints in the orx documentation, so i tried to implement the above code, but it doesnt work neither.
Can any body help me?
btw, the website doesnt work. It just works if you put "index.php" infront of it:
<- not working
Last but not least, sorry for my english, my native language is german/turkish. I will eventually write a german translation of the orx tutorials. But first, let me code some games with it :P
First of all, welcome here and thanks for your feedback!
I'm glad to see some people are giving orx a chance even if we get few or no feedback at all.
I've corrected the website issue tonight: my web host added a generic index.html in my folder, probably after some automated script execution (they moved my account to another server, but as they also deleted my mail forwarders, I didn't receive any mail keeping me informed...).
I'll probably switch for another host in a couple of weeks so as to prevent this kind of issues in the future.
Sorry about that!
As for Box2D joints, they currently aren't implemented, unfortunately.
There are 2 reasons for this: 1st, no request was done for it and I had no need for them so far; 2nd, I wanted to think of a clean way for adding them through orx's config system.
I'm currently in vacation so I won't be able to add this before early January 2009. I only have a macbook with me here, and the few hours I'll spend coding, I'll try to put a fully working mac OS X version of orx out there.
As a matter of fact, SFML is bugging me with this. The last working mac os X version was the SFML 1.1, so I tried with the current svn version. After some struggling I was able to have a running version of orx on mac OS X, but SFML is currenlty bugged on mac AND linux.
The linux version crashes because of a memory corruption, and mac version can't handle mouse position access nor text display (crash for the text display because of their unicose module).
As I'm only using the openGL feature of SFML and their font management, I'm considering switching my main plugin chain back to SDL.
Actually orx has its own resource management, so it's not using SFML's one. I just need to find some time to write the openGL display code and the font creation/management one. I was hoping to do it during the vacation and probably the first week after.
If you really can't wait for the joint support in orx, there are 2 possible solutions:
- you can contribute to orx and add the support to the Box2D plugin + wrapper in orxBody.h/.cpp, I'll then add your code to the svn repository, with full credits, of course
- you can hack orx source to have a direct access to the orxPhysics field of the orxBody module. This is the Box2D body object, you will then be able to use direct Box2D code. This is pretty fast, but it's temporary code! :P
Anyway I'm sorry for the inconvenience, I won't be able to do it myself before 2-3 weeks.
Hope this is not too blocking for you!
Thanks again for your post, and of course, a German version of tutorials would be greatly appreciated!
I can understand a bit of German, but I'm not fluent anymore unfortunately. It's already hard for me to have an understandable English so...
thank you for the reply
Hm, bad for me :ohmy:
I just wanted to play with it, nothing more i think. Would be cool to shoot my enemy, and he would fly around with cool physic effects :P
But i can wait for this feature. I'm coding another game until then.
AFAIK the next stable SFML release (v1.4) will have Mac OS X support. I think, this one should run on a Mac just fine. I don't have a mac; its more important for me, that my game runs on linux (and windows ... and *BSD would also be great :P ).
If somebody makes a few good games in ORX, it would be a good advertisement for the engine, so we would get more developers helping you out with the code
I think, i could do it. Maybe the second one, but it shouldn't be hard to code
No problem dude. I can do it a few weeks without this feature
I have many ideas for games, which are possible to develop without joints
I'm working on it! Maybe i will also write some tutorials, how to start coding with orx, and some example games (pong or something), in english and german.
Anyway, thanks for your time; i will start a thread again, after i finish some games in orx
Great, I'll add to joint support to my todo list when I'm back in january then. It shouldn't be too long to do, I'd just like to make it easy to use through the config system (data driven).
That's what they say, and I want to trust them, but they also say that SFML 1.4 should soon be released.
And seeing the current svn version, it's not stable enough. At least on Mac OS X & linux. The linux version has regression (crash) and the mac OS X isn't ready for a release. I also noticed they aren't a lot of commits these past weeks, so it might take a while before they can make the 1.4 release.
That's what I'd love to see. I posted quite a few (and sometimes lenghty) posts on a few different forums (tigsource, freegamedev, developpez.com, games-creators and gamedev), but I usually have little to no answer at all.
I'm currently working on a few game prototypes, but my free time isn't that expendable, so it takes a long time, having also orx to maintain. If you want to post your games/prototypes on this site, I'd be happy to dedicate a page to them, btw.
The second option was more for you not to be stuck with this issue, but if you feel like going for the first one, go for it, I'd be happy to have other contributors to orx!
Great then! I'm glad it isn't too big an issue for now! Btw, if you need more precisions about how to do stuff with orx, feel free to ask. As a matter of fact, I've added a few new features since the tutorials, and I haven't had much time to update them.
One good way to learn is also to look at small examples I've posted like the particle test or the WIP game/musical experiment called Drops.
Thanks for giving orx a try, and if you have any suggestions, feature requests or improvements, feel free to ask! I'm happy to have feedbacks!
I'd also love to see how you use orx and having german tutorials and/or examples like pong or like would be greatly appreciated!
I haven't had time for adding the joints, but I just added tonight support for defining convex meshes as body shapes. This will help to have collision that fits better objects that are not based on boxes and circles!
I'll lack time to do the joint support, so if anyone wants to lend me a hand here, please let me know!
Maintaining orx on all platforms (win/visual, win/mingw, linux and mac os X x86/ppc) and adding new features is a huge task for a single person. I couldn't even find time to debug the GP2X version (it compiles fine but something goes wrong at runtime and I don't have the correct cables to debug it).
I'll continue adding new features after the 1.0 release, but probably at a slower pace than last year (my summer was pretty crazy working 40/45+ hours per week in addition to my full time job).
Every help is welcomed! Especially if you're using it and would like to help building a wiki to help newcomers getting into it. I'll post on the news section about this next week.
So basically, new stuff in the physics section of orx, but no joint support yet!
Besides the above, the only flaw I've seen with this engine is me not knowing how to start designing.
Actually there's currently no estimation for the integration of the joints directly in orx.
It shouldn't be too much work but I'm already struggling with trying to find time to work on the iphone version so I won't be able to do it myself anytime soon.
Of course, if you or anybody else feels like adding their support to orx, I'll be more than happy to help with that.
That being said, while joints are not officially supported at orx's level, the fact that the only available physics plugin for orx is based on Box2D allows you to use joints directly with Box2D's API.
There's only a slight modification to add to orx for that and no need to recompile it.
The easiest way to cheat and use Box2D directly for joints is by getting the definition of struct __orxBODY_t from orxBody.c and put it at the beginning of orxBody.h so that you can access all its fields directly.
The fiel called pstData (of type orxPHYSICS_BODY) is actually a Box2D b2Body.
With that info you can handles joints the same way you would have done by using Box2D directly. More info here.
This way you're not stuck while the feature is actually supported at orx's level.
As for the perfect pixel collision, it's something I'd like to add but that would prevent orx from benefiting of Box2D's physics simulation. It can be a plugin dedicated to pixel perfect collisions with a very basic dynamics support for certain types of games (such as shmups for example).
Hope this helps!
As for PP collisions, it's just that Box2D performs its collisions and dynamics/reactions at the same time. I presume it'd be possible to have a custom collision computation and give the info to Box2D but it might be somewhat tricky to do. So far all my experiences with compounds of polygons gave pretty good results.
As for the no-config use, sure, orx can be used (almost) completely without touching the configs. The only exceptions that come to me right now being the display settings and the fragment shaders. And even for that, you can find all-code work arounds, but it's a bit more tedious.
Config-related functions are most often only wrappers around lower level functions. However if you give the config system a try you might find it very handy as it allows developping/tweaking stuff in a far more efficient way than the "traditionnal" all-code approach. Hopefully, the tutorials and the config section in the wiki will help you discovering its possibilities. But of course, this boils down to a matter of taste, so developping with orx without using its data-driven aspect is totally possible.
If you have any questions regarding how to use the config system or orx in general, I'll be happy to answer them!
The structure I started in my head had all game objects have properties that are shared properties.(ex. enemy.health is the health of the instance of the enemy.) This seems to be possible with the configs as I've seen so far, but I don't understand how to access an object when instances are multiple, or even how to access them at all from the code.(the tutorials do a good job of showing how to set one time properties of objects, but I didn't see something that explained how the config files translate to code usage, if at all.)The spawner object seems to be related to multiple objects, but the tutorials only showed how to spawn items with a "mind of their own".(ex. they operate due to simple pre-defined actions. It doesn't show if objects can be placed individually by their needed location, like a specific hole an a scene an object should reside in.)
Now, another part that seems a void is a way to create a whole map on screen easily. Now, it seems you had/have an editor you've been working on that could help solve this, but how these objects on the map can turn into physics bounds is also something I haven't found. (ex. creating a map, some just terrain and others "boxes" or other physics enabled objects.)
Also, how are configs stored and accessed in code? I think I saw something that showed .inis can be turned into .so files, but what is this for? Do you link them together to the game exe in the end or are the .so not related to the .inis?
On my questions before about asking if I could do it all in C, I asked because I haven't really written anything game-wise(except a few) in which I didn't code in myself an object's actions. It seems the .inis should be less work and easier, but it doesn't help if I'm not familiar with them yet.
Also, I've pre-ordered a Pandora and am interested in this platform. Do you know if there might be any plugins that will not work/be compiled for it?
EDIT:it seems some more parts I didn't know about describing the config structure were on a part of the wiki I didn't know existed. Will look at this, but would still like to have it explained too.
And it will still be the case with your enemy object in orx. The config is only there to help you setting up initial values. However, the "current" values of your objects will be stored in your object class.
So basically if you have a class called CEnemy, for example, you can declare it like this:
Your CEnemy ctor will then look something like this:
And somewhere in your config file you'll have:
Of course if you want to centralize the health amount for all your kind of enemies you can have something like this:
Not sure if that answers your question.
Well, each instance of an orx object is bound to its instance counterpart in your game logic. So as long as you keep references on your C++ game instances, you can access its orx's binding this way:
You're totally correct. That's why orxSPAWNER is very good for weapons, particles, ... and all "spawned" stuff.
However, when a orxSPAWNER spawns an object, it'll send an event of type/ID: orxEVENT_TYPE_SPAWNER/orxSPAWNER_EVENT_SPAWN.
The sender being the spawner and the recipient being the spawned object. You can listen to this kind of event and when you recognize an object (calling orxObject_GetName() gives you its config name), you can then intanciate your corresponding game class, bind it to orx object, etc... in the same way you'd do if you had created the orx object yourself directly.
The most simple way of storing objects is to store a scene using the ChildList property:
And have a separate config entry for Enemy1, Enemy2, etc...
Then all you need to do is call:
We could have called orxObject_Delete(pstScene) directly but if you do it from an event callback, it can be unsafe whereas setting its LifeTime to 0 seconds is always safe.
Now the editor light I wrote (named Scroll) has a different approach as the one above only allows 256 direct children and need you to have a separate config entry for all the objects.
What I do is use a naming convention (for example GameObject0000, that allows me to create up to 10000 objects for a level), and in every entry I store the instance information: its position, orientation, color, tiling, smoothing, etc.. and its model name (the usual orxOBJECT config entry). Then I iterate through the whole list, create an object of the corresponding model and finally override its current properties with the one stored as mentionned above.
Remember an important thing: the config module is great for initializing stuff but it can be modified at runtime and saved in different files, allowing you to make savegames for example!
For that, you can see a basic savegame handling in the Drops prototype, looking at its code/config files.
Actually, no, .ini will stay this way. The only thing you can do is encrypt them to prevent players from fiddling with your settings.
The .so are plugins loaded on the fly that contains your game code when using orx's default launcher (tutorials 1-9). However this is only useful when you want to try something very fast with the minimum amount of lines of code. However, nowadays, creating your own stand alone executable based on orx doesn't take much longer (it wasn't always the case) as you can see in the tutorials #10 & #11.
The default .ini file (named after your executable) will be automatically loaded, but, at runtime, you can load any other config file you want, clear info, add/override info and so on... More info about it here!
Hope the above answers helped you with that! Let me know if you still have missing info!
As soon as I'll be done with the SDL/OpenGL plugins for orx (my current task on orx actually), the Pandora version shouldn't be hard to obtain. However my finances are a bit tight now and I won't be able to get a Pandora before end of 2010 probably, so if someone wants to help with the port, he's more than welcome to contact me!
Hopefully both the wiki and my answers above will help you get started with that. If you still have questions about that, I'll be happy to help!
As for orx, did you get both the source and the extern package? Which way are you using to compile? The makefiles are somewhat defective and I wasn't the one who wrote them so I kind of stop maintaining them. On linux the best for for compiling all the orx versions is by using CodeLite and the corresponding project files.
Someone reported me once he compiled orx on linux 64 but as I didn't do it myself I don't know if it's troublesome or not. For Linux32 it sure compiles out of the box (gcc 3.4.x & gcc 4.x) as long as you have all the external dependencies (the extern package).
However I suggest you directly sync the svn repository (the whole /trunk, via the sourceforge page) as there have been some important changes since the v1.0.
It will soon be released as v1.1 anyway, provided I find someone to package the visual studio 2005 version.
EDIT: Also if you have more details about the compile/link issues it'll be more easy for me to help you with that!
EDIT:oh, and this is the framework:
libstaticliborxd.a no such file or directory
So I decided to try and compile the externs first. box2d compiled once I added #include <cstring> to some of the headers. SFML had more errors than I cared to fix, one of them being it thought I was building for windows.
EDIT:would installing packages for some of these items in my system be of use? Or does it have to be the exact version in the externs packages?
EDIT2:just saw your PM, guess I should take this out of this forum, as it's not totally in line with the original post anymore.
I'll continue this in pm so we can figure out what's going wrong.
I encountered this. Calling orxObject_Delete from my animation event callback raised an exception in orxClock_Update().
It would be useful for others if this info were added to the Doxygen for orxObject_Delete!
Also note that I recently added a debug warning message at runtime: