Create My Own Component

#1 Create a physics component that connects with your physics engine. Then have that compent perform any of ht ephysics you want on the sprit itself.

Then just add that component to the sprite in question and you're off.

Take the physics component of tankbuster as an example of how to create a component.

It's pretty straightforward to do and not very difficult.

#2 The component you add to each T2DSceneObject can be the physics engine. That's basically how stock TX does it with the T2DPhysicsComponent. Yes, you will want to do your regular updating in the ProcessTick method.

#3 I'm still getting my head around this whole component based architecture. I like it so far but it's a bit of a learning curve so please bare with me. :-)

I'm still not quite understanding how to set up my Physics Enigne. Here is how I would do it outside TorqueX:

//as the game starts up/intiailzes
PhysicsSimulator physicsSimulator = new PhysicsSimulator() 'this is a single global object (singleton)

RigidBody rb = new RigidBody()
Sprite sprite = new Sprite()

//every 60 milliseconds
physicsSimulator.Update(1/60)

sprite.Position = rb.Position
sprite.Orientation = rb.Orientation.

So, the thing I am having trouble with (I think), is how to set up the PhysicsEngine as a singleton that will recieve constant updates from the underlying TorqueX renderer.

Creating this object as a component seems wrong since it is a singleton object. Currently I'm leaning toward just creating this object as a singleton type object then hooking into the PumpEvent to update the physics engine.

Then, I would create a MyPhysicsComponent (or some such thing) that would new up a rigid body, add it to the global physics enigine object, then update the underlying sprite every frame through the ProcessTick callback. (all the hooking up would be behind the scenes of course.) I think this is what what you guys are suggesting, correct?)

thanks for the help on this.

Am I on the right track?

#4 So your design has a singleton with the "real" position/orientation of each object in the sim and the sprites are just ghosts of those objects? You then are updating the ghost at 60hz to match the position of the "real" object in the physics system. Just trying to make sure I follow.

You can certainly get things working like this in TX. Make the singleton register itself to receive ticks (you can set the engine to tick at whatever rate you want, I believe default is 30ms). Each object onscreen that wants to act as a ghost could have a component added to it, lets call it PhysicsGhostComponent (PGC for short). The PGC can use its init method to register it's owner as a ghost in the singleton and register its owner for ticks. From your example code above, the PhysicsSimulater.Update(1/60) becomes the ProcessTick of your singleton. The registering of the new RigidBody happens in your PGC init method. The updating of the sprite position/orientation happens in the ProcessTick of PGC.

I personally don't see the merit in design of having two objects in memory for every one object on screen, but if you are simply porting an existing physics system and that's how it works then it could be the easiest way. I would think it easier to have a single object in memory for every one object on screen and eliminate the singleton physics object and all the ghosting and just use the objects directly. I believe this is the way the TX physics system works. Each T2DPhysicsComponent is responsible for managing the physics for its owning object. Collisions are handled by a separate component, the T2DCollisionComponent. You may consider these to be linked in your physics system (as many do) but I like the separation in TX.

#5 Certainly after reading the Farseer documentation it seems like you could go either way. Without digging into your code, my first thought is to set up the singleton to do the broadphase check and the individual components to do everything else.

I can still see it working in the previous two discussed ways as well as this hybrid architecture.

#6 Thanks Ben, I think I get it now.

#7 Just to reiterate what Ben suggested, your Physics manager class can support the ITickObject interface, then just implement the InterpolateTick and ProcessTick methods within your class. When your class is instantiated, you can then call ProcessList.AddTickCallback to register with the ProcessList for tick events.