How to add lighting to classic maps legally?

[Graf Zahl]

but also to some extent the OS does, too. While Windows 8 and 10 are far less consuming of GPU resources than 7 was for obvious reasons, the same is not said of the Linux world. I don't know what kind of resources KDE and Cinnamon use, but they do seem GPU-heavy to me, and I have no idea if this plays well with games.

True, but in that case I am out of options. If the OS itself hogs a significant amount of GPU processing power that's no longer available to games we have a major problem that cannot be solved just by making the games less resource demanding.

With web browsers we have already reached a point where I have to close any tab with Javascript-heavy content to even be able to play any game without hiccups.

[Chris]

If we are a game, we are the only one using it!

Not really. The graphics driver has to process the calls you give it before sending them off to the GPU (this is improved with AZDO and Vulkan, but GZDoom doesn't use them yet, AFAIK), which is extra CPU processing. When you display a frame, you're giving it to the desktop manager which has to go and composite it, redrawing the desktop to show the updated window (a desktop that disables compositing for opaque fullscreen windows can help, but that's not a guarantee, especially if you don't play fullscreen). The audio service has to take the audio you give it and do its own processing (mixing, volume adjustments, etc) before it can be given to the audio driver to give to the audio hardware. While the game may just make a draw call, a SwapBuffers call, or write a chunk of mixed audio to an audio buffer, the system does more work before it gets to the hardware from the game.

It gets worse when you add things like video capture, streaming, or various real-time data probes. Even a modern game console can have dozens of threads/processing running in the background separate from the game itself (the Nintendo 3DS apparently has around 40 external processes, some more active than others).

The reality is different: On modern graphics hardware the GPU is actually mostly idle when running GZDoom. So the choice is not 10% more effects for twice the horsepower but 10x as many lights without having any performance impact at all. Unless, of course, you are the proud owner of an OpenGL 3 graphics card and would be shut out.

I consider myself to be fairly lucky in the video card department, with a GTX 650. Certainly not high end, but it's got a bit of horsepower to it, supporting things like OpenGL 4.6 and Vulkan. But it's also cut off a bit at the knees, since I have a rather weak CPU. The CPU can end up being the bottleneck in graphics-intensive scenarios even if the GPU is capable of keeping up, because the driver can't tell the GPU what to do fast enough. In a way, my GPU is too powerful for my CPU, though it does mean when I'm able to finally upgrade my CPU (which will also require upgrading the motherboard and memory at the same time), there'll be less pressure to immediately upgrade my GPU as well.

But lately when I see a lot of your posts, they seem to be of fear about anything other than whatever may presently be the status quo at the present time. If it's someone who complains about a change that's already been implemented you frame it in such a way that people don't like progress - but if it's a change that's yet to be made you have what seem to be strong concerns about it before it happens.

I apologize if I come across as obsessively cautious. It's not my intention to speak against future improvements. I just feel a bit of unease when a feature is tailored to a specific piece of hardware, not for its capabilities or because it represents the proper way to work, but just because it's modern. For example, take GZDoom's shadow mapping. There is a minimum requirement given its design, and that's fine, but the feature itself isn't tailored to a particular level of power. The shadow texture size can be lowered or raised to work on weaker or stronger devices. Similarly, AO has a minimum requirement, but it can be tuned low, medium, or high depending on the available power (the number of portal traversals for AO can also be configured). It tries to be somewhat accommodating.

When it comes to something like automatic placement dynamic lights in the original maps, I'm not sure a similar quality setting would be doable, which makes it a bit more difficult to be accommodating. So rather than just looking at what hardware is contemporary to set the target, IMO it would be better to work the other way around, find an acceptable look and use what you need to achieve it. I mean, if you can add a setting to scale up or down that would be great and ease my concerns, I just wouldn't presume such a thing to be feasible. And it'd be a shame for a potentially nice feature to be all-or-nothing given an arbitrary requirement.

[Graf Zahl]

If we are a game, we are the only one using it!

Not really. The graphics driver has to process the calls you give it before sending them off to the GPU (this is improved with AZDO and Vulkan, but GZDoom doesn't use them yet, AFAIK), which is extra CPU processing. When you display a frame, you're giving it to the desktop manager which has to go and composite it, redrawing the desktop to show the updated window (a desktop that disables compositing for opaque fullscreen windows can help, but that's not a guarantee, especially if you don't play fullscreen). The audio service has to take the audio you give it and do its own processing (mixing, volume adjustments, etc) before it can be given to the audio driver to give to the audio hardware. While the game may just make a draw call, a SwapBuffers call, or write a chunk of mixed audio to an audio buffer, the system does more work before it gets to the hardware from the game.

GZdoom right now doesn't even fully use 2 CPU cores, including the driver overhead. However, if I say that more lights require little CPU power I mean just that. It needs a bit more to upload more data to the GPU but there aren't any more draw calls or state changes for more lights. It's just that the shader has more work to do to use the provided data.

And that's for a high end map. For IWAD stuff none of these concerns are even remotely relevant.

[Caligari87]

Performance questions aside, I would be interested to see how feasible it would be to light the IWAD maps entirely with dynamic lights (sector lighting set to zero, except perhaps daylight outdoor areas). I proposed a dynamic solution in Discord a while back that involved placing lights in a coarse grid pattern and sampling the surrounding illumination / textures with linetraces to get an intensity and color for the "ambient" light. Combined with iterating over linedefs and sectors to place lights according to textures and flats (perhaps even with a customizable "density" aka minimum light spacing), good results could be achieved. I'm sure someone smarter than me could come up with a better "algorithm" but I think the basic idea is sound.

[Nash]

There's one small problem with setting sector brightnesses to 0... textured automap will show nothing but black tiles. :(

[Rachael]

There's one small problem with setting sector brightnesses to 0... textured automap will show nothing but black tiles.

Yeah - about that...

The higher level code in softpoly is loosely based on the textured automap, if I understand correctly. Maybe it might be possible to port back that code with the dynamic lights attached?

I think only dpJudas would know how possible that is, though.

[dpJudas]

As far as I know, it is the 2D drawer that draws the automap. Generally speaking, the 2D HUD drawing code in both the software renderer and softpoly could be thrown into the dumpster and just use the GL renderer for it. There's really no reason why there are three implementations there even today.

[Graf Zahl]

That has already happened half a year ago when the render backends were consolidated.

[dpJudas]

I was thinking of the render playersprites code in r_playersprite.cpp and poly_playersprite.cpp. I don't see any particular reason why that would differ between the three renderers. In the really old days they were needed by the Linux port and the fuzz effect, but not any more.

[Graf Zahl]

I didn't consolidate those because they are not fully identical, mostly related to how lighting works. It's not really that bad, because the software renderer's code just ends up in a single 'DrawTexture' call. The GL code still uses its own special implementation.

[Kinsie]

I'm somewhat cautious about including this in the engine, because a lot of people will turn it on the first time they see the option (effectively making it a new default), which would be a real pity if a pig's ear was made of the project like with Duke 3D 20th Anniversary World Tour.

[Enjay]

While I get what you are saying, I'm also not convinced that stepping back from a potentially very nice feature just because some people might cock it up for themselves is a particularly good way forward either.

And let's hope - if it's done - that a pig [cop]'s ear isn't made of it anyway.

[Kinsie]

While I get what you are saying, I'm also not convinced that stepping back from a potentially very nice feature just because some people might cock it up for themselves is a particularly good way forward either.

I'm not necessarily saying to step it back, I'm saying to be a bit cautious about it. I feel like the key is subtlety and, say, replacing sector-light effects like the lamp-casting in MAP03 with actual lights. You can do a lot with a little.

In addition, I think it might be worthwhile (more or less worthwhile than this, who can say) to develop a ZScript-based system (possibly with one of those fancy custom lump parser things like what Lithium constantly uses) ala compatibility.txt for lightweight third-party map augmentations in the same vein as eDuke's maphacks.