# Queued rendering in LibGDX 2D

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)

What you describe is somewhat similar to how libGDX's ModelBatch works. It deals with 3D graphics, but the sorting is similar, just instead of messages it uses Renderables, which are your "POJOs of what needs to be rendered". By the way, you may also want to sort by texture, unless you have everything on single texture atlas page.
• I'll check ModelBatch source out and see what I can "lift" off of it :D. Regarding the Render component. I'm using artemis-odb which doesn't seem to quite work with polymorphic components (so I can't for example make a system which gathers all Renderables), though my idea was to basically have a RenderSystem which would pass renderable data over to the RenderEngine thing i mentioned in the OP. – dumdumgames Aug 15 '18 at 7:00