Page 2 of 5

Re: Doom 64 style lighting improvements

Posted: Sat Nov 10, 2018 5:27 pm
by Rachael
https://mega.nz/#!4ZlUXCgb!Lm4Hr3JU-CYX ... iRwCSr-FKE

This is the 64-bit Mesa Gallium driver, which redirects OpenGL calls to Direct3D. This particular version is probably a year old now, but it supports OpenGL 3.3.

I have no idea if it's going to work for you. If it does, the first thing you should do is set "vid_scalemode 2" in order to use a lower resolution render buffer, this will speed things up considerably for you. That should at least make the Doom64 lighting visible in GZDoom.

If you do decide to use it, you might consider making a separate folder and reinstalling GZDoom to the new folder with this driver, so that you can test both with and without the driver.

Re: Doom 64 style lighting improvements

Posted: Sat Nov 10, 2018 5:32 pm
by Erick194
I'll agree, I'll try.

Re: Doom 64 style lighting improvements

Posted: Sat Nov 10, 2018 6:01 pm
by Erick194
Well with the bookstore that you gave me, it did not work, I investigated a more updated one and downloaded this
http://downloads.fdossena.com/Projects/ ... -18.2.4.7z
and it worked, here an image

opengl render mode.

This is interesting now I can do tests, with the recent version.

Re: Doom 64 style lighting improvements

Posted: Sat Nov 10, 2018 6:06 pm
by drfrag
Rachael wrote:This is the 64-bit Mesa Gallium driver, which redirects OpenGL calls to Direct3D.
That looks interesting, a recent OGL to D3D wrapper. Where can i get the 32 bit version and more info about that driver?
Erick194 wrote:but force the port to 4.4 and enable those shaders without problems
You made a source port based on GZDoom 1.9? What do you mean by forcing 4.4? I know there was an experimental version enabling shaders on GL2 hardware, i tried it but it just crashed.

About mesa for windows i never got that one to work with render buffers enabled.

Re: Doom 64 style lighting improvements

Posted: Sat Nov 10, 2018 6:10 pm
by Rachael
drfrag wrote:That looks interesting, a recent OGL to D3D wrapper. Where can i get the 32 bit version and more info about that driver?
Mesa is Linux's default driver front-end for X11, if it is not replaced by your GPU driver directly. Gallium also works in Linux by interfacing with the open-source drivers which will drive the GPU's hardware functions. I believe it also includes its own compiler.

It can also be configured with environment variables. https://www.mesa3d.org/envvars.html

https://fdossena.com/?p=mesa/index.frag
Try this

Re: Doom 64 style lighting improvements

Posted: Sat Nov 10, 2018 6:11 pm
by Rachael
Erick194 wrote: This is interesting now I can do tests, with the recent version.
That is good to hear. At least now your hardware isn't what's holding you back, for now. :)

Re: Doom 64 style lighting improvements

Posted: Sat Nov 10, 2018 6:14 pm
by Erick194
drfrag wrote:
Rachael wrote:This is the 64-bit Mesa Gallium driver, which redirects OpenGL calls to Direct3D.
That looks interesting, a recent OGL to D3D wrapper. Where can i get the 32 bit version and more info about that driver?
Erick194 wrote: You made a source port based on GZDoom 1.9? What do you mean by forcing 4.4? I know there was an experimental version enabling shaders on GL2 hardware, i tried it but it just crashed.
Actually I've done several things with Gzdoom 1.9 you can see in the Doomworld forums
https://www.doomworld.com/forum/topic/9 ... r-edition/
Rachael wrote: That is good to hear. At least now your hardware isn't what's holding you back, for now. :)
you're right :)

Re: Doom 64 style lighting improvements

Posted: Sat Nov 10, 2018 6:49 pm
by drfrag
Rachael wrote:Try this
Actually that's the one i tried, it's a software driver and not a wrapper. Wine for windows is a D3D to OGL wrapper and works very well.
Mesa for windows is extremely slow without glversion 2 BTW.

Re: Doom 64 style lighting improvements

Posted: Sat Nov 10, 2018 7:20 pm
by Rachael
Do Gallium, not SWRast. SWRast is why it is slow.

Mesa is not exclusively a software renderer for OpenGL - that's one of its primary features, but it does use hardware acceleration when it is available. In fact - that's actually what it was designed for to begin with! (Albeit, not on Windows for that)

The primary reason why Mesa even has a software renderer is to serve as a reference implementation. If, when you program to it, it doesn't work on Mesa, chances are real GPU drivers (as long as they are programmed right) will have troubles with it too. There are obviously some things that GPU drivers can do that Mesa can't, and Mesa largely plays catch-up with the latest GPU features, but generally that's how it is.

Also, if Mesa is doing a lot of software rendering under Gallium, chances are pretty good that Microsoft is actually taking over missing GPU features with its WARP implementation. That feature was added in Windows 7 and plays an important role in getting desktop composition working in 8 and 10 when your drivers are missing. WARP can compile its own shaders and if your GPU cannot do certain things Microsoft will render them on your CPU, instead. It uses some tricks to accomplish this at a reasonable speed, like SwiftShader does for D3D 9.

Re: Doom 64 style lighting improvements

Posted: Sat Nov 10, 2018 11:28 pm
by Talon1024
The Doom 64 Tech Bible is here. I had a quick glance, and it looks like there are flags for each linedef to peg the gradients to top or bottom, and/or invert the gradients on all sections of the wall.

I would suggest having peg and invert flags for each section of the wall in order to be more flexible, and maybe make it so that the parts of the gradient which are not pegged all have to have the invert flag set in order for the non-pegged gradient to be inverted.

Re: Doom 64 style lighting improvements

Posted: Sun Nov 11, 2018 12:18 am
by Erick194
This is a possible code:

Code: Select all

#define WALL_TOP 1
#define WALL_BOTTOM 2
#define WALL_MID 3

void R_SetSegLineColor(seg_t * seg, int type)
{
	PalEntry Top = seg->frontsector->SpecialColors[sector_t::walltop];
	PalEntry Bottom = seg->frontsector->SpecialColors[sector_t::bottom];
	PalEntry TempTop;
	
	if (seg->backsector && type != 0)
	{
		if ((seg->linedef->gecflags & ML_FLIP_UPPER_PEGGED_COLOR) && type == WALL_TOP)
		{
			//Flip Color Top Only
			TempTop = Top;
			Top = Bottom;
			Bottom = TempTop;
		}
		
		if ((seg->linedef->gecflags & ML_PEG_UPPER_WALL_COLOR) && type == WALL_TOP)
		{
			//no interpolate color
		}
		else
		{
			//interpolate color (front ceiling to front floor)
		}

		if ((seg->linedef->gecflags & ML_PEG_LOWER_WALL_COLOR) && type == WALL_BOTTOM)
		{
			//no interpolate color
		}
		else
		{
			//interpolate color (front ceiling to front floor)
		}
		
		if (type == WALL_MID)// midtexture
		{
			//interpolate color (front ceiling to front floor)
		}
	}
}

Re: Doom 64 style lighting improvements

Posted: Sun Nov 11, 2018 3:14 am
by Graf Zahl
No flip_lower?
I also remember there was something about restricting the gradient to the actual wall tier and not only from front ceiling to front floor.

Re: Doom 64 style lighting improvements

Posted: Sun Nov 11, 2018 3:24 am
by Graf Zahl
Talon1024 wrote:The Doom 64 Tech Bible is here.
That information should be sufficient. Of course doing it precisely like Doom 64 is too limited. I'd rather add a few more fields for flexibility.

Re: Doom 64 style lighting improvements

Posted: Sun Nov 11, 2018 3:39 am
by Gez
How should gradients on 3D floor sides be handled? New flags in [wiki]Sector_Set3dFloor[/wiki]?

Re: Doom 64 style lighting improvements

Posted: Sun Nov 11, 2018 4:29 am
by Antnee
No flip_lower?
It would be a nice QOL feature, but as long as Flip_upper is there, it isn't strictly necessary. You could always just reverse the lighting order in the sector colors, achieving the same effect.

...but it would be nice time saver nonetheless