Hi there...

weve posted about it, but its really just the nature of the engine. The way it works is that input sends an event to physics. But Im guessing you, like many of us, are compiling without physics enabled; This has the effect that objects dont move. The input keys, like 'w', dont directly effect the world objects; they actually effect the collision meshes attached to the 'actual' viewing meshes. The physics engine sync's up the position and orientation of the world objects when any of the collision meshes are updated via the input event system.

I hope 1) that this helps and 2) that any of the above is correct

-Stellar

This is slightly off topic and not in reference to the original question :

the code used in the book uses a style that Im really not used to, so I found it a bit difficult to grasp. But to put it in simpler terms.

World objects ( actually, just the collision meshes ) are controled via input events. Events are used to seperate each of the sub-systems. Events are kind of like global variables that contain a type ( so the target knows what to do ), and data for the type ( so the target knows how to modify an object ).
In a simple manner, you could do away with all the classes and just have a global list that stored a struct { int nType, CBaseData xData }. Where CBaseData is just a interface class so you can pass in whatever you want as data. Every system would have access to the list and could scroll thorugh as needed. This would be too simple for a real game, but it demonstrates the point that the overly complicated world of events is just a global type and data.

I have no idea why im posting this....
-Stellar

Im afraid that wont help too much. The physics chapter I belive touches on what the bare fundamentals of physics is, but it doesnt do anything in depth, as it should be. It concentrates on showing you how the authors library is tied into the 3rd party software. If you want to see teapotwars in action, you'll either have to plugin a different physics sdk ( ie Ode ), or youll have to implement your own. Ill be doing both. Its more practical to use a sdk, but I have this undying desire to understand how everything works, at the lowest level, in a game. To start off in my own demo tho, Ill just use a free sdk.
Some professional companies probably decide to create their own libraries because it can more easliy be integrated into their own software and tweeked. Also, I belive an sdk would have to replicate the data for the world objects, which causes memory and cpu overhead ( I may be wrong about this ). But it would be easy to just pass your world object list to the physics engine without having to do any translations/conversions.

The collision models of your models are not the same. A collision model is only an approximation of the real model. So it doesn't matter if you use an SDK or your own physics library, because you have not the time to do all those calculations with your fully detailed models.

Why don't you just install the physx sdk? It's free for non-profit use.

Last I checked, the physx library went big and is no longer free but very expensive ( even supports its own accellerated card ). Am I wrong?

if anyone does have a free 'older' version, could you post it so we can grab a copy to build the program with? thx.

I downloaded it some weeks ago SDK Version 2.3.3 which is free for non-profit use. And yes it can use an accelerator card, but also has a software mode.
If you make a game which uses physx so heavily that you can run it only with this card you get your license for free, too.

To get the sdk, go to devsupport.ageia.com click on "sign in" and create a new account. After creation sign in and you can enter the download section through the "online support tab" and there is a link called "downloads" (directly under the "online support" text). And then to your left there are the different sdk versions listed.


And you can improve the event data casting by changing the get function from

into


The boost::polymorphic_downcast uses in debug build dynamic_cast and throws an exception when you cast the IEventData to an invalid derived class.
And in release builds it uses a static_cast.

An even better methode is:

In debug build this code checks if the conversion is valid (you could use the dynamic_cast too, but then dynamic_cast throws only when you use a reference and I this is therefore shorter).
But the real improvement is that this version won't break the reference count and there is no possible error because of invalid data (although it is unlikely that you will store IEventData packages in an event handler, but one can never know).