Dynamic light fallback doesn't work

[slipher]

For GL drivers lacking a certain extension, there is a fallback implementation of dynamic lights, which can be tested by replacing the line in sdl_glimp.cpp

glConfig2.uniformBufferObjectAvailable = LOAD_EXTENSION_WITH_TEST( ExtFlag_CORE, ARB_uniform_buffer_object, r_arb_uniform_buffer_object->value );

with glConfig2.uniformBufferObjectAvailable = false.

However, this implementation produces no visible effect for me. It seems to be the same as setting /r_dynamicLight 0.

[illwieckz]

On Linux with Mesa drivers, it's expected to be possible to test the missing extension without modifying code, by using this environement variable:

export MESA_EXTENSION_OVERRIDE='-GL_ARB_uniform_buffer_object'

[slipher]

My suggestion to disable it by deleting a line was bad as it misses the part which sets shader defines. A right way to test with the extension disabled is /r_arb_uniform_buffer_object 0.

I found that in the 0.51 release, the fallback code path works correctly, but only if you have r_dynamicLight 1 (the deprecated option). As of the latest 0.52/sync (including #453), the fallback code is broken even if you try to use the deprecated rendering path with /r_dynamicLight -1, so there's a regression there.

[illwieckz]

My commit turning deprecated renderer as -1 value was broken and then there was no way to re-enable the deprecated renderer.

This PR re-enables the deprecated renderer:

• https://github.com/DaemonEngine/Daemon/pull/1045

Once the deprecated renderer is working again and enabled, setting r_arb_uniform_buffer_object to 0 makes a difference, the screen turn into black when there is a light in scene, meaning it uses an alternate code path but this code path is buggy.

If the fallback is only usable on the deprecated renderer, this is a good reason to keep the deprecated renderer as a fallback itself.