Rework the way lens flares are rendered.

[DreamyCecil]

Description

Right now the code for lens flares seems to be very unstable. And while it might work (mostly) fine under the current configurations on many PCs, it seems to significantly slow down the engine internally or even absolutely break down under specific in-game graphics settings.

Most issues seem to be happening under OpenGL graphics API.

A few issues to note about lens flares:

• Tanked performance on lower end PCs, leading to less frames per second.
• Difficulty to implement under other graphics APIs, like Vulkan.

Other issues specifically under OpenGL:

• Rendering through everything regardless of obstacles in the way depending on rendering configurations.
  • Can be seen most prominently in Classics Patch when opening the menu while staring into a direction of lens flares obstructed by something (a torch behind a wall or the sun behind the roof).
• Inability to render them when the world is rendered on top of an active framebuffer using glBindFramebuffer() (a continuous spam of assertions is happening under Debug builds).
  • glReadPixels() with a depth component complains about the lack of a depth buffer, despite one being set up via a render buffer that is bound to the framebuffer. The most probable error: GL_INVALID_OPERATION is generated if format is GL_DEPTH_COMPONENT and there is no depth buffer.

Proposed solution

Find a way to determine whether a lens flare is obstructed by something without relying onto graphics API calls directly in order to display it on screen.

Perhaps try rewriting OpenGL logic from simply reading the depth buffer to whatever Direct3D is currently doing, which seems to work mostly fine with its much more complicated algorithm.