native tree
I've worked on this for the past few days and it works perfectly, but I want to be sure that it isn't overcomplicated or a bad idea.
I will put here the header and source files.
The logic is that the sprites are put into a multimap, sorted by texture, and then rendered all at once to minimize openGL calls.
Any criticism or different approach is welcome!
violet parcel
Haven't looked at the code, but why not just use texture atlases if it's all sprites anyway?
native tree
This is just a template for the approach I want to use regarding all renderers, not only sprite renderers
For example, a model renderer would sort its elements by model ID instead of by texture ID
violet parcel
Model being a mesh / bunch of meshes?
native tree
Yep
violet parcel
If so, doesn't make any sense to sort them before draw.
native tree
Okay that's true, I'll need to rethink
violet parcel
3D opaque: draw in whatever order you like, and each mesh will use its own materials / textures, so there's very little realistic chance of reusing bindings across meshes.
3D transparent: need to sort by distance to camera and draw backwards: furthest ones first, so that closer ones blend into them correctly.
2D implicitly transparent: draw the next object on top of all the existing objects. This simplifies UI at higher layers, you don't have to manually manage Z depth and such, just draw stuff in order of it appearing on the screen. This is where binding reuse will be most beneficial, as many 2D objects will share materials/textures.
native tree
Got it
Dang I didn't think about sprite layers
I should just ditch the multimap stuff and change it to a normal map shouldn't I
Because I just realized this messes with stuff being on top of each other
violet parcel
It's up to you. 😄
native tree
Well, it's not like I'll be gaining all that performance from HUD elements anyways