I just finished the overworked Renderer. Uploaded it to GitHub, check it out here.
It works fine and I was not able to find any bugs or errors. If you find one, please let me know 
In it’s current form, it addresses the first three flaws/issues. The most important feature is of course the ArbitraryVertexCommand, as it enables you to render all kinds of meshes, etc. without even touching OpenGL. For more info check the GitHub page.
The rendering process is as following:
- sort RenderQueues
- make a single list out of all RenderQueues while:
- converting TrianglesCommands and QuadCommands to ArbitraryVertexCommand
- creating batching data
- map the index and vertex buffer to the gpu
- process all RenderCommands
There are however some issues/flaws with this implementation too.
Too make sure that you can use this Renderer without changing any code in your game, every TrianglesCommand and QuadCommand needs to be converted to an ArbitraryVertexCommand. This creates quite some overhead if you are using a lot of them. Another one is that if you call the Renderer::render function more than one time per frame (e.g. if using multiple Cameras per scene) issue #1 happens again. A solution to this would be multi-buffering.
I also did some comparsions (performance wise) between the cocos2dx renderer and my renderer. Here are the results:
###Tests
MR: My Renderer
CR: Cocos Renderer
android1: Tested on Samsung Galaxy S (very old device)
android2: Tested on Motorola Moto G
EDIT: The given time is the time that the Renderer::render function took to finish.
Test case 1: 10000 Sprites are visible on screen sharing all the same material.
Results:
Win32 MR release = 7.803578ms
Win32 MR debug = 30.862434ms
android1 MR = 59.805569ms
android2 MR = 38.757420ms
Win32 CR release = 2.439611ms
Win32 CR debug = 9.020019ms
android1 CR = 28.575230ms
android2 CR = 20.793112ms
Test case 2: 10000 Sprites are visible on screen. They are rendered in 1000 batches
Results:
Win32 MR release = 8.053041ms
Win32 MR debug = 32.239613ms
android1 MR = 63.866676ms
android2 MR = 42.696968ms
Win32 CR release = 2.613098ms
Win32 CR debug = 9.656133ms
android1 CR = 31.219564ms
android2 CR = 21.113848ms
Test case 3: 10000 Sprites are visible on screen. Every 100th Sprite, there is a CustomCommand (meaning pipeline flush)
Results:
Win32 MR release = 8.103778ms
Win32 MR debug = 32.057499ms
android1 MR = 61.389282ms
android2 MR = 40.610973ms
Win32 CR release = 9.170638ms
Win32 CR debug = 26.020094ms
android1 CR = 201.462753ms
android2 CR = 17.157057ms
Test case 4: 10000 Sprites using ArbitraryVertexCommand directly (meaning no conversion necessary) are visible on screen. They share the same material.
Results:
Win32 MR release = 3.819415ms
Win32 MR debug = 18.110653ms
android1 MR = 40.330093ms
android2 MR = 24.701368ms
Win32 CR release = N / A
Win32 CR debug = N / A
android1 CR = N / A
android2 CR = N / A
###Conclusion
Note: The gigantic gaps between the debug build and the release build are mainly due to the lack of function inlining in the debug build.
As you can see from the results, the conversion of the TrianglesCommands and QuadCommands produces quite some overhead. Issue #1 is nicely represented by test case 3, as the release CR version is slower than the release MR version. However on the Moto G, test case 3 performs even faster than the other cases which is pretty odd. You can also see that if every TrianglesCommand would be replaced by an ArbitraryVertexCommand, my renderer would be nearly as fast as the original.
It would be cool if anyone could use my renderer on an ‘real-life’ scenario and tell me how it performs there ;).
The Renderer wasn’t really optimized by myself yet, so that could be another reason why my Renderer is slower than the original.
Cheers,
Darinex