Awwh, that makes me a little bit worried about my current use of this system. Right now I'd e.g. use one of my component systems to render like this:
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.
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.
3. Setting the worldview matrix in the effect might make sense in terms of the implementation details, but does it makes sense from a high level view? If not, it's probably a DI violation.
I think it would be cleaner to change your Render interface to something like:
void Renderer::Render(const CMesh&, CEffect&, CMatrix worldView);
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.
Yeah, thats the thing. Since I used a linear only-so-named-because-it-sounds-cool "hash", I actually required that map to actually access my textures again after loading them safely. So you'd suggest to create a hash of the texture name on loading - and then, when I later access that file (loading and accessing is a seperate task now, no more lazy loading, the one time in the texturemodule was a slip), simply create a new Texture-object, like this?
Yeah, thinking about it it may be better to stick to using a linear index for the locator. Either way, it's an implementation detail, and so long as it's all wrapped nicely behind the relevant interface, you can tweak the actual implementation details to better suit the real life usage patterns.
Well you can call me on premature optimization there too, since I assumed that it was better not to create a new texture handle (can we call it that anyway?) every time I accessed a texture by file name? You could also call me on having currently a stupid messed up rendering system that at least for the entities doesn't store the textures but accesses them per frame per entites (no, not even material sorting currently, yiekes :/) so that would be quite a bit memory creation and deletion per frame. That is, if you are suggesting me to handle it that way as in the code, aren't you?
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.
