Hey! I am going to design my resouce classes and I have encountered a big problem developing the Texture and Font classes because ... they are api - specific, right ? I don't think I could create a generic Texture class because the engine should load it before rendering the scene or it will be very slow... I should create an abstract texture class and some texture_dx10 and texture_gl classes, but I am looking for a way to: 1) hide the name of the api-specific texture class under the name of the abstract one in a way that the user doesn't see he's directly istantiating a texture_dx9 or texture_gl class... 2) provide a sort of extensible resource system: I could create some function in the renderer such as Texture* t = Renderer->createTexture() but it would not be extensible and user couldn't have the possibiliy to manage the memory of a resource by themselves or to add new resouces ( Renderer would work as a sort of static abstract factory, it could be very difficult to code new resources without editing the renderer code, too )... Could you help me with some ideas please ? I can't go ahead in my engine if I don't solve this design problem.. I hope you will help me :) Thank you!!

i dont see why u cant use the renderer as a factory? there will be maybe 7-8 different resource u have to add... Texture, VertexBuffer, etc... thats how i do it...

Hi, thanks for the answer !
I would like to avoid the renderer = factory solution because renderer' s scope is to draw polygons, i don't know if formally it's a good design, and because i would like to provide a solution for the game programmer to add custom resources in the engine which, for example, manage the memory in a sort of "custom" way...

Quote:Original post by Whiles
Hi, thanks for the answer !
I would like to avoid the renderer = factory solution because renderer' s scope is to draw polygons, i don't know if formally it's a good design, and because i would like to provide a solution for the game programmer to add custom resources in the engine which, for example, manage the memory in a sort of "custom" way...

what kind of custom resources? the renderer should only handle its own resources such as Textures, VertexBuffers etc... and i think its within the renders scope to create the resources it uses... only the renderer will ever need these resources... so i dont see why you would create them elsewhere... i think this is a good design also if u later want to put the renderer in a seperate thread...

Do you know if it's possible to develop a generic texture class ?
It seems like Horde3D has a generic class which loads the pixel data and passes it to opengl ? Is it possible to pass pixel data to Directx, too ?

Quote:Original post by Whiles
Do you know if it's possible to develop a generic texture class ?
It seems like Horde3D has a generic class which loads the pixel data and passes it to opengl ? Is it possible to pass pixel data to Directx, too ?

i dont see what u mean by a "generic texture class" or why u even need it...

i do it like this...

ive got a library with all my interfaces... forexample



then i implement it for the different APIs...



then u would do something lile

IRenderer* renderer = new d3d10::Renderer;

ITexture* pTexture = renderer->CreateTexture(); // create a d3d10::Texture but returns a ITexture