Which is the better way to draw?

g4j31a5 · 01-17-2007, 01:00 AM

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.

**Bubba** · 01-17-2007, 05:26 AM

I really have no idea what you are talking about.

psychopath · 01-17-2007, 05:27 AM

Quote:

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.

Perspective · 01-17-2007, 10:42 AM

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

Nodtveidt · 01-17-2007, 08:34 PM

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.

g4j31a5 · 01-18-2007, 01:00 AM

@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.

**Bubba** · 01-18-2007, 01:22 AM

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

g4j31a5 · 01-18-2007, 01:45 AM

Quote:

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.

ahluka · 01-18-2007, 02:14 AM

Eww.

Sang-drax · 01-18-2007, 04:21 AM

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.

Perspective · 01-18-2007, 10:23 AM

>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.

Tonto · 01-18-2007, 10:30 AM

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.

Perspective · 01-18-2007, 11:33 AM

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

anon · 01-18-2007, 11:46 AM

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.

Tonto · 01-18-2007, 12:06 PM

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.

01-17-2007, 05:26 AM	#2
Bubba Super Moderator Join Date: Aug 2001 Posts: 7,470	I really have no idea what you are talking about.
Bubba is offline

01-17-2007, 10:42 AM	#4
Perspective Crazy Fool Join Date: Jan 2003 Location: Canada Posts: 2,588	I'd take good, extensible design over a minor increase in performance.. but thats just me. __________________ jeff.bagu.org - Terrain rendering and other random stuff
Perspective is offline

01-17-2007, 08:34 PM	#5
Nodtveidt Insane Game Developer Join Date: Nov 2006 Location: Isabela, PR Posts: 105	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. __________________ Code: cout << "Language comparisons are dumb"; echo("Language comparisons are dumb"); PRINT "Language comparisons are dumb" alert ("Language comparisons are dumb")
Nodtveidt is offline

01-18-2007, 01:00 AM	#6
g4j31a5 In the Land of Diddly-Doo Join Date: Jul 2006 Posts: 373	@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. __________________ ERROR: Brain not found. Please insert a new brain! “Do nothing which is of no use.” - Miyamoto Musashi.
g4j31a5 is offline

01-18-2007, 01:22 AM	#7
Bubba Super Moderator Join Date: Aug 2001 Posts: 7,470	At current speeds I doubt even a 1000 virtual calls will cost you 2 frames.
Bubba is offline

01-18-2007, 02:14 AM	#9
ahluka Supermassive black hole Join Date: Jul 2005 Location: South Wales, UK Posts: 1,709	Eww. __________________ Good class architecture is not like a Swiss Army Knife; it should be more like a well balanced throwing knife. - Mike McShaffry
ahluka is offline

01-18-2007, 04:21 AM	#10
Sang-drax and the hat of marbles Join Date: May 2002 Location: Göteborg, Sweden Posts: 2,038	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. __________________ Last edited by Sang-drax : Tomorrow at 02:21 AM. Reason: Time travelling
Sang-drax is offline

01-18-2007, 10:23 AM	#11
Perspective Crazy Fool Join Date: Jan 2003 Location: Canada Posts: 2,588	>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. __________________ jeff.bagu.org - Terrain rendering and other random stuff
Perspective is offline

01-18-2007, 10:30 AM	#12
Tonto Registered User Join Date: Jun 2005 Location: New York Posts: 1,465	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. __________________ ╔╗╔╦══╦╗╔╦══╦╗ ║╚╝║╔╗║╚╝║╔╗║║ ║╔╗║╠╣║╔╗║╠╣╠╣ ╚╝╚╩╝╚╩╝╚╩╝╚╩╝ codez http://code.google.com/p/zxcvbn/
Tonto is offline

01-18-2007, 11:33 AM	#13
Perspective Crazy Fool Join Date: Jan 2003 Location: Canada Posts: 2,588	With all the other stuff going on in a game engine, a series of constant time lookups are the least of your worries. __________________ jeff.bagu.org - Terrain rendering and other random stuff
Perspective is offline

01-18-2007, 11:46 AM	#14
anon The larch Join Date: May 2006 Posts: 3,082	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.
anon is offline

01-18-2007, 12:06 PM	#15
Tonto Registered User Join Date: Jun 2005 Location: New York Posts: 1,465	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. __________________ ╔╗╔╦══╦╗╔╦══╦╗ ║╚╝║╔╗║╚╝║╔╗║║ ║╔╗║╠╣║╔╗║╠╣╠╣ ╚╝╚╩╝╚╩╝╚╩╝╚╩╝ codez http://code.google.com/p/zxcvbn/
Tonto is offline

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
draw function HELP!!!	sunoflight77	C++ Programming	1	05-10-2005 11:28 PM
ray casting	lambs4	Game Programming	62	01-09-2003 06:57 PM
draw to a BITMAP* argument - allegro and objects again	MadHatter	Game Programming	13	12-13-2002 06:51 AM
Draw Shapes.	Unregistered	C Programming	1	08-19-2002 09:22 AM
Transparent Draw Question	GodLike	Windows Programming	5	05-07-2002 06:56 AM