Doom 64 style lighting improvements
Moderator: GZDoom Developers
Re: Doom 64 style lighting improvements
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.
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
I'll agree, I'll try.
Re: Doom 64 style lighting improvements
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.
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.
- drfrag
- Vintage GZDoom Developer
- Posts: 3141
- Joined: Fri Apr 23, 2004 3:51 am
- Location: Spain
- Contact:
Re: Doom 64 style lighting improvements
That looks interesting, a recent OGL to D3D wrapper. Where can i get the 32 bit version and more info about that driver?Rachael wrote:This is the 64-bit Mesa Gallium driver, which redirects OpenGL calls to Direct3D.
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.Erick194 wrote:but force the port to 4.4 and enable those shaders without problems
About mesa for windows i never got that one to work with render buffers enabled.
Re: Doom 64 style lighting improvements
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.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?
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
That is good to hear. At least now your hardware isn't what's holding you back, for now.Erick194 wrote: This is interesting now I can do tests, with the recent version.
Re: Doom 64 style lighting improvements
Actually I've done several things with Gzdoom 1.9 you can see in the Doomworld forumsdrfrag wrote:That looks interesting, a recent OGL to D3D wrapper. Where can i get the 32 bit version and more info about that driver?Rachael wrote:This is the 64-bit Mesa Gallium driver, which redirects OpenGL calls to Direct3D.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.
https://www.doomworld.com/forum/topic/9 ... r-edition/
you're rightRachael wrote: That is good to hear. At least now your hardware isn't what's holding you back, for now.
- drfrag
- Vintage GZDoom Developer
- Posts: 3141
- Joined: Fri Apr 23, 2004 3:51 am
- Location: Spain
- Contact:
Re: Doom 64 style lighting improvements
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.Rachael wrote:Try this
Mesa for windows is extremely slow without glversion 2 BTW.
Re: Doom 64 style lighting improvements
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.
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.
-
-
- Posts: 374
- Joined: Mon Jun 27, 2016 7:26 pm
- Preferred Pronouns: He/Him
- Graphics Processor: nVidia with Vulkan support
- Contact:
Re: Doom 64 style lighting improvements
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.
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
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)
}
}
}
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49067
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Doom 64 style lighting improvements
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.
I also remember there was something about restricting the gradient to the actual wall tier and not only from front ceiling to front floor.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49067
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Doom 64 style lighting improvements
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.Talon1024 wrote:The Doom 64 Tech Bible is here.
Re: Doom 64 style lighting improvements
How should gradients on 3D floor sides be handled? New flags in [wiki]Sector_Set3dFloor[/wiki]?
Re: Doom 64 style lighting improvements
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.No flip_lower?
...but it would be nice time saver nonetheless