|
||||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic |
Last Thread Next Thread ![]() |
| Object Abstraction in OpenGL |
|
![]() Br1 Member since: 2/7/2002 From: Montevideo, Uruguay |
||||
|
|
||||
| I love the article. It really shows C++ shinning. Your designs wouldn't be possible in C# or Java. Eat dust! |
||||
|
||||
![]() Pipo DeClown Member since: 2/16/2002 From: Amsterdam, Netherlands |
||||
|
|
||||
| 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) |
||||
|
||||
![]() valoh Member since: 3/20/2003 |
||||
|
|
||||
| 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] |
||||
|
||||
![]() jamessharpe Member since: 1/6/2003 From: Bristol, United Kingdom |
||||
|
|
||||
quote: 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: 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: 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] |
||||
|
||||
All times are ET (US)![]() |
Last Thread Next Thread ![]() |
|