Archived

This topic is now archived and is closed to further replies.

graphics engine design

This topic is 5116 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I''ve been looking through some engine source, such as the OGRE engine, and I''ve come up with a design that I want feedback for: Each object in the world is represented by an instance of an Object class, and each object has a unique ObjectID to identify it. When the rendering class renders each object, it renders a mesh or a billboard etc based on the object''s position and ID. What I''m stuck on is how to deal with the ObjectIDs: should there be a (limited) preset of IDs, or should they be entirely created at runtime? Anyway, I was just looking for some feedback on my design. Do you see any flaws, or better ways to do something?

Share this post


Link to post
Share on other sites
I dont know if this will help you, but I use a simple RTTI
solution in my engine. RTTI or run time type information
is nothing more then a enum...

enum OBJECT_RTTI
{
EOR_DEFAULT=0,
EOR_TERRAIN,
EOR_PARTICEL
etc
};


and then a virtual function in the object base class:
virtual void SetRTTI(OBJECT_RTTI pType);
OBJECT_RTTI GetRTTI()...

The purpose for rtti is for other objects to know what there
dealing with. Pseudo:

if(*this collides with that) //say this points to a bullet obj
if(that.rtti = metalwall)
PlaySound(metalcollision)
LeaveDecal()

Hope that helps you.

Share this post


Link to post
Share on other sites
Sounds totally abstract. Personally, I wouldnt base engine design off of "ogre". Its not an actual game engine, its a "graphics rendering engine".

I suggest you go with the efficient entity design. You have a base class from which all interactive world objects (weapons, players, monsters, items, etc) inherit from. This base defines the standard properties that are common to most objects along with a set of standard virtual interface functions.

For the rendering, you have two options. Either you have a Draw() or Render() method defined for all of them, which allows each object to define how it will be rendered, or you simply have some default rendering method for all. You might want, for example, to assign each entity a model, in the form of a mesh, or some other kind of rendering object, such as a 2D sprite.



Looking for a serious game project?
www.xgameproject.com

Share this post


Link to post
Share on other sites
actually, you can pretty much pass the RTTI system using pointers and virtual functions.
Say you have a base class OBJECT, and several other classes that all inherit OBJECT. You can actually use a:

vector <OBJECT *> obj_list;
ITEM *itm = new Item(); //both use OBJECt as base class

WEAPON *wep = new wep();
obj_list.push_back(itm);
obj_list.push_back(wep);
//The following will work fine, regardless of Weapon, or Item

obj_list[i]->Collision();


Don''t need any state machine checking the type of an object, nor type casting to get the correct data back out, everything is done without extra boolean statements.
Works mighty fine.
~Main

==
Colt "MainRoach" McAnlis
Programmer
www.badheat.com/sinewave

Share this post


Link to post
Share on other sites
DuhRoach, I understand what you said, but doing it that way you
can only use data such as velocity, collision type, etc to get a proper interaction with the object. The only way that would work
is if you coded every object type staticly. (ie. a bullet hits a wall and leaves a black mark, a bullet hits flesh and leaves a
black mark, in order to leave the proper decal on the object the bullets hitting you still need a flag that sets surface type which in essence is rtti.)



[edited by - no one on December 14, 2003 12:23:46 PM]

Share this post


Link to post
Share on other sites
you can make the interface a little more complex so that a metal wall knows that a different effect should be made when it is hit with a bullet than a flesh object.

im thinking something like CObject::TakeBulletImpact(CObject *pImpactor)

and this func is called by the bullet, or other collidable thing that leaves marks, in its routine CObject::HitObject(CObject *pTarget)....

an example of how this could be better is, say

CWoodenWall::TakeBulletImpact(CObject *pImpactor)
{
PlaySound(''bullet_wood.foo'');
MakeSplinterEffects(pImpactor->Location, pImpactor->Velocity);
}

CMetalWall::TakeBulletImpact(CObject *pImpactor)
{
PlaySound(''bullet_ricochet.foo'');
pImpactor->Ricochet(this->NormalAt(pImpactor->Location));
MakeRicochetEffects(pImpactor->Location, pImpactor->Velocity);
}


CBullet::HitObject(CObject *pTarget)
{
pTarget->TakeBulletImpact(this);
}

CRocket::HitObject(CObject *pTarget)
{
pTarget->TakeExplosiveImpact(this); //makes scorch mark and explosion instead...
}

all in all, i say let virtual funcs handle the whole thing!!

Chris

Share this post


Link to post
Share on other sites