Quote:Original post by Zahlman
Whenever you call a non-virtual member function through a pointer or reference to the base class, the base class version of the function is called, not the derived one. The destructor is a member function; therefore, whenever you call 'delete' on a pointer to the base class, and the destructor of the base class is not virtual, the base class version is called. That's bad, because if the pointer actually points to a derived instance (and the ability to do that is what motivated you in the first place), then the program will try to clean up a derived instance as if it were a base instance. Note: this does not simply clean up the base part of the class and leave the derived part alone. It is explicitly undefined behaviour.

Quote:Original post by PezMutanT
- Reading the ID3DXSprite reference, it mention something about a list of batched sprites, like here:

"ID3DXSprite::Draw Adds a sprite to the list of batched sprites."

I don't understand how I should manage that list and if I could access every element of it (because every element would be a different sprite). Is it related with the AddRef() and Release() functions?

ID3DXSprite::Draw(x, y, w, h) // Whatever the parameters are{   add_4_vertices_to_vertex_buffer(x, y, w, h);   add_4_indices_to_index_buffer(x, y, w, h);   m_numSprites++;}ID3DXSprite::Flush(){   set_vb_and_ib();   m_pDevice->DrawIndexedPrimitive(blah, foo, m_numSprites*2);   m_numSprites = 0;}ID3DXSprite::End(){   Flush();}

Quote:Original post by Zahlman

Quote:Original post by PezMutanT
- Why a virtual destructor? If I only have one destructor in the parent class, shouldn't it be enough?

Whenever you call a non-virtual member function through a pointer or reference to the base class, the base class version of the function is called, not the derived one. The destructor is a member function; therefore, whenever you call 'delete' on a pointer to the base class, and the destructor of the base class is not virtual, the base class version is called.

Quote:Original post by PezMutanT
So I suppose I only have to keep a list (for example a vector) of references (pointers to my own Sprite class and/or its derived ones) to the different sprites in the game just to interact with them (for example killing one of them or moving one of them along the window), right?

Quote:Original post by PezMutanT
I took a look at your journal, that's great stuff man! How can I access to it directly from the home page of gamedev.net?)

Quote:Original post by PezMutanT
Ok, I think I get the idea. Every tick I have to call the Update() function in every element of the vector (every sprite), and every render tick I have to call the Render() function in every element of the vector. And this Render() function would have one call to ID3DXSprite::Draw() in order to add that sprite to the batched list of sprites, of course between Begin() and End() functions. Is this right?

That "update ticks different from render ticks" thing... I hope being able to manage it...

Thanks again Evil Steve! ;)

class GameObject{public:   GameObject() {}   virtual ~GameObject() {}   virtual void Update() = 0;   virtual void Render() = 0;   // Any other info you may want such as bounding spheres for culling,   // object names for debugging, etc};class Sprite : public GameObject{public:   // Various Sprite() member functions here   virtual void Update() { /* Do update code */ }   virtual void Render() { /* Do render code */ }};// Elsewhere:std::vector<GameObject*> m_sceneGraph;// Add some objects:m_sceneGraph.push_back(new Fire(...));m_sceneGraph.push_back(new Fire(...));m_sceneGraph.push_back(new Fire(...));// And then your main loop would be something like:for(size_t i=0; i<m_sceneGraph.size(); ++i){   m_sceneGraph->Update();   m_sceneGraph->Render();}