The renderer at the moment is very stable and works well with the current engine structure. The problem is that the renderer is not very expandible and while looking at implementing a HTML UI engine (RmlUI), due to the structure we'd not be able to have the renderer run this. The problem is the Renderer's support for indices, currently only a vertex buffer exists making indices extremely slow (We'd need a system similar to the vertex conversion code).
The Solution (I think/hope)
Rework the renderer to support indices (optionally) and have an index buffer alongside the vertex buffer. In order to ensure that the renderer does not slow down due to writing another buffer, we need to investigate ways of multithreading the renderer where possible (such as processing vertex conversions or buffer writing). This would both allow indices to be used in the renderer and could also speed up the conversion process (Currently only quads and triangle fans to raw triangles) and would involve far less data being passed to the GPU. This implementation shouldn't break anything that is currently in the Engine, but would change (again) the API for pushing batches of vertices.
In addition to this change, the matrix stack should be made available to the batch Add function to allow for easier translations of massive vertices.
Additional changes to Engine to make this smoother
The update loop can be moved to a second thread (for release builds) to allow for drawing to be uncapped to an FPS (If options allow for this). This will allow for updates to use a full frame and drawing to use a full frame, not whatever ratio there is currently for both in one frame (i.e 2 parts of the frame to update, 1 to draw).
The renderer at the moment is very stable and works well with the current engine structure. The problem is that the renderer is not very expandible and while looking at implementing a HTML UI engine (RmlUI), due to the structure we'd not be able to have the renderer run this. The problem is the Renderer's support for indices, currently only a vertex buffer exists making indices extremely slow (We'd need a system similar to the vertex conversion code).
The Solution (I think/hope)
Rework the renderer to support indices (optionally) and have an index buffer alongside the vertex buffer. In order to ensure that the renderer does not slow down due to writing another buffer, we need to investigate ways of multithreading the renderer where possible (such as processing vertex conversions or buffer writing). This would both allow indices to be used in the renderer and could also speed up the conversion process (Currently only quads and triangle fans to raw triangles) and would involve far less data being passed to the GPU. This implementation shouldn't break anything that is currently in the Engine, but would change (again) the API for pushing batches of vertices.
In addition to this change, the matrix stack should be made available to the batch Add function to allow for easier translations of massive vertices.
Additional changes to Engine to make this smoother
The update loop can be moved to a second thread (for release builds) to allow for drawing to be uncapped to an FPS (If options allow for this). This will allow for updates to use a full frame and drawing to use a full frame, not whatever ratio there is currently for both in one frame (i.e 2 parts of the frame to update, 1 to draw).