Base Texture -> (derived) OpenGLTexture
(derived) D3DTexture

then use a factory pattern to get the right one for your engine. In your base texture you want stuff like filename, if is selected by the API etc.

The derived versions have the actual API implementations for loading the texture to video memory, selecting with the API and such.

You might also want a special texture loading class. Instead of loading the texture into a sperate class each time you want to load it, it returns a referance to that textures class if it has already been loaded. This will help save on video memory and can also help to batch model drawing by texture. The beauty is that something like that would be API independant, so write it once and it will work with all your derived API texture versions.

A couple months spent in the laboratory will save a couple hours in the library.

This is a case of needing to study the wheel and not reinvent it:

http://www.ogre3d.org/

just to name one of countless examples

Regarding Ogre's texture management its not bad but I feel that particularly the base texture class tries to do too much - take for example the function to retrieve the depth - this is highly specific to 3d textures - so why is it not only available on 3D textures? For that matter why is there even an option to query the size of the texture at the generic level - all I have in my implementation is a function to bind the texture to a texture unit, which is implemented by the subclasses.

Currently my inheritance path then goes to API specific then texture type(1D, 2D, 3D, cubemap), but it is just as feasible to do it the other way around it all depends upon how I want to structure the code that actually uses the specific types.

So to give you an example of the flexibility I get to create a Shadow map texture - all I simply do is derive a new class from the RenderTexture2D class and implement the stuff that's specific to creating/binding a shadowmap - means I can almost directly copy and paste code straight from tutorials/documentation - easy!

Quote:Original post by jamessharpe
For that matter why is there even an option to query the size of the texture at the generic level

Isn't size common to all textures?

whats the benefit of having API dependent texture classes? why not having a function in the Abstract Render API that will bind the texture and in that function the different API calls will go.

e.g. having this

class CTexture2D : public CTexture { ... };

// abstract render api class
class CRenderCore {

...
// bind the texture using API dependet calls
virtual void BindTexture( CTexture *texture ) = 0;
}

instead of this:

class CTexture2D : public CTexture {

virtual void BindTexture() = 0; // have API dependent calls here in the derived class

};

Quote:Original post by McZ
whats the benefit of having API dependent texture classes? why not having a function in the Abstract Render API that will bind the texture and in that function the different API calls will go.

That might work, but API-specific calls are also required when the textures are loaded, (glTexImage, gluBuild2DMipmaps, or DirectX equivalents)... I think that jamessharpe's suggestion sounds very flexible.

And I agree that the Ogre engine seems to overcomplicate certain things, like texturing.

Quote:Original post by Aph3x

Quote:Original post by jamessharpe
For that matter why is there even an option to query the size of the texture at the generic level

Isn't size common to all textures?

Yes but the number of dimensions isn't so a clean interface is difficult to provide.

Quote:
whats the benefit of having API dependent texture classes? why not having a function in the Abstract Render API that will bind the texture and in that function the different API calls will go.

e.g. having this

class CTexture2D : public CTexture { ... };

// abstract render api class
class CRenderCore {

...
// bind the texture using API dependet calls
virtual void BindTexture( CTexture *texture ) = 0;
}

By doing this you have to assume the method used to store a texture representation is the same for all API's which of course is not the case - DirectX uses COM objects and OpenGL uses GLuint's.

well, then I might need to re-think my design a litle bit.

if I create a API dependent texture class like CglTexture2D would that one be derived directly from CTexture or should I still use the abstract CTexture2D class in between altough I can't really figure out why I would need that?

and then should I let the texture bind it-self?

e.g.
MyTexture->Bind();