I have some more builds for you to test to make sure I didn't horribly break the rendering engine of FSO with my changes
These changes should have no effect on the behavior of FSO so if you see anything different compared to the most recent nightly please let me know here.
Test build for all platforms:
http://swc.fs2downloads.com/builds/test/persistentBufferMapping/So, what do these builds actually do differently?
The easy explanation is that they improve the way FSO lets your GPU know how to render your shiny ships.
The more complicated explanation requires some additional information:
At the moment FSO uses a mechanism called "Uniform Buffers" for a few things when rendering your frames. These buffers are a pretty efficient way of grouping data together to make it more efficient to upload them to the GPU. Some time ago, I changed some of the rendering functions to make use of this which improved the performance of FSO by decreasing the CPU overhead. The way I made these changes worked for large batches of data (e.g. when rendering a lot of models) but it would cause a lot of overhead when only uploading a few bytes of data. The reason why I added uniform buffer support in the first place is to move closer to how the new Vulkan API works since that only supports uniform buffers instead of simple uniforms which are used extensively by FSO at the moment. So, before we can even consider supporting that API, FSO needs to only use uniform buffers, even for small amounts of data. This is where my changes from these builds come into play.
With these changes, all uniform data is kept in one large buffer where it is more efficient to store a small amount of data. Furthermore, I added optional support for
persistent buffer mapping. This technique is quite new and requires a more recent GPU (there is a fallback for older GPUs though). When this is enabled the OpenGL driver is involved even less than before in the process of uploading data to the GPU which in turn decreases the CPU overhead.
I'm sorry if this last part was a little too technical...