In my 2D game project, as well as in LibGDX in general, are a lot of different entities that need to be rendered(static images, sprites, animations, etc...), as well as have certain effects applied (shaders). Most, if not all, tutorials show a simple hardcoded way of rendering each sprite instance, or at the most, a loop iterating over one type of renderable entity and rendering it.
I have a need to render a decent number of entities (~1000 static(background/tilesets) and dynamic(characters) per screen) where certain entities might have one or even multiple shaders applied to them. I'll also probably have to deal with rendering to FBO's to be able to apply multiple shaders on entities, though I haven't yet reached that point so I'm not sure yet (so far my entities have either 0 or 1 shader, but I'm planning on placing multiple shaders per entity soon so I need to take that into account).
I don't know what rendering techniques would allow me to accomplish this task however I've got some ideas I'm stuck with.
For more context I'm also using an ECS but I'm not coupling rendering to it.
My current idea is to have a RenderingEngine
of sorts, decoupled from ECS. It would basically contain a queue of... something, some message POJO describing what and where to render. This queue would then, each render cycle, be sorted according to layer, type, shader and then be distributed to their own appropriate renderer.
The gist is that other game systems send a message to the RenderingEngine
describing what they want rendered and then the engine works out what to do with it the next rendering cycle.
Current issues I've got with this idea:
- Messages might prove to be a performance overhead as they are plain objects created for the sole purpose of sending a message over. This could probably be alleviated via pooling.
- Shaders. Without shaders rendering logic is fairly simple [sort by layer -> for each layer sort by type -> render]. Shaders however are applied per batch and that confuses me. I am not sure where in the above rendering logic would shaders fit in...
Am I reinventing the wheel? Is there a standard technique of accomplishing this kind of "flexible" rendering?
Is the queueing idea I've described above a part of some well known technique I could investigate for clues?(My searches have given me no anwsers so far)