Doom 64 style lighting improvements

[Graf Zahl]

How should gradients on 3D floor sides be handled? New flags in [wiki]Sector_Set3dFloor[/wiki]?

No idea yet. We could go overkill and do it ultimately flexible or just apply the middle part flags. Let's not forget that this stuff has to be checked for each wall segment that gets rendered so some compromises will have to be made.

[Gez]

I figure at a minimum it should use the part of the texture that applies (control linedef's middle part by default, but upper or lower part of the actual linedef if flags 16 or 32 are set).

[Graf Zahl]

Stuff for later. The more complicated this gets the harder it will be to do this efficiently.

[Graf Zahl]

Better gradient support is in. That leaves the Doom64 light model. Does anyone know how that works with depth fading? Or is it just the unattenuated colors without any fading?

[Major Cooke]

Can you add controls for ZScript like you did the sector glows (Sector's SetSpecialColor function)? Or are these non-runtime abilities?

[Graf Zahl]

Later. That first commit was just the pure feature.

[Erick194]

I'm going to take a look at the new color options.

[Erick194]

Excellent work Graf Zahl, the system to modify within the sidedefs is fine, but I think there should be at least flags for the line too, like: nogradient_all, clampgradient_all, flipgradient_top, flipgradient_mid, flipgradient_bottom.

I know that all these are in sidedefs mode, but if I want to make a sector that goes up or down I would have to configure it for both sides, it's just an idea.

Also with respect to NoGradien it could be the color of the thing, like d64.

[Graf Zahl]

I'd like to keep it simple for the renderer. All this stuff adds up and needs to be processed in time critical code. This is really not the place for convenience options.
There's a reason why this 'use sidedef colors' flag was added. This makes the check simple and straightforward instead of having to make guesses about the actual meaning - even though it makes editing a bit awkward. I think these things can be better managed by an editor

[drfrag]

Actually I've done several things with Gzdoom 1.9 you can see in the Doomworld forums

But you have not released your port yet nor any source code. No idea of what you've done to get the shaders working, i tried them in software with Mesa and it was somewhat playable. I was asking since i'm still maintaining an old version using the old 1.9.x renderer (ZDoom32).

Do Gallium, not SWRast. SWRast is why it is slow.

I used Gallium of course, it's still a 100% software driver.

I wonder if this will be portable to the vintage build, haven't looked at it yet, there's some stuff i need to add first. Looks i've got some work to do.

[Rachael]

If you do it, you'll have to bring back the LLVM dependency. And - interesting. I could've sworn it was hardware accelerated because it was at a playable framerate for me. I guess I got tricked. I never expected software rendered OpenGL to be that fast.

Of course, then I upped the detail settings to max just to see what it could handle and quickly discovered my frame rate tank. My fans are still spinning down from that little stunt.

[drfrag]

It's fast since recent versions are compiled with LLVM 6.
BTW i've recreated your old Pentium M laptop, same hardware but this one is a no brand chinese clone. I've adquired a hard disk for 6€ at Cex, hope it works.

I wonder if this will be portable to the vintage build, haven't looked at it yet, there's some stuff i need to add first.

I was referring to the D64 lighting of course, first i need the tarray changes. I don't know if this needs sections.

[Erick194]

But you have not released your port yet nor any source code. No idea of what you've done to get the shaders working, i tried them in software with Mesa and it was somewhat playable. I was asking since i'm still maintaining an old version using the old 1.9.x renderer (ZDoom32).

I know, I'm almost finished with the project.

I was referring to the D64 lighting of course, first i need the tarray changes. I don't know if this needs sections.

It's a bit complicated but if possible.

[drfrag]

How can i test this stuff? Is there a demo around?

[drfrag]

I've just pushed this, however i don't like the idea of pushing untested stuff. The next legacy devbuild could be somewhat broken, hope it's not. Definitely needs testing, also "- cache the results of hw_FakeFlat for the remainder of the current scene instead of storing this in local variables.", "- instead of copying the sector planes to GLWall, just store pointers to the front and back sector for later use." and "- more options for Doom 64 style gradients on walls" could need some reviewing.

https://github.com/drfrag666/gzdoom/commits/legacy

I never expected software rendered OpenGL to be that fast.

About MesaForWindows recent versions are indeed much faster plus now it works, surprisingly i've tried an older version and it now works too, may be it's the nvidia driver somehow. It's strange since it's a software driver.
Edit: confirmed that only works on certain cards, else no render buffers support.