First of all, thanks for looking into my renderer :).
Hmm I just realised that I never really looked into
PrimitivesCommand. But you’re right, they are very similar except that
PrimitivesCommands are (currently) not batchable.
Good idea, here’s what I would like it to have/support.
1.) Support for drawing with both
glDrawElements. Already there.
PrimitivesCommand only contains the data necessary for drawing, but doesn’t know how to draw itself. The
Renderer would be responsible for the drawing then. Kinda like my
PrimitivesCommands can be batched. Again, just like my
PrimitivesCommands would have an option to be transformed on the cpu or not.
Also I really liked the vertex gathering stage, because it allowed you to update the vbos once at the beginning of the frame.
I would also like the
Renderer to have control over all vbos used for rendering, and the
PrimitvesCommands would only provide the data that they should be filled with. This would have several advantages:
Renderer could batch buffer updates and submit them all at once before rendering.
Renderer could implement own backends for updating the vbos (e.g. if the GL_OES_map_buffer extension is accessible, us
glMapBuffer or if you support gles3.0 in the future it would use
Renderer could take of the issue that I mentioned with large updates via glBufferData on android (using buffer slicing)
So yeah, I would think if
PrimitivesCommand would be taken in the direction where
ArbitraryVertexCommand is, that would be pretty good.
You’re right with the backward compatibility issues, although I think that if that would be introduced in v4.0, this would not be a too much of a problem.
Issue 1) could be fixed by using a vertex gathering stage and issue 2) could be fixed by having a flag
A problem here would be that the glsl version on desktop openGL doesn’t mirror the openGLES one. I would use some kind of an enum, with values like
GLSL_30_ES and so on.
GLSL_20_ES would be version 100 on opengl es and version 130 (I think?) on desktop opengl.
GLSL_30_ES would be version 300 on opengl es and version 330 (I think?) on desktop opengl
You’re right, this would be low priority.
This would be the way too go as it looks a lot more mature than GLStateCache. It could be used along with the new
So yeah, makes perfectly sense