Which is the better way to draw?

Hi, I've got a simple question. I have 2 ways to draw objects that I can think of but I didn't know which one is better.

1. Use an abstract class Renderable for the parent of the objects and have an std::vector of the Renderable class and call an overloaded virtual function to draw.

E.g:

Code:

class Renderable
{
  public:
       virtual void draw()=0;
}

Code:

class MovableObject:public Renderable
{
 public:
        void draw()
        {
        }
 .........
}

class TerrainObject:public Renderable
{
 public:
        void draw()
        {
        }
  ........
}

class OverlayObject:public Renderable
{
 public:
        void draw()
        {
        }
  ...........
}
etc...

Code:

std::vector <Renderable *> mRenderable
...
mRenderable.push_back(new MovableObject() );
mRenderable.push_back(new TerrainObject() );
mRenderable.push_back(new OverlayObject() );

//Main loop
  while (!done)
  {
      ..............
      for (std::vector <Renderable *>::iterator itr=mRenderable.begin();
          itr!=mRenderable.end();
          itr++) 
       {
             (*itr)->draw();
       }
       
   }
........

2. Not using any inheritance and making the respective objects's vectors for drawing
e.g.:

Code:

class MovableObject
{
 public:
        void draw()
        {
        }
 .........
}

class TerrainObject
{
 public:
        void draw()
        {
        }
  ........
}

class OverlayObject
{
 public:
        void draw()
        {
        }
  ...........
}
etc...

Code:

std::vector <MovableObject *> mMovables
std::vector <TerrainObject *> mTerrains
std::vector <OverlayObject *> mOverlays
...
mMovables.push_back(new MovableObject() );
mTerrains.push_back(new TerrainObject() );
mOverlays.push_back(new OverlayObject() );

//Main loop
  while (!done)
  {
      ..............
      //Movables
      for (std::vector <MovableObject *>::iterator itr=mMovables.begin();
          itr!=mMovables.end();
          itr++) 
       {
             (*itr)->draw();
       }

      //Terrains
      for (std::vector <TerrainObject *>::iterator itr=mTerrains.begin();
          itr!=mTerrains.end();
          itr++) 
       {
             (*itr)->draw();
       }

      //Overlays
      for (std::vector <OverlayObject *>::iterator itr=mOverlays.begin();
          itr!=mOverlays.end();
          itr++) 
       {
             (*itr)->draw();
       }
       
   }
........

The question is which is better? I understand that using virtual calls can very much affect the performance. But how slow will it be?

Thanks in advance.

I really have no idea what you are talking about.

Originally Posted by g4j31a5

I understand that using virtual calls can very much affect the performance.

Really? I don't see how. I use them all the time, and I've yet to see a noticable performace hit.

I'd take good, extensible design over a minor increase in performance.. but thats just me.

Depends on your plans for the game engine. If you plan to reuse the engine for other games, go for a more flexible method. But if the various data in your game is specific to this one game, and you have no need for flexibility, the seemingly "minor" performance increases will add up and you'll get better results. Remember, the players don't care how the game was coded, they care how the game plays.

@Bubba

Well, basically the question is whether I should use inheritance or not. Because I understand that virtual calls have a slight performance decrease. So I was just wondering whether it's appropriate to use virtual calls for a method that always be called every loop (e.g. drawing) in lots of objects.

@All

Actually my current method is the second one. I created lots of category of renderable objects independently. And in the class that handles the scene (I called it SceneManager), there's a vector for each category (e.g. MovableObjects vector, TerrainObjects vector, etc) and iterated each vector for drawing every loop. But after I give it some more thought, wouldn't it be better to use inheritance and virtual calls to draw.

I still hesitated to change the design though because I was afraid that the performance drawback of the virtual calls will be quite huge. FYI, I'm developing for a very low spec machine so I don't need any more performance drop because it's quite slow as it is right now.

At current speeds I doubt even a 1000 virtual calls will cost you 2 frames.

Originally Posted by Bubba

At current speeds I doubt even a 1000 virtual calls will cost you 2 frames.

It will if the processor is 400 MHz. BTW, that's the machine I'm developing to.

Eww.

Go for the first alternative. Virtual calls are neglible.

Also, you should use a std::list instead of a vector, because you'd probably want to remove objects not being used anymore.

>the seemingly "minor" performance increases will add up and you'll get better results.

I don't mean to sound rude but, no, no it won't. You won't see any (statistically significant) measurable performance increase that can be attributed specifically to using virtual functions.

I think he was suggesting that you'd get better performance not using virtual functions (he said if you don't need flexibility [polymorphic design] don't have it). I would venture to say that function pointer + call from vtbl cost of the virtual function is inconsequential in the grand scheme of things, but maybe the little things do add up, but I honestly don't know.

With all the other stuff going on in a game engine, a series of constant time lookups are the least of your worries.

You can do some testing with both?

But honestly, are you sure that the rest of the program will perform optimally? Are you sure that you don't waste time detecting collision between objects that have no way of colliding, for example? Are you sure that your pathfinding algorithm doesn't consider some really crooked ways?

If a program is slow, it is usually because a) it does enormous amounts of work and it's unreasonable to expect it to be any faster; b) the algorithms are implemented poorly - all your efforts to gain microseconds are useless if you use bubble-sort on a large array or do something that is algorithmically equally suboptimal.

I see that questions about micro-optimisations are asked often, but never is any real code provided, so we could see if there's even any point discussing them.

I think it's just more of a general question that would come up while designing base code, anon. I mean, if you implemented awesome algorithms and such, but then found that polymorphism killed performance and you wanted to redesign things, it would take forever. But luckily, the consensus seems to be that such will not be the case for the OP.