Sign in to follow this  
steg

Drawing game objects

Recommended Posts

steg    390
Hi everybody I was wondering how you guys actually render your whole game world ? I was thinking I should have something on the lines of a top level object which stores pointers to objects in the game ? For instance, if I have a couple of objects in my game, for simplicity say four cubes and 2 pyramids, now each of these objects has its own orientation and position in world space and each of these objects has a method to render itself. I'm thinking the best way of rendering all these is to have a top level object which has maybe a link list to all these objects, may be something like ( this is very simple ): class CObjectManager { int m_nObjectAmount; CVectorMap* m_pObects; }; Now CVectorMap is a dynamic template list, able to store any type of object, thus to add one : CCube* pCube = new CCube( 10, 100, 20 ); CObjectManager oObjectManager; oObjectManager.m_pObjects.Add( pCube ); Then rendering the objects : for( int i=0; i < oObjectManager.GetSize(); i++ ) { CShape* pShape = ( CShape* )oObjectManager.m_pObjects.Get(i); pShape->Render(); } CShape is an abstract class which all objects derive from. Does this same a good/bad way ? Any advice is very much appreciated. Kind regards, Steve

Share this post


Link to post
Share on other sites
steg    390
Thanks Arcibald,

I think it is good to have the objects draw themselves due to the abstractness of objects, one object may need to be drawn a different way than an other object. Just my thoughts ?

Kind regards,
Steve

Share this post


Link to post
Share on other sites
Toolmaker    967
I'm currently working on my 3rd game(and first with D3D9) in 2D. I currently use a scene manager which stores all (game)objects.

During my call to SceneManager->Update(fFrameTime) the scene manager tells all objects to update themself, checks them for collisions and then tells all objects to render themself.

To achieve this, I made an abstract top level class called CD3DObject. All objects that should be updated/drawn in a scene are derived from this object and stuffed into my scene manager.

Toolmaker

Share this post


Link to post
Share on other sites
steg    390
Thanks ToolMaker,

Looks like we are doing almost the same thing!

All my objects are also derived from a top level abstact class, this top level class has a couple of pure virtual functions in there such as Initialise, Render and also some common members. Each one of my objects therefore that are derived from this abstract class have to implement the pure virtual functions, one of them being Render :-)

Best regards,
Steve

Share this post


Link to post
Share on other sites
circlesoft    1178
Instead of your scene manager holding the meshes themselves, it may be a better idea for the scene manager to hold entities instead. Whereas meshes actually hold the vertex and index buffers, the entities just hold a reference to it's mesh. That way, you can render the same mesh multiple times per frame.

Like this:


class IEntity
{
D3DXVECTOR3 position;
D3DXVECTOR3 rotation;
IMesh* meshReference;

virtual void Update() = 0;
};

class CHumanEnemy : public IEntity
{
// Additional entity-specific values
float health;
float experience;

void Update(); // Do all your AI here
};


Then, when it comes time to render...
for( int i = 0; i < sceneManager->GetSize(); i++ )
{
IEntity* entity = sceneManager->GetEntity( i );
IMesh* mesh = entity->meshReference;

// Build/set the matrices
mesh->Render();
}


This really is a good system to follow, because you save a lot of memory, instead of duplicating it.

Share this post


Link to post
Share on other sites
EverIce    151
CircleSoft: I don't know surely that is a good idea to inheritate a game object from a render object.

Because the game object(CHumanEntity) can have an abstract physic class. I mean the game object can inheritate from physic object. I think the multiple inheritance not a good thing.
So my suggestion is containing:


class CHumanEntity
{
IEntity entity;
IPhysObj physObj;

float health;
float experience;

void Update(float pTime); // Do all your AI and Graph and Physic here
};

Share this post


Link to post
Share on other sites
Motorherp    613
Hi again. For full on performance and conservative memory usage you might want to consider the following for rendering. Since you seem to be handling basic primitive shapes why not have a unit size mesh for each shape type stored in a single vertex buffer in the manager to begin with. The offset to the beginning of each shape types' verts in the buffer as well as the number of verts they are made up off can be stored in an enum in the manager. Each instance of an object would then only contain its pos and scaling vectors, and orientation matrix. When you want to render an object you concatinate its pos, scaling, and orientation into a matrix which you pass to the D3D device SetTransform and tell the manager to render the verts in the vert buffer from that object types offset up to that object types number of verts plus the offset. Now here are the advantages:

-> Theres only one vertex buffer to lock hence better performance

-> The memory usage is kept very small

-> Since the total number of verts will be small it wont hurt not use an index buffer meaning you get another performance boost

This method can even be extended to arbitrary meshes for which you wish to have many instances of in game. However if you want many different unique meshes it starts to loose its appeal a bit. Hope this helps.

PS: I'm off to Scotland for a couple days so I appologise if it takes a while for me to respond to any replys

Share this post


Link to post
Share on other sites
steg    390
Thanks Motorherp,

I need to go through what you have said and try to understand it a little more!
I did get my ObjectManager written last night and it works a treat.

Do you have email address so I could PM you bud ?

Have a safe trip to Scotland!

Best wishes,
Steve

Share this post


Link to post
Share on other sites
Motorherp    613
You caught me just as I was about to leave. You should just be able to hit PM below my posts if you want to chat more in depth. I've PM'd you my email just incase anyway. Gotta go. Speak to you soon

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this