Advertisement

Storing Object Data

Started by January 10, 2004 11:37 AM
5 comments, last by SkinnyM 21 years, 1 month ago
Hello, I have been thinking about this for awhile now, what i am trying to plan is how i am going to store my objects inside my engine. My orignal plan was to use a link list and every frame, have the link list go through and update all the objects. The problem i have been running into is, i want to be able to name my objects like CTerrain, and CModel and things like that, but in the link list, it wouldnt know if what is being passed in is CTerrain or CModel, so what i was thinking was to have a base class with 3 virtual functions in it, called CObject. (Initalize, Update, and Exit are the virtual functions) and then each object is derived from that base class. And in the link list, i would have CObject *Object; and then when i pass in the object, i would cast it to a CObject type. So the link list doesnt need to know what kind of object each of them is, it will just call the 3 virtual functions replaced by the upper class. Because they are always the same for each object. Do you guys think that would work? Or do you have any other ideas which could make this whole process alot easier. Also, do any of you have any idea on how to store the actual data for my objects, the program would get really messy if i had had CTerrain Terrain; and CModel Orgo; everywhere as global varibles. Do any of you have any ideas how i can store these, because in the link list, it is really onnly storing the object of the class.. Thanks for the help "What we do in life, echos in eternity" -- Gladiator
"What we do in life, echos in eternity" -- Gladiator
Yes, you should create a virtual base class, that sould have 3 virtual entries. Bit you do not need an init and exit function. The constructor and destructos is for this purpose (they are to keep data integrity, and maintain the type invariants of your object). The other rhing is that you do not have to cast it to the actual type. The first problem is that you dont know, to what type you have to cast, the second is, you dont have to. Vith te virtual byse class, you declare the needed functionality, but hide the actual implementation from your system. So your virtual base class should be:

class CObject
{
public:
CObject(){};
virtual int Render(){};
}

I dont know what do you mean under your second problem. Your linked list should look:

class LinkedNode
{
private:
LinkedNode next;
CObject *Data;
public:
LinkedNode();
LinkedNode Next();
CObject GetData(); //mybe a "void Render(){Data->Render()}" instead
...
}
"Knowledge is no more expensive than ignorance, and at least as satisfying." -Barrin
Advertisement
So what you are saying is that i dont have to cast it at all, C++ will automatically figure out what functions the base class has and what functions the class coming in share, and then it just uses those, so you dont have to type cast right?

So i could do:

class CObject
{
public:
virtual void Render();
private:
int Nada;
};

class CTerrain : public CObject
{
public:
void Render();
void DoSomething();
private:
};

class CLink
{
public:
CLink *Next;
CObject *Object;

void PassInObject(CObject *Object1);
void RenderAllNodes();
private:
};


then i could do

CTerrain Terrain;

CLink Link;

Link.PassInObject(Terrain);

and then all i would have to do is call RenderAllNodes(); each frame and that would call the Render() function from terrain. Is it that simple?

Thanks alot



"What we do in life, echos in eternity" -- Gladiator
"What we do in life, echos in eternity" -- Gladiator
Can you guys tell me if everything in my last post will work?

Thanks
"What we do in life, echos in eternity" -- Gladiator
SkinnyM,

I haven''t looked at your idea that closely, but it appears it would work.
Here is what I would do instead, though (in p-code):

class Scene{   std::list<WorldObject*> objects;   void Render()   {      for(std::list<WorldObject*>::iterator i = objects.begin(); i!= objects.end(); ++i)         (*i)->Render();   }   void Update()   {      for(std::list<WorldObject*>::iterator i = objects.begin(); i!= objects.end(); ++i)         (*i)->Update();   }};class WorldObject{   virtual void Update(float timeelapsed) = 0;   virtual void Render() = 0;} 


And then for each type of object you want:

class Terrain{   void Update(float timee){...}   void Render(){...}}class Bullet{   void Update(float timee){...}   void Render(){...}}... 


You can add objects like this:
Scene scene;scene.objects.push_back(new Terrain());scene.objects.push_back(new Bullet()); 


Then every frame just call Update and Render and your scene instance.
I have found that for the tiny, if any, frame rate gain from using a custom linked list it is not worth the effort compared to using a simple std::list.
Correction to my prevoius (anonymous) post:

Terrain and Bullet should be defined like this:
class Terrain : WorldObject {...};class Bullet : WorldObject {...}; 
Advertisement
dont confuse skinnym! he needs only to understand polymorphism! yes skinnym, you are right. you create the list with the base class (that is actually abstract, contains no implementations), and then use your specific objects, which inherit the "mother class''s" functionality. So you list will se something that can be Rendere()-ed or Update()-ed. It doesnt care about the real object, standing behind it. Of course you wont be able to reach those methods and properties, that was not part of the basic object.
So the final answer is YES! It is that simple!
"Knowledge is no more expensive than ignorance, and at least as satisfying." -Barrin

This topic is closed to new replies.

Advertisement