VReaperV

> I found interest in the forwardLighting renderer for gameplay realtime lights versus cosmetic realtime lights. We don't have that distonction implemented, but the idea is that some lights may...

> Wait, it is actually possible with our code base to process dynamic lights without the `forwardLighting` renderer, while not using the `lighttile` shader? Yes, just upload it into the...

> * what does the `lighttile` shader do actually? Puts lights into `u_LightTiles` based on which tiles they affect and the depth buffer depth at that tile. > do skipping...

Perhaps then the texture matrix/texmods should then be made part of `shaderStage_t` instead.

> [@VReaperV](https://github.com/VReaperV) you may know what is happening, the crash happens in `GLShaderManager::PrintShaderSource()`. I'm not sure why it fails on that line... it only does `const size_t position = line.find_first_not_of(...

> I also noticed that with earlier commits before the one I reproduce the crash with, I got incomplete shader souce printing. Which commit is that? This also sounds similar...

I guess that code is simply eaten by the driver since we get it back through the api. With the recent changes to shader build system we can just store...

> I've noticed before that some of that code dealing with image arrays is really bad. It's like no one is really keeping track of the number of images in...

> I'm not sure how a separate release cycle would work given the need for an agreed-upon ABI. The client and all rendering DLLs would have to be updated simultaneously...

> Also, I find it wrong if updating the OpenGL renderer makes it only runnable it on devices supporting Vulkan. We better run Vulkan on devices supporting Vulkan than requiring...