Criticise my proposed rendering method

So I was thinking about this:

Basically I'll have a class, CRenderClass, that looks something like this:

Code:

---

class CRenderTask
{
public:
    virtual void Draw() = 0;
};

---

My little rendering system will keep a (std:: )list of these which it will iterate, calling the Draw() function on each one.

BUT, this means for everything I want to render I'll have to derive a class from this class. Is there a more manageable but similar approach?

Yes, this is the first time I've written a renderererer.

Oh yeah:

SDL. For the Nth time: DirectX can rot until I get some books. Yes books, I mean you.

I don't see a particular reason why DirectX is better than OpenGL, Since SDL allready uses OpenGL, just learn GL.

I've learnt enough OpenGL, I just want to use SDL. I didn't mean to compare DirectX and OpenGL.

Allright, i'm sorry for bringing that up ... now a new GL vs DirectX war will begin...

I think one virtual lookup per rendered object isn't a big deal.

You could also have your rendering system store a list of functions pointers and have each object register it's rendering function with the rendering system.

Quote:

---

Originally Posted by Quantum1024

I think one virtual lookup per rendered object isn't a big deal.

You could also have your rendering system store a list of functions pointers and have each object register it's rendering function with the rendering system.

---

Sounds like a plan. I'll use this thread to post any probs - I bet y'all can't wait.

Are you gonna use it like this, 'cause that seems fine.

Code:

---

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

class tile : public render
{
      ....
      void draw()
      {
          ...
      }
};

class something : public render
{
      ...
};

---

Function pointers = bad idea.

Try it.

yes, turns out they would be pointless in this case since a function pointer to a virtual member function dose a virtual lookup anyway.

Yeah that kinda went... wrong. Methinks I need to rethink this.
EDIT: Not only didn't the function pointer not work, the performance was terrible.

LOL sorry for sugesting that it seamed like a good idea at the time. Just stick with your origional idea.

Well, to note one major thing.

MOST (not all) geometry should be drawn in virtually the SAME way!

There are only a couple things you should have different drawing methods for...

Models: (make all models subscribe to a vertex array or something similar format)

Terrain: (Might be same as above, but use triangle_fans for this guy, it would be faster!)

Thats all I can think of that is really different...

So then you're only deriving two classes from that main drawing class! Imagine that!

If you can keep everything virtually the same (in terms of drawing methods) you'll have an instantly relatively cleaned up renderer!

Virtual functions are function pointers.

I use a similar method, in that there's a different rendering method per renderable type, but I don't use any Object Oriented programming to do it.

I also don't implement shaders or any spectacular rendering effects...

I completely agree with the plan to make some sort of a empty base class for tieing all of your renderable objects together, but you may want to add more than just draw() to it so that next time you want to relate all this data for something you dont need to make another class, put every thing you think you will need in that class, which may or may not be more than just draw(). Just think ahead i guess on what other properties a renderable object may need, mabe its distance from the camera, mabe a boolean value that tell if it needs to be rendered or not, ect.

Ok guys I'll give it some more thought.