As a learning exercise I'm trying to make a physics testbed with SVN HEAD. I've gotten as far as repurposing the physics tutorial into a standalone program and recognizing when an object is clicked on. I want (as a start) to be able to "pick up" objects and drag them around with the mouse, but I currently have two problems:
1) I can't figure out how to get all the information about a body associated with an object. Specifically I need to know if a body is dynamic or static, but I don't see any way to determine that for an arbitrary object. I thought I was onto something using orxStructure_TestFlags() and orxBODY_DEF_KU32_FLAG_DYNAMIC, but that didn't work out.
2) It looks like there's no MouseJoint. I'd accept it if this (and perhaps the preceeding issue) is something too specific to Box2D to be included in Orx's API, but if that's the case can someone recommend a good alternative? orxObject_SetPosition doesn't play well with the physics engine. I've only used Box2D a little before this (and then only version 2.0) so maybe something equivalent can be done with the other joints.
I'm also trying to understand Orx's object system; are orxOBJECTs supersets of orxBODY, and is the proper way of going from the former to the latter to cast the object with orxBODY()? Or with orxOBJECT_GET_STRUCTURE()?
Comments
It might not be obvious, but it's a _DEF_ flag, so it's only used in body definitions.
If you need accessors I can add them. What I usually do is that I store this kind of information in the object's config and I get it at runtime. Something like:
That's right, the mouse joint has been designed mostly for Box2D's testbed, according to Erin. You might achieve the same result with other joints, but I'll need to go look at them first as I don't know them by heart, not using them much myself.
An easy way to move the object to the mouse is by setting its speed according to the delta time and the current position delta. That whould work fine and not break the physics simulation.
orxOBJECTs are empty shells: they're just containers for components such as orxBODY, orxGRAPHIC, orxCLOCK, orxSPAWNER, ...
You need to use orxOBJECT_GET_STRUCTURE to retrieve them.
I did realize that, but thought it might magically work anyway. :P
That's pretty reasonable, though I think it'd improve Orx's usefulness for rapid prototyping if you didn't have to do that kind of bookkeeping -- at least for the things Orx keeps track of internally anyway. In this case it might be best to have one getter for all the flags relevant to a body (even though, at the moment, I'm not sure what other flags I might need to know about).
That sounds promising. And I'll see if I can figure out how MouseJoint actually works too (maybe it does exactly what you suggested?)...
Could you explain what orxSTRUCTURE_GET_POINTER() does and what the macros in orxStructure.h that use it are for? Are they for casting an orxSTRUCTURE (which is the root class?) into other types?
Ahah, no magic trick there, I'm afraid!
You're totally right about that. The problem, in this case, being that orx actually doesn't store this information, only Box2D does.
It's very easy to add and I've never done it so far as I never had to use that information myself. I'm out tonight but I'll try to add it tomorrow (along with all the other def properties).
In the meantime, another option that would work without having to alter the config would be to actually push the body's config section and look for the Dynamic property on it, instead of adding one manually on the object.
You should never have to call orxSTRUCTURE_GET_POINTER() yourself but it's the base for all the convert macros (orxOBJECT(), orxCLOCK(), ...). What it does is cast the result of _orxStructure_GetPointer() into the right type.
This function itself will use use a cheap RTTI-like mecanism to verify you're accessing the data that is actually of the requested type and a faster but less secure one in release (still performing a check but without the use of the magic number 0xDEFACED0).
That's why one should always use them when casting structures instead of using the traditional c-style cast.
It'll also complain if you use them on an object that has been deleted, due to the presence of the magic number 0xDEADC0DE.
And yes, you're right, the base "class" is orxSTRUCTURE, which provides storage (and allows to parse all the collections of different types), sorting (either in list or tree), ID and reference counter. All the orxStructure_* function can be called on any derived type, which list in at the top of orxStructure.h. It's a cheap version of inheritance in C that works just fine for orx's needs.
Haven't tested it but I don't see how it could not work.
I need a way to set the Linear Damping of an object at runtime. Maybe an orxObject_SetLinearDamping( orxFLOAT ) or something the engine already has but I didn't find.
Thanks.
Sure, I'll add the accessors, both get and set, for linear and angular damping in the body module. I'm getting married on Friday and attending the GDC tomorrow so it might not happen before Monday.