Jump to content
  • Advertisement
Sign in to follow this  
shwasasin

Separate Base/Derived Methods in a Class

This topic is 3001 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

Hey Everyone,
I was recently writing some code and came across this interesting problem (or at least I think it is). I have 2 mesh classes, one for immediate mode rendering data (base class), the second is for vbo rendering data (derived class). In my graphics manager I have a method called "Draw", which for the life of me I cannot remember if there is a way in C++ (VS2005) to allow for each type (base/derived) to have their own implementations.

I'm reluctant to add a virtual "Draw" method to each of my Mesh classes, but any suggestions to solve the problem are welcome.




Mesh* pMesh = new MeshVBO();
GM g;
g.Draw(pMesh);

class GM
{
public:
// This method always get hit.
virtual void Draw(Mesh*& m)
{
// draw immediate
}

virtual void Draw(MeshVBO*& m)
{
// draw vbo
}
};


Share this post


Link to post
Share on other sites
Advertisement
I disagree with the use of templates here.

I think the best solution, since it is a derived type anyway is to provide a DrawVbo(MeshVBO* m) function instead of trying to make a Draw() call that takes both types.

The problem with your implementation is that the compiler doesn't know which Draw() call to use since both are valid on a MeshVBO class (because of the inheritance).

Plus, since MeshVbo is a derived special type of a Mesh, using a special function for those types is not atypical.

Jeff.

Share this post


Link to post
Share on other sites
Quote:

That's how I would do it.

Really?

You didn't post a solution at all. You didn't say how you might determine the correct runtime type. You posted code that gives vague hints but falls miles short of doing anything useful.

Maybe next time you show someone how you would do it, post code that could work. Psuedo code is ok, as long as it demonstrates the technique.

Plus I think that your solution would be stupid regardless of how you recontruct the type, because there is 100% no reason to go all the way back to a raw void pointer for this, throwing away type safety for no possible benefit.



@ shwasasin
You've thrown away the type information by storing the base class, so you must either store it manually, or rely on how the compiler implements virtual functions.

However, I am curious as to why you plan to support both immediate and batched rendering - at runtime no less? Why support immediate mode at all, it is deprecated after all.

A simple approach would be to not derive MeshVBO from Mesh. You won't be able to choose at runtime, but again I question the necessity of this.

Share this post


Link to post
Share on other sites
Quote:
Original post by Zahlman
Are you perhaps looking for "double dispatch" (Google it)?


After performing some google-fu, I believe "double dispatch" or more precisely the Visitor Pattern is what I'm looking for, thanks!


------------
@rip-off:
- While VBO's are preferrable for optimal performance, I find it easier to use immediate mode for rapid prototyping of features (i.e. new particle effects, rendering collision volumes, etc..). It's definitely not put into production/ship code. When VBO's aren't supported on the hardware, alternate rendering methods such as vertex arrays, and display lists are used.


Thanks for the advice everyone.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!