Decals will now be processed into a list in the processing pass, allowing to use the vertex buffer even on GL3 hardware and to offload this part of the work to a multithreaded worker task.
* to do this efficiently the amount of required vertices needs to be calculated up-front
* always create the vertices in the data generation pass, not the render pass.
* added synchronisation code to the vertex buffer allocator.
Without multithreading this causes a slight slowdown, due to added processing cost. (Frozen Time bridge scene drops from 47 fps to 44 fps on my test machine.
- added copy constructors and assignement operators to GLFlat and GLWall so that they can use memcpy instead of field-by-field copy. This actually increases performance slightly.
This is mainly for future-proofing because storing these as objects in an array not only has a negative impact when using multithreading due to longer blocking time for the threads but also makes it hard to cache this data for reuse.
This has increasingly become an obstacle with the hardware renderer, so now the values are being stored as plain data in the sector, with the software renderer getting the actual color tables when needed. While this is a bit slower than storing the pregenerated colormap, in realistic situations the added time is mostly negligible in the microseconds range.
Removing this made me realize that calling the renderers' FakeFlat functions from the automap is inherently unsafe with the recent refactorings because there is absolutely no guarantee that the data may actually still be defined when the automap is being drawn.
So the best approach here is to give the automap its own FakeFlat function that runs independently of render data and assumptions of data preservation. This one can also be a lot simpler because it only needs the floor, not the ceiling info.
This was done to clean up the license and to ensure that any commercial fork of the engine has to obey the far stricter requirements concerning source distribution. The old license was compatible with GPLv2 whereas combining GPLv2 and LGPLv3 force a license upgrade to GPLv3. The license of code that originates from ZDoomGL has not been changed.
This is slower than doing it in the render pass so it's only active when actually needed - it's also slower than using a client array so this code only gets used when there is no choice but to work with a 3.x core profile context.
It makes no sense having them organized differently in this struct than what the rendering code needs. This saves one redundant copy operation and a function-local static variable.
