How autoremove body??

Marioko

05-10-2006 03:34:09

Hi.. its me again.... :P

How can i set OgreNewt to auto delete or remove of the screen and world, the olds bodies???

for example, if i will have game with a rifle shotting, then the bullets are remove when the time pass.

----------------------

Sorry for my english my friend... :roll:

HexiDave

05-10-2006 04:44:28

Well, you have to delete your own bodies if you want them dead before program termination, otherwise you have to wait for the program do die and the Newton world kills them.

Store them in a vector<OgreNewt::Body*> or something and destroy them as you need to.

Marioko

05-10-2006 22:27:28

ok... but how can destroy it, include mesh...??

HexiDave

06-10-2006 01:00:11

If you use that vector<> you could do something as simple as a loop (this is if you're not going to delete a body right after you're done with it and you want to garbage-collect on a regular basis for "junk"):

vector<OgreNewt::Body*> mBodies;
...

mBodies.pushback(body);

...

for(int i=0;i<mBodies.size();i++){
OgreNewt::Body* mVectorBody = mBodies[i];
if(mVectorBody){
delete mVectorBody;
mVectorBody=0;
}
}
mBodies.clear();


Pretty straight forward code.

Marioko

06-10-2006 05:28:00

ok, thanks.. i going try that :D

OvermindDL1

09-10-2006 18:52:29

If you do want Actor's to properly clean themselves upon their death, I'd recommend doing what I do. I have a base Actor class that all in-game objects inherit from. It does initial body setup, mesh, etc... etc... based on settings from the derived class. I only pass things around using ActorPtr's, not Actor*'s. ActorPtr is a smart pointer. When the object is in-game and alive then it is always has at least two references active, one in the Level it belongs to, and one that it holds of itself. When one needs to be removed from the game world (whether dead, level end, etc...), then the method Destroy() is called on it, which clears the mesh, texture, collision, etc... instances, resets the internal smart pointer to null, and tells the Level that it was deleted. The Level then can do things such as reset the smart pointer that it holds of that object, or it may keep it around for later access or what-not. There may be other objects that have a hold on a smart pointer for that object, and while at least one smart pointer exists, the instance itself is not deleted (so no access violations can occur). Classes are supposed to hold weak pointers to the smart pointers for an object if they want to keep a hold on it but not actually increment the reference count as you have to extract a smart pointer from the weak pointer to use it, and it will return an empty smart pointer if the object has since been deleted. If you get a good setup for your classes, then programming more things, making changes, etc... is vastly simplified and it takes away almost all of the hassle of managing mundane things. (Not to mention that the smart pointers make a *wonderful* interaction with Python as a scripting engine).