Home » Community » Forums » » Object Abstraction in OpenGL
  Intel sponsors gamedev.net search:   
[Control Panel] [Register] [Bookmarks] [Who's Online] [Active Topics] [Stats] [FAQ] [Search]

Add Forum to Favorites |  Send Topic To a Friend | View Forum FAQ | Track this topic


 Last Thread Next Thread 
 Object Abstraction in OpenGL
Post Reply 
I love the article. It really shows C++ shinning. Your designs wouldn't be possible in C# or Java. Eat dust!

 User Rating: 1022   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

Interesting use of inheritance. Nice read, thanks.

--
You're Welcome,
Rick Wong
- Google | Google for GameDev.net | GameDev.net's DirectX FAQ. (not as cool as the Graphics and Theory FAQ)


 User Rating: 1469   |  Rate This User  Send Private MessageView ProfileView Journal Report this Post to a Moderator | Link

mhh, I really like c++ and templates, but I think there is just a little to much templates without a benefit in your design.

The
template <GLenum TextureT> class OGLTextureImpl
{
//generation, deletion and binding here

}
//

template <GLenum ProgramT> class OGLProgramImpl
{
//generation, deletion and binding here

}

approach makes sense, because you really save code. For the Object template I don't see a reason to use that. Where do you save code? All the code you save at the first view, you have to type for the policy class. Imo you can then better leave out the Object base class and only use the templates for classes with same creation and deletion but different GLenums.

Also an interesting trick with the "delegation to a sister class", but I probably would prefer a design without multiple/virtual inheritance.
As far as I know you have always a runtime overhead with virtual inheritance. And for what do you need the GLTexture class?

Would something like
template <GLenum TextureT, typename BaseT> OGLTextureImpl :
    public BaseT
{
   OGLTextureImpl() {glGenTextures(1, m_id);}
   ~OGLTextureImpl() {glDeleteTextures(1, m_id);}

   virtual void bind() {
      glBindTexture(TextureT, m_id)
   }
   private:
      GLuint m_id;
}

class Texture {
   //..

   virtual void bind()=0;
};

class Texture2D : public Texture {
//..

};

class OGLTexture2D : public OGLTextureImpl<GL_TEXTURE_2D, Texture2D>
{
// here other ogl 2d texture stuff

};

have any disadvantage over your design?

[edited by - valoh on May 29, 2004 6:37:07 PM]

 User Rating: 1015   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

quote:
Original post by valoh
For the Object template I don't see a reason to use that. Where do you save code? All the code you save at the first view, you have to type for the policy class. Imo you can then better leave out the Object base class and only use the templates for classes with same creation and deletion but different GLenums.



Yes I take your point about the GLObject class, I suppose you could alternatively create a base class for the policy with the virtual functions required for each of the ops. I suppose my thinking was that I wanted to enforce the programmer to implement each of the functions that were needed - my method will cause compile time errors if the required functions aren't implemented, since they are guarenteed to be called - I'm basically minimising the number of things that need to be called explicitly by the programmer. There's so many different approaches you could take, I suppose it just boils down to which syntax you feel more comfortable with.

quote:

Also an interesting trick with the "delegation to a sister class", but I probably would prefer a design without multiple/virtual inheritance.
As far as I know you have always a runtime overhead with virtual inheritance.



Yes you do get some overhead from virtual inheritance its the same as with virtual functions - it amounts to an extra pointer dereference and the memory required for the vtable. The virtual inheritance is there to solve the diamond inheritance problem i.e. to prevent two instances of the base class in memory.

quote:

And for what do you need the GLTexture class?



The reason I've designed it this way is that my texture manager can then hold pointers to GLTexture classes instead of Texture classes, and thus expose the extra functionality specific to GLTextures that don't exist in the general texture interface. This also enables a very clean interface to the outside world - all they ever see is Texture pointers. There's nothing wrong with your design either, you've just chosen to derive by Texture Type first and then API, I currently use the opposite, although I can see advantages in deriving by type first, especially in writing the texture manager - I hadn't thought about that.

If I was being totally critical of the design you suggested, I'd argue that a OGLTextureImpl doesn't reflect the IS-A idiom of inheritance, whereas my method is using the Impl class purely for the implementation hence the use of private inheritance. Of course there's nothing really wrong about this as long as the user of the code knows that they shouldn't try to use OGLTextureImpl pointers, although there wouldn't be any harm in that either.

James



[edited by - jamessharpe on May 30, 2004 11:04:01 AM]

 User Rating: 1263   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

All times are ET (US)

Post Reply
 Last Thread Next Thread 
Forum Rules:
You may not post new threads
You may post replies
You may not edit your posts
You may not use HTML in your posts
Jump To:
Administrative Options: