[WIP] New renderer

[TheJJ]

This is basically a totally new graphics engine, designed for our needs.

• Abstraction of render backend
• OpenGL 3.3 requirement
• Preparations for Vulkan (we don't know much..)
• File watching subsystem
• constexpr key-value map
• Screenshot support
  • optimizations (maybe this or this)
• Render pipeline abstraction
  • Textures
  • Shaders
  • Compiletime shader variable access
    • Uniforms
    • Vertex attributes
    • Dynamic buffer uploading
  • Samplers
  • Materials
  • Geometries
• Quaternions
• Texture position transformations without reuploading vertex buffer
• Texture packing
  • Efficient binpacking
  • 3D Textures
• Separate renderer thread and other event loop improvements
• Efficient render task queuing (minimize shader/texture changes)
  • Viewport clipping
• Smooth zooming
• Enable Z-Buffering
• Geometry drawing
  • squares
  • circles
  • smooth paths
  • boxes (for the gui)
  • text rendering (use freetype / harfbuzz / pango)
• Perspective translation (e.g. the unit-selected-circle)
• Terrain rendering
  • Terrain texture merging to single square tile
  • Perspective rendering
  • Blending cache
  • Terrain blending in the shader (in perspective to easily split tiles)
• Outline rendering with obstruction dual-pass (z-flip)
• Occlusion queries
• Pixel-perfect unit hitbox for unit selection and damage areas

implements #34, #286 and ideas from #153
closes #264 (file watching subsystem).
will do #149 (terrain blending in shader), #158 / #154 (blending cache), #141 (terrain perspective adjustments), #359 (outlines), #368 (unit selection box), #374 (texture clipping incorrect).

If you wanna work on this as well, submit pull requests to my branch please!

[Jon0]

can I request a Texture constructor which is usable by job threads? Currently the construction leads to gl calls which segfaults for not having an OpenGL context. I have made a small work around by moving the glBufferData() call to be done inside the first Texture::draw() call of a particular texture. which maybe the best way of implementing this feature. We should also have some kind of check that Texture::draw() is called using the main thread.

[mic-e]

Maybe we should move all program logic (including the main loop) outside Thread #0 (the thread that owns the OpenGL context and provides input), and have all other threads make synchronous calls into Thread #0?

[TheJJ]

My plan was to create a queue structure for all tasks to be rendered. Things to be drawn (textures, texts, geometries, whatever) would be added/registered to a queue and the renderer, when it's ready for the next call, fetches all those instructions, reorders them and then renders them to the framebuffer.

The registering/adding can be done from any thread, the renderer will either fetch the instructions itself or the instructions are converted/processed upon enqueuing, i haven't decided on that yet.

Basically all other subsystems will get backend-independent handles for all the render calls, so opengl or vulcan or maybe html5 someday can do the actual rendering then.

[TheJJ]

The thread-independent texture (TextureData in renderer/texture.h) should now be there i think. You can fill it with data anywhere and have to register it at the renderer instance to actually create the internal opengl handles.

[TheJJ]

https://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/

[TheJJ]

Continued in #850 :)