There's a reason every modern language has forbidden this kind of C-style tomfoolery: you will make more mistakes like this before your project is done! :)Thank you, for some reason, i totally missed it :wacko:
There's a reason every modern language has forbidden this kind of C-style tomfoolery: you will make more mistakes like this before your project is done!
When you think your code is finished, leave it for a month, then come back and audit it with a fine-toothed comb.
Of course i realize that. The thing is i'm not working on production code, i'm just experimenting during my spare time.
I don't override new/delete because with these kinds of packed/variable-sized structures, I usually want to put more than one of them into a single allocation. So I usually end up with a function that lookw like a simple constructor, but actually just returns the size that's required. You can then loop through all the objects that you want to create, measure their requirements, perform one single big allocation, then do a 2nd pass where you actually construct them in-place.I would highly recommend overriding new and delete for any struct that stores data past the end (or use a factory function and hide all the constructors).
I also wouldn't include structures like this in any public header files -- the public API would likely just have a forward declaration of the type ("struct DrawItem;"), a factory for creating them, and functions that ise/consume them. That way all this dangerous variable size stuff isn't even visible to the user of the code.
Does every draw item really need to store information about shaders, number of textures, assigned textures, etc?
Wouldn't it be better to store an id to a "material" object which contains a pair of shaders and any textures/constants that need to be set for the material to work?
Yeah, that works too. The less code that has to know about how to specially construct these and what not to do with them the better.
Yes it is very important in production code that is manipulated by many people not to allow such a data structures to be easily or accidentally accident missused. It must not be possible to construct a drawitem on the stack or in a conatiner that would construct an incomplete object.
Does every draw item really need to store information about shaders, number of textures, assigned textures, etc?
Wouldn't it be better to store an id to a "material" object which contains a pair of shaders and any textures/constants that need to be set for the material to work?
Yes indeed. But then, how do you define the "material" object ? This material object will need to have thoses fields anyway with the arrays.
Yes indeed. But then, how do you define the "material" object ? This material object will need to have thoses fields anyway with the arrays
Well, the main idea is that not every draw item will have a unique combination of shaders and textures, etc. By moving the shared data into a material you will save memory in your main draw queue, it's basically the flyweight pattern.
Also you will want to sort your render queue by some criteria which will probably include a material id. Since the number of materials will hopefully be much less than the actual number of draw calls you could use some "heavier" data structures like vectors for the varying length parameters like textures and constants.
Well, the main idea is that not every draw item will have a unique combination of shaders and textures, etc. By moving the shared data into a material you will save memory in your main draw queue, it's basically the flyweight pattern.
Also you will want to sort your render queue by some criteria which will probably include a material id. Since the number of materials will hopefully be much less than the actual number of draw calls you could use some "heavier" data structures like vectors for the varying length parameters like textures and constants.
You mean moving the shaders, the shader parameters and the textures to a material class that could be shared among multiple DrawItems ? Yes it could be done. But what i'm trying to do (and this is only experimentation) is to pack all the data for a draw call into contiguous memory to see if there is something to be gained by being more "cache efficient". Packing arrays is what is actually difficult.
Elements of a draw item are of course shared across models.
