Sprite implies animation, which is not what your sprite class does. A camera isn''t a sprite, but it is a node in the scene graph, which is what your sprite class appears to actually represent.

Starting with one pure virtual base class is the SI mindset; it''s not necessary with MI. A common base interface is often useful, but all the other interfaces don''t need to derive from it.

Several commercial engines use a virual render function that is called for objects such as (a real) CSprite, CTerrain, etc...

Doesn''t anyone remeber the "Is A", "Has A" relationship lecture from the early college programming classes.

A Car "has" 4 tires.. so it doesn''t make sense to inherit a tires class from car class. The Car Class should contain 4 "tire" class objects.

A car "is" an automobile so is a truck, or an RV. So it makes sence to inherit a "Car" class from an "automobile" class.

quote:Original post by Ironside
A car "is" an automobile so is a truck, or an RV. So it makes sence to inherit a "Car" class from an "automobile" class.

So does an automobile have 4 tires?

I''m waiting on the "Is a"/"Has a" lecture when I do my first OOP unit this coming semester, but wouldn''t an Automobile have -no- tires, and you''d leave it up to the derived classes to decide how many tire classes they''d include?

I was aware that i screwed up the Is-A relationships pretty badly, and the naming as well. It was a 2 hour long experiment in high levels of inheritance, to see just what the result would be. It was terrible.

Ive been doing research in interfacing and seeing what type of interface and setup works best. When that''s totally done, I''ll put all the code into a nice format.

The relationships are going to stand at CObject-CSprite-[Specific Object] i think. THe camera class is going to rotate and move somewhat differently from world sprites. Each camera will store it''s own matrix. The pipeline class will have an internal pointer to the camera that is to be used, and use it''s matrix for the view transform. The pipeline will also manage the top of the my frame-based hierarchy, and will allow direct access to the hierarchy if one needs it. There''ll be a mesh class in Specific object, which will probaly manage either a CD3DMesh(part of DX Common files), or directly deal with an ID3DXMesh. Not totally sure yet. Or i could use a union. But so theres the general break down.

Comments?

-----------------------------
The sad thing about artificial intelligence is that it lacks artifice and therefore intelligence.