About dynamic lighting

1) Is there a software renderer with dynamic lighting? Can it be done?

2) Is there a source port that has lights that get properly blocked by walls? In GzDoom the light shines through the walls to the neighbouring rooms and it looks clunky and even more out of place.

Doom Legacy has dynamic lighting in software IIRC.

Linguica said:

Doom Legacy has dynamic lighting in software IIRC.

Did you write that with a straight face? :-D

...what? It did at one point long ago, in any event http://www.doomworld.com/mailbag/092998.php

VGA said:

2) Is there a source port that has lights that get properly blocked by walls? In GzDoom the light shines through the walls to the neighbouring rooms and it looks clunky and even more out of place.

Doomsday's dynamic light clipping is better than GZDoom's, though as a result slower (the better the clipping, the more work the engine has to do). Though it's still not perfect.

Doom Legacy is a clusterfuck, especially on Windows, I tested it and saw no dynamic lights in the software renderer, it must be in the hardware renderer.

I'm gonna keep an eye out for the newer bugfix release of Doomsday and will install it when it's out. Still no portable release, huh?

VGA said:

1) Is there a software renderer with dynamic lighting? Can it be done?

Vavoom. Though the last version of Vavoom does not have the software renderer anymore, so you need to get the previous one.

There is a ray-traced experiment called DoomTracer.

VGA said:

1) Is there a software renderer with dynamic lighting? Can it be done?
.

GoldSrc engine has the ability to load dynamic lights in software renderer,not sure if it can be done with DOOM Engine ..

VGA said:

1) Is there a software renderer with dynamic lighting? Can it be done?

If your not concerned about it being a literal software renderer, Doomsday can be made to look almost (there are a couple of visual elements of the software renderer Dday can't emulate) like a software renderer would, via it's renderer appearance menu.

http://postimg.org/image/hfk31bq5x/full/

In the above screenshot I've made a new rendering profile in Dday's renderer appearance menu, by copying the built in 'Vanilla' rendering profile (hence why I named my new profile 'Vanilla with dynamic lights') and then turned on dynamic lights (located under the 'point lighting' sub section).

Given Dday uses profiles for visual settings, one can toggle back and forth between various visual setups in an instant.

I installed Doomsday yesterday, pointed it to doom2.wad, started it, read the tutorials and I had some microfreezes/lags while moving around in map01 so I immediately uninstalled it.

This is the third/fourth time I've installed DD and instantly got rid of it. I'll check it again when some major update comes. Does it support Boom maps?

VGA said:

I installed Doomsday yesterday, pointed it to doom2.wad, started it, read the tutorials and I had some microfreezes/lags while moving around in map01 so I immediately uninstalled it.

Most likely these are the result of having to quickly prepare resources that weren't cached before the map began. Improving the precaching is something we intend to do once the rest of the game side UI systems (menu, intermission, etc...) have been reimplemented to use the 2.0 UI system (used in Renderer Appearance menu, seen in Vermil's screenshot above).

Does it support Boom maps?

Not yet, no.

Doomsday doesn't support Boom maps, though work is progressing on that front.

As for the micro lag, it sounds like Dday is unable to precache resources (sprites, audio etc) quickly enough on your computer or there isn't enough free memory to store them.

EDIT: Beaten to it :p

For my tastes, I'd go for the vanilla profile and just enable a couple of things from there ... when I reinstall some newer version in a few months I guess.

But not having boom compatibility is a problem, it limits the playable Doom content a lot. Also, I don't trust Doomsday to properly work with vanilla mapping tricks that are used in many vanilla megawads. I'm afraid I would constantly lose time and have to cheat my way through maps.

Even Zdoom doesn't have 100% boom compatibility or 100% vanilla compatibility, I don't want to imagine how Doomsday would fare.

EDIT: I'm on a Core 2 Duo e8400, 4gb RAM, gtx260, if it can't cache map01 of doom2 with the default options within a few seconds then ... wtf. From a user perspective why should I even care about that? I hope it's gonna get improved on that front.

Those kind of 'hitches' are not really about how long it takes to cache individual resources. The problem is that many of them aren't being precached, forcing the engine to cache them just-in-time, when necessary.

The difference between Doomsday and a more traditional, software-rendering port is that most of the DOOM resources are not in a format that is suitable for immediate use. The data formats used in the IWADs were designed specifically for the needs of the software renderer (obviously) and consequently, hardware-rendering ports have to jump through a great many hoops to convert this into something usable.

Given that the majority of the resource data is already in a format suitable for rendering in software, DOOM has virtually zero caching logic because its unnecessary.

Linguica said:

...what? It did at one point long ago, in any event http://www.doomworld.com/mailbag/092998.php

Unfortunately it was never finished for software, and was pushed to glLegacy instead.

Other goodies Fab and Boris attempted:

* Floor decals
* Unreal-style texture filtering (prboom has this now)
* "stackable" things

It's likely that "dynamic lighting" would have been done like the floor and wall decal code, given that legacy's decal code was fast enough to handle it on a 233MHz (and even a P200) - but the implementation of floor decals per subsector may have proven too difficult to pull off given the massive amount of power required (procedural textures on the floor?). Most of that code is commented/stubbed out.

There was talk back in the IRC days of torches "spraying" bright decals near walls that would decrease in size with distance, but that really isn't "dynamic" lighting, is it?

Csonicgo said:

There was talk back in the IRC days of torches "spraying" bright decals near walls that would decrease in size with distance, but that really isn't "dynamic" lighting, is it?

...yes? What else would one call it? "Fake" lighting? All the lighting is fake, really.

Maybe it's only "really" dynamic if it can be applied on moving objects/projectiles.

Csonicgo said:

There was talk back in the IRC days of torches "spraying" bright decals near walls that would decrease in size with distance, but that really isn't "dynamic" lighting, is it?

That's essentially what the dynamic lighting in GL Legacy was doing.

From what I remember, the dynamic lighting in DoomLegacy is done with GL calls. It only for the hardware renderer. Interesting that it has the same problem with walls not blocking the lights, because the GL calls do not know they are walls, they must only look at the depth buffer and screen position.

I have been considering how to make it work in the software renderer.
Doing it in the software renderer would be entirely different because there is no depth buffer for the screen. The lighting would have to be done before drawing the walls and flats. It probably would be able to have the walls block the lights though.