Well, I'll at least have to try to set it every frame, if you are just talking about the code that is calling SetColor here, since I have more renderer that all render with the same effect and use the texture slot with different textures. I don't see many possiblities to handle this like you said, except if you are talking about like in a render queue - I quess the color would be part of my StateGroup commands, so that might work out.
There are a few approaches you could take. Alternatively the colour could be stored in the api agnostic Effect object, or in a low level, api specific wrapper that is stored in the EffectModule. When actually setting up the underlying d3deffect object, you just set the stored colour. Outside the api specific renderer code, you only set the colour once, or when it needs to change for a specific Effect instance.
Sounds like a good idea, but would you rather advice me to have the "renderer" class of your example be a seperate class, getting a reference to the texture, effect and mesh module, or is it supposed to be what my "Gfx3D" class does, simply in a different name? Also, the renderer isn't really supposed to be API agnostic, isn't he? Since only way to really resolve this lookups really is if I quarantee my renderer to hold a dedicated API-specifiy version of the resource modules (if it shouldn't be part of api specifiy gfx3d implementation, that is), at least I can't see anything else.
Yep, it's the same as your Gfx3D class, and the implementations will be api specific. (but the interface should not be, of course)
Yah, currently my component stores only texture file name. I see that this isn't very fitting since I'm now going for an advanced low level rendering implementation. So I see, I'll need only the locator for the current texture name and a pointer to the action handler, without the need to create and/or store a dynamic Texture object. Then again I'll at least need the one map you mentioned before, to further map file name to locator, but I think that'll be not a big deal.
But that's all the Texture really is. A pointer to an action handler, and a locator. Why not store the textures? It's clearer what they are and how to use them.
Yup, you are assuming right. I didn't want to specifically implement it for mesh before I've heard your opinion about what I've done before, quess that wasn't a bad choice since its going to save me a lot of unnecessary work like the Begin and End functions of the Effect. So I quess I really should just expose the functionality that is totally needed via the Texture, Effect and Mesh classes and leave everything possible to the renderer using the actual API-specifiy objects, right?
Yep, that sounds about right. You may also find that you actually don't need very many 'actions' on the textures after all, because once you've moved all the rendering logic behind the api specific interface, you will probably find that you only very rarely need to muck about with the internals of the texture from outside.
Also, I was wondering how I should handle this system for the meshes? Right now I'm only having low-level wrappes for dx objects like vertex buffers, index buffers, and vertex declarations. Should I have different allocators for those in CMesh or should I create some DX9-level abstraction class for meshes (therefore a combination of vertex buffer, index buffer and vertex declaration)?
Vertex buffers and index buffers are implementation details and should not be exposed outside the api specific code, not even indirectly in the form of locator objects. My feeling is that the IB and VB info should probably be wrapped up in an api specific mesh object, and have the locator point to that.