ZDoom

If this were to be done, the best option would to be to go the way of light sourcing in Rise of the Triad. (Radial, colormap-based lighting.)

It's probably the closest you'd get to the Doom software renderer to compare to.

[quote="Graf Zahl"]That will never work with the 8 bit software renderer simply due to lack of needed colors.[/quote]

Then it would work just like quake 2 lights, colored for opengl and white/black for software.

IF the lights were fixed sized and would never change, it would be easier, but, it could create a texture buffer just to store the textures of the places with dynamic light, apply that circle sprite as a brightmap and tadah, you got a dynamic light :D but the limitation for that result would be the management form that extra textures AND a way to bright up sprites/voxels on that area (on my method, it would only birght up floors and ceiling/walls).

At least it would be a start for software users [size=60]Use Gzdoom, give up from zdoom and his pentium mmx render era, come back to the new world and feel the beauty of opengl. Unless you have a pentium mmx with a voodoo [/size]
Why can't I use a 50 size font? its the tinny config '-'

Extralight brightens everything. Dynamic lighting as defined in GZDoom consists of localized pointlights that only brighten their surrounding.

[quote="Revanic"]The only thing I am really suggesting here is taking what little "fake" dynamic lighting software mode has and expand upon it in some way.[/quote]There isn't any, so there's nothing to expand on.

The only thing I am really suggesting here is taking what little "fake" dynamic lighting software mode has and expand upon it in some way. Colored lighting is not necessary for this, nor is overbrightening.

I would love some Quake overbrighting. Too bad >255 sector light already has a "defined" behavior - Not that there couldn't be a new sector flag to enable overbrighting.

You can kind of fake it with sector fades currently, but that's a pain in the arse. (And can't quite work properly with light specials, if you need to transition from overbright to darkened.)

I am sort of leaning towards the white-light idea as well. How hard would it be to add overbright to ZDoom, I wonder?

If dynamic lights are limited to white light, it could work with an overbright colormap. If I'm not mistaken, Quake used something like that.

All the examples of dynamic light in original software renderers (not advanced ports written over a decade after the game) that I remember were limited to white light.

That will never work with the 8 bit software renderer simply due to lack of needed colors.

I wouldn't consider method 1 as dynamic lighting since it would be just range for a_light (which on itself isn't a bad idea).

I was thinking about this: The light would be image which would be drawn and the tilted to the floor and walls on top of the scene. (wait, isn't that something like GZDoom?)
Something like this:
(maybe not) possible result: https://www.dropbox.com/s/vqxi53maak1h8ok/Light%20A.png?dl=0
Lighting tilted: https://www.dropbox.com/s/z3w4vnf7hgrtbax/Light%20B.png?dl=0
Combined picture: https://www.dropbox.com/s/t395uqesgyttvvh/Light%20C.png?dl=0

But I am not even thinking about dreaming that something like this would even be attempted.

[quote="Revanic"]I believe a few Build engine games did something like this.[/quote]
If you're thinking of the flare in Blood, it does it by adding extra round, see-through flat sprites to the render list for each flare sprite that was visible from drawrooms and within a certain distance of a floor or ceiling.

I thought of 2 ways to simulate dynamic lights in software mode that shouldn't have much more of an impact on resources/fps as DooM's regular dynamic lighting ( Weapon flash).

[b]Method 1[/b]
The easiest of the two.
Essentially just adding the light values to the player's extralight (like weapon light), or something similar, possibly attenuated by distance from the player (because a monster attacking another far away from the player shouldn't just randomly light up all the sectors). You would get the illusion of a dynamic light as the lit object would approach you. May be able to determine attenuation through the defined lights in lights.pk3. I believe a few Build engine games did something like this.

[s][b]Method 2[/b]
More correct (but not totally), and [i]possibly[/i] more resource intensive, though I do not know by how much. Should be cheaper than GZDoom's dynamic lights still.
You would treat each light casting thing like how light is treated for the [i]player's view[/i], but disregard all sector lighting (treating it like its all at 0), and then add it on top of the default lighting. This will look pretty good and allow the player to see dynamic lights from anywhere, however the lighting would have no Z attenuation, meaning the floor and ceiling will have the same brightness created around the object regardless of height difference. Would be better than nothing though. Could definitely use the lights from the lights.pk3 in this one.[/s]

Edit: Actually the above is wrong. Something similar can be done, but just not the way I suggested it exactly. I guess for now I am only suggesting [b]Method 1[/b].

Just an idea. I may try coding either of these myself if I can get the source to compile.