DRD Team

Graf Zahl wrote:...I did some further tests with much more simplified data and shaders. It doesn't crash anymore but it exhibits some really odd behavior which looks like a driver bug....

4. Swap lines 12 and 13 in the shader (vec4 light =... and vec4 texel =...) and run again.

No matter what I do, I either get the texture data or the texture buffer data, but never both at the same time.

Are you doing this in a subroutine called from your shader main? If so, does the same occur if you inline that subroutine into main?

This does sound a bit odd but I must admit to only having limited working experience with shaders.

Actually, this is really just a very simple test shader. All it contains is this:

The 2 lines marked with a * are the ones I am talking about. If I switch them around I get a different result. To be precise it's always only the data from the second call. If I add further sampler calls it's always the last one that gets displayed.

I tested it, after commenting out the EnableLight calls. The new code works for me, no bug, no crash, no different outcome depending on line order in main.fp. Also, no discernible difference when playing between old and new code.

Vista 32, Nvidia GeForce 9600m GT with those drivers and modded inf.

Damn. Can you make a screenshot of E1M1 right at the start? I'd like to see at least if it does what it should do.

Here are two screenshots, one with dynlights on and one with dynlights off. Based on r524.

In both the test shader is clearly not being used at all. Most importantly, if it is active you wouldn't see any dynamic lights.

I ditched the texture buffer approach because no matter what I tried, it didn't work. I found an alternative that seems to work fine.

Performance wise it's sometimes better and sometimes worse than the old method but the lighting looks a lot cleaner when done with shaders. Apparently the old light texture is not particularly good.

The best thing though is that the new method is capable of having final light levels that are greater than 1.0 which in many cases makes the lights look a lot better.

Essentially I have implemented most of the stuff I planned for the new renderer. It's really too bad that nothing of this proved to be a performance boost. I have stopped trying now. There's no point in optimizing the rendering code. Each cycle I manage to shave off the engine has to wait at the end of each frame so it's just shifting the time to another place and that's not worth investing work in.

So all that's left is clean up and add some options to GLDEFS to configure the new dynamic lighting method for different textures.

GuntherDW wrote:Also, RT lighting would be somewhat hard to do in the DooM engine, which is utilising sector lighting and all.

I know I am gonna get shot by saying this, knowing they are two entirely different games, and engines altogether with only minor things in common... But, the Eduke32 devs managed to pull off RT Lighting (well, a mix between RT and Sector Light) in a game that uses Sector Lighting, via their new Polymer Renderer, which I do believe is purely shader-based, and runs on OpenGL 2.0. Looks quite awesome as well.

http://www.youtube.com/watch?v=z9nVuf6O ... r_embedded (Video)

Spoiler: Shot of Polymer

---

Of course it can be done, with the appropriate time and effort. But that's not my goal - both for lack of interest and time.

I am aware, and I respect that. I just figured I would mention that though.