renderer

This is the main page containing all information regarding the new renderer

API's

• ideally support opengl and vulkan rendering. The architecture should allow an easy integration of vulkan, OpenGL is first target.
• OpenGL target version is 3.3
• if possible use different implementations depending on the available OpenGL version (immutable storage, ...)

General note to Vulkan

• Vulkan has no glsl reflection like glGetAttribLocation, glGetUniformLocation, ...
• Vulkan has a lot of immutable state, e.g. a Buffer cannot be resized after it's creation
• Vulkan has much less global state than OpenGL, i.e. no global clear color, ...
• to allow an easy integration of vulkan I recommend keeping this things in mind for implementing an API independent logic

Requirements

Also see this and this

• DONE: Rendering textured quads (tile rendering)
  • DONE: for textures keep the pack and unpack alignment of opengl in mind (see this
• Partly DONE: multipass rendering
  • DONE: render to texture
• terrain rendering
• DONE: enable use of buffer objects
• Partly DONE: support of much textures, texture atlases ( Vulkan has ImageViews see this, but maybe prefer OpenGL and Vulkan shared solution)
  • There is gamedata::subtexture -> the correct tex-coords for a quad have to be passed as vertex attributes
• DONE (maybe not completely finsihed): abstract view on passes with pass inputs and pass outputs
  • for uniforms using uniform buffer objects is preferred by myself (performance, more compatible to vulkan, in the end it is whats the driver does)
    • regarding buffers used in shaders a memory layout has to be respected. The std140 layout should be used because its compatible with vulkan, see this "Sub-section 2.15.3.1.2 - Standard Uniform Block Layout"
  • DONE: using old style OpenGL uniform variables -> should be ok
• STARTED: use geometry class/struct for drawing quads or complex geometries
  • because vulkan has no glsl reflection like glGetAttribLocation it is preferred to implement some logic that maps attributes of drawables to the correct position for the shader (more information can be found here
• outline drawing
• 3D coordinate system with classic modelViewProject-Matrix to handle drawing objects at specific positions.
  • orthographic projection should be the first projection method to use
  • maybe conversion from/to other openage coordinate systems is required
• ON HOLD (not really a thing to think about now): Phong illumination could be needed
• use of heightmaps, tesselation of terrain for terrain with... different heights ;)
  • use of geometry shaders for tesselation required because OpenGL 3.3 is targeted
• texture compression (low priority currently)
• DONE: use depth testing for correct order of drawing
  • if semi-transparent objects are drawn this could be improved (depth peeling or so?)
• scene graph and drawing only visible objects, (optional: minimize overdraw)
  • -> basic view-frustum culling to enhance performance
• terrain blending
• occlusion queries (to further enhance performance?!)
• ALMOST DONE: pixel perfect hitbox (render object id into texture)
  • TODO: support 32 bit id's
• maybe remove some dependencies on SDL (e.g. for storing a texture)
• a way to parallel rendering tasks, only vulkan can use this but its a key benefit. Using an abstract implementation where OpenGL can simply do the work in one thread would be optimal

Roadmap

• 3D coordinate system
• implement, use geometry class
  • how to pass vertex attributes belongs here
• game renderer that is "link" between renderer and game
• terrain drawing -> blending, tesselation, ...
• scene drawing, scene graph?
• debug code -> display statistics, display overdraw, display wireframe, different textures, e.g. id texture, maybe display complexity -> e.g. terrain blending stuff, ....
• outline drawing, when no outlines are present in the textures / sprites
• depending on the amount of work getting a OpenGL implementation is more important than working on Vulkan in parallel