The other day I finally got to the point where I can say my two main systems (a sprite batcher and full GPU particle emitters) are working!

So I decided it would be a good idea to test them both... at the same time, which is where I ran into a minor glitch. Turns out if I do

 
batch.Begin(projectionMatrix);
batch.Draw(sprite1, 150.0f, 150.0f);
emitter.DrawParticles(projectionMatrix, 150.0f, 150.0f);
batch.End();

The emitter's particles will always get covered, regardless of the order. I soon found out it came down to the current batch of my sprite batcher not ending at the point of the emitter's draw call. Which makes sense, because they are separate systems and handle drawing separately.

Then I pondered a solution: If I had a render manager then I could do things like flag every Draw**** method for each subsystem. Then when a Draw**** calls are made I could flush and render whatever I need.

So this brings me down to my questions:

Is this something I should even consider / whats the best approach?

Should I have done this in the first place?

Would it just be better to have the separate entities and "flush/draw" when I know I need?

Does the Singleton pattern apply here / will I fall into it's "trap" (I kind of don't really understand the Singleton pattern trap)?

Is this something I should even consider / whats the best approach?

having a renderer interface responsible for properly sequencing all draw requests is a pretty common pattern.

Are we talking about a literal interface here that each "sub system" implements?
Or are we talking about some kind of larger "render system object", it has where all the "sub systems" as members and then we have wrapper functions?

EG Something like:

class RenderSystem
{

    public:
    DrawSprite(const Sprite &sprite, float posX, float posY);
    DrawParticles(const ParticleEmitter &emitter, float posX, float posY);

    private:
    SpriteBatcher batcher;
    bool pipeHasItems;

    /* Other members */
};

//=====================================================================================

void RenderSYstem::DrawSprite(const Sprite &sprite, float posX, float posY)
{  
    if(pipeHasItems)
       FlushRenderPipe();

    pipeHasItems = true;
    batcher.Draw(sprite, posX, posY);
}


/* Similar method for particle emitter */

/* -- Other render systems methods -- */

No, more like a "RenderSystem" object that methods to "enqueue" and "flush" objects of type "Renderable." A renderable object is a simple structure (not the base of some class hierarchy) that has references to geometry (vertex and index data), textures, shaders, and whatever other metadata you need to render (such as some flags to indicate sort order requirements, and so on). The render system simply enqueues these, sorting them as appropriate based on the data, and flushes them when needed (or demanded). This puts all the logic for dealing with batching, sorting, et cetera in one place.

Higher-level systems (like a "particle visualizer") are built on top of that medium-level system. The ParticleVisualizer interface can take a *logical* particle system description and produce the appropriate renderable instance or instances, which can then be fed to the RenderSystem.

No, more like a "RenderSystem" object that methods to "enqueue" and "flush" objects of type "Renderable." A renderable object is a simple structure (not the base of some class hierarchy) that has references to geometry (vertex and index data), textures, shaders, and whatever other metadata you need to render (such as some flags to indicate sort order requirements, and so on). The render system simply enqueues these, sorting them as appropriate based on the data, and flushes them when needed (or demanded). This puts all the logic for dealing with batching, sorting, et cetera in one place.

Higher-level systems (like a "particle visualizer") are built on top of that medium-level system. The ParticleVisualizer interface can take a *logical* particle system description and produce the appropriate renderable instance or instances, which can then be fed to the RenderSystem.

This sounds a lot like my sprite batcher in a sense. It takes in the all my data, manipulates it, gets it all ready for the render pipe, and etc. The only unfit puzzle piece is my emitters, since I created them with a dramatically different rendering method in mind. I guess its just a matter of fusing them together / building a system that can handle them both properly

Leaving me with a few questions, but mainly does this mean my "render system" is going to be tightly coupled to my current rendering objects or any future one's I create? Or am I missing the point here? And that I should be rewriting my current systems into one giant one instead of trying to keep them separated?

The way I see it is that my render system is the highest level and the subsystems (sprite batchers, emitter, light, etc) are the medium level. Maybe I'm thinking of this wrong?

I think, you did not understand he wants you to ditch the idea of a huge RenderSystem with dependencies on "everything", make the most basic one by avoiding it having any dependence on game objects and just take simple structures, which are still descriptive enough to render everything, as they contain only low-level data.

Then you can have any number of independent higher level systems, which only know of one type of game object and the RenderSystem interface and do the job of translating the data into the mentioned simple structures and feeding it into the RenderSystem.

but mainly does this mean my "render system" is going to be tightly coupled to my current rendering objects or any future one's I create?

No, exactly the opposite. Creating new things -- text, sprites, particle emitters, whatever -- involves appropriately crafting the data of an Renderable instance or instances and sending them to the RenderSystem. The RenderSystem only understands Renderables, and thus is not coupled to any specific use of them.

And that I should be rewriting my current systems into one giant one instead of trying to keep them separated?

Yes, you should strive to have your rendering pipeline unified. Differences should be handled by data, not code, for as deep along the pipeline as you can. Your approach right now appears to have each type of visual thing directly know how to render itself through manipulation of the appropriate D3D interfaces, et cetera. Not only does this create the sort of state synchronization problems you original encountered, it's usually less maintainable because it's usually a lot more repetitive boilerplate code, and changing or adding features can involve having to touch a significant amount of that code.

The way I see it is that my render system is the highest level and the subsystems (sprite batchers, emitter, light, etc) are the medium level. Maybe I'm thinking of this wrong?

I think, you did not understand he wants you to ditch the idea of a huge RenderSystem with dependencies on "everything", make the most basic one by avoiding it having any dependence on game objects and just take simple structures, which are still descriptive enough to render everything, as they contain only low-level data.
Then you can have any number of independent higher level systems, which only know of one type of game object and the RenderSystem interface and do the job of translating the data into the mentioned simple structures and feeding it into the RenderSystem.

In the approach I am describing, you have OpenGL or D3D at the bottom of the stack. On top of that is the "RenderSystem," which abstracts away those APIs allowing you to speak in terms of "draw this geometry with these flags at the correct time." On top of that you build the highest-level visualizers for transforming you logical game data (tile maps, sprites, particle emitters) into appropriate commands or objects for the RenderSystem to consume.

I do understand what Josh means, but I think the thing that is tripping me up is the way I currently have it VS the way I should have it.

The "Render System" Josh describes actually truly is my sprite batcher, it handles all my intended render calls for my sprites, tiles, etc.

But here is where the issue, the trip up I have, comes into play. Its that the system I wanted afterwards, my particle emitter, have been built on a whole different way of rendering.

It so drastically different that it did not/does not make sense to make it apart of my sprite batcher.

The reason these systems are so different / hard to fit together is what everything is when its boiled down.

The sprite batcher takes vertex data, manipulates it, fills a VBO, then if the batch needs to end because of a texture swap or we ran out of space then it is and new batch is started. Then you have my emitters, these are full on GPU emitters. In a nutshell, they get configured once on creation and you let them go. The GPU handles everything: it is responsible for creating new particles, killing particles, etc. The "renderable object" in turn gets handled internally by the hardware.

The two systems have very different vertex data footprints and ways of rendering. The batcher has its "normal" use of VBOs / a few uniforms and makes quads; where the emitter uses TBOs filled with point / particle property data, then the emitter's vertex shader "expands them" into quads.

That is why I am falling apart here :(

I can't make sense of having something that already handles itself and forcing it to be handled by something else that really does nothing for it

But here is where the issue, the trip up I have, comes into play. Its that the system I wanted afterwards, my particle emitter, have been built on a whole different way of rendering.

Which is generally bad. Now you have divergent render paths that must communicate to ensure reasonable state assumptions are consistent.

The sprite batcher takes vertex data, manipulates it, fills a VBO, then if the batch needs to end because of a texture swap or we ran out of space then it is and new batch is started.

A "batch" is a "renderable." Geometry, associated textures, flags (et cetera). A sprite batcher produces n renderables.

Then you have my emitters, these are full on GPU emitters. In a nutshell, they get configured once on creation and you let them go. The GPU handles everything: it is responsible for creating new particles, killing particles, etc. The "renderable object" in turn gets handled internally by the hardware.

The "renderable object" cannot be "handled internally by the hardware" unless there is some kind of draw call. Otherwise, nothing happens. So then, a "renderable" is that draw call. You must set up some kind of buffer, shader and texture state before you emit that draw call. Factor that out with the state that the sprite rendering is using. It's not going to be possible to give you further advice without more specifics about what you find so different between these two things.

The two systems have very different vertex data footprints and ways of rendering. The batcher has its "normal" use of VBOs / a few uniforms and makes quads; where the emitter uses TBOs filled with point / particle property data, then the emitter's vertex shader "expands them" into quads.

A "batch" is a "renderable." Geometry, associated textures, flags (et cetera). A sprite batcher produces n renderables.

A "renderable" has buffers (VBOs, TBOs), properties (uniforms) and shaders..

I see this differently, maybe I have thinking of this concept wrong, to me a renderable is a object such as a Quad.
Just the data that would be in a VBO (The XYZ positions, Texture Coords, assigned texture, etc), the VBO is just the medium to get it to the GPU

Maybe this is cause my focus is 2D

It's not going to be possible to give you further advice without more specifics about what you find so different between these two things.

I hope this will explain things better

For an instance of SpriteBatcher they have:

Renders Quads. Single vertex Data is:

XYZ position

UV tex cords

Single VAO:

Contains a VBO and IBO

Single Shader Program:

Contains a Vertex Shader and Fragment Shader

The VBO is filled using Draw methods that map directly into the buffer. Vertices are pre transformed

Drawing [When a batch's end has been signaled using the End() method or forced (ran out of space) through the VBO space check)]:

Bind the shader program

Bind the batch's texture

upload uniforms (MVP matrix / texture)

Bind the VAO

True draw call that uses the IBO to render all the data that was placed in the VBO

For an instance of Particle Emitter they have:

Renders quads transformed from point data. TBO Data:

XY position

XY acceleration

XY Velocity...

all use vec2 in shaders. 8 vec2s total

Two VAOs

VAO 1: contains only a TBO

VAO 2: contains only a IBO

Two Shader Programs.

Shader Program 1 (used for updating particles):

Contains a Vertex Shader and Geometry Shader

Shader Program 2 (used for rendering particles):

Contains a Vertex Shader and Fragment Shader

Pertains to Updating [thought I would include just in case]:

TBOs are initial given one "generator" particle. This particle created more particles based on uniforms that are used to describe the properties a particle can have (velocity, acceleration, etc). Particles are generated over time in the Geo shader, where they are also discarded if they are "dead". The vertex shader is the one that actually updates the positions etc

Pertains to Rendering [Explicitly done through a DrawParticles call]:

Bind Shader Program 2 (render program)

upload uniforms (MVP matrix / texture for particles / bind texture for TBO use)

Bind VAO 2 (one with IBO only)

True draw call that uses the IBO. Magic happens in the Vertex Shader where the TBO is iterated over to take each Point Data (single vertex and its data that makes up the particle) and expand it into a quad. Number of particles is based on the actual number of point data in the TBO

If you have any questions let me know