1. What are the Begin() and End() calls actually doing?
Since there's no batching or sorting by effect going on, it makes no difference whether you call the Begin() and End() functions outside or inside the render. However if you later upgrade the engine to use rendering queues with batching, these Begin() and End() functions are going to be meaningless.
I'd argue that they are violating DI, and should be hidden away behind the renderer interface.
Begin() and End() do finally match the Begin() and End() calls of my D3DXEffect-framework wrapper, via the action handler and thus via the EffectModule. Yeah, I get the point, I started to experiment with a basic render queue, and I must say that those are really obsolete from that point of view.
2. Do you need to set the colour every frame? Some of this state could be managed in the underlying effect implementation, so you only modify it when it actually needs to change.
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.
It's then up to the renderer implementation to decide how to put all these things together into a render call, or render queue, or whatever it wants to do with them. Note that I'm also assuming a similar resource proxying mechanism for the mesh and effect classes. You don't actually need to resolve any of the lookups here at all, that can all be deferred to the Render() function's internals.
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.
I'd envisaged the texture class as being something almost completely engine agnostic, that could be stored in components. You wouldn't need to create them very often at all, and if you did, you could happily create them on the stack (public constructor that takes a pointer to the action handler - or something that can provide a pointer to the action handler) They're pretty lightweight, so it's not like they consume huge amounts of memory. In fact, they are probably going to consume less space than most texture names would, especially if you're using wide character strings.
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.
Note that I'm also assuming a similar resource proxying mechanism for the mesh and effect classes.
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?
EDIT: 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)?
Edited by Juliean, 08 April 2013 - 05:44 AM.