Glowmaps

Epoch · Post by **Epoch** » Wed Mar 08, 2006 16:01

Would it be possible to implement glowmaps in GZdoom?
What I mean is make it so some parts of sprites (specifically the orange glow from the muzzle flash on zombie) always stay a certain minimum brightness, thereby allowing people to do away with the fullbright crap. This could be defined using "replacement" sprites between G_Start and G_End markers, similar to hires stuff.

YouTube · Post by **Nash** » Wed Mar 08, 2006 19:17

You can achieve a similar effect by removing the fullbright flag from the zombiemen attacking animations, and attaching a carefully-sized dynamic light to it...

Post by **Enjay** » Wed Mar 08, 2006 19:45

I'd like this effect (not bothered how it's implemented) for textures too - imagine textures with glowing lamps - but only the lamps - or little red dots on computery/techy textures or...

I know that, again, it could be done with a dynamic light, but I'd like to be able to specify a texture to behave like that all over a level without having to place a dynamic light each time.

Post by **Graf Zahl** » Wed Mar 08, 2006 20:14

Yeah, I think I have to get some software shader stuff working eventually...

YouTube · Post by **Nash** » Thu Mar 09, 2006 2:48

Graf Zahl wrote:software shader stuff

That's the good news.

Epoch · Post by **Epoch** » Fri Mar 10, 2006 1:27

The shader stuff is good news.

As for the tiny lights, that wouldn't work.
The lights would light the entire thing, instead of say, just the bright orange part.

Shinjanji · Post by **Shinjanji** » Fri Mar 10, 2006 7:24

Epoch wrote:As for the tiny lights, that wouldn't work.
The lights would light the entire thing, instead of say, just the bright orange part.

Why not? Just make the background black, and use additive transparency. That's how many modern games do it.

Post by **Graf Zahl** » Fri Mar 10, 2006 10:36

Actually, that's the only way to do it.

Regarding the shaders, I have looked through ZDoomGL's code. I think I can do most of the stuff without problems. The only thing that won't work 100% is some exotic blending mode combinations with fog so I think I will restrict this to the safe combinations for now.

Caligari_87 · Post by **Caligari_87** » Fri Mar 10, 2006 15:34

I don't know how easy this would be, but for sprites, if the frame is tagged BRIGHT, just use the average of the most intense pixels, and light the sprite and level accordingly

Post by **Graf Zahl** » Fri Mar 10, 2006 16:05

No Doomsday-like guesswork. I really don't like that stuff.

YouTube · Post by **Nash** » Fri Mar 10, 2006 18:06

Yeah, that sounds a little bit clumsy, Caligari.

Most of the Spidermastermind's pixels are quite "bright" in colour. That's enough to cause some confusion.

DaniJ · Post by **DaniJ** » Sat Mar 11, 2006 0:17

The reason Doomsday has routines like that are to save the modder work and to add effects to resources it doesn't have definitions for. If the automatically determined values aren't what you're looking for OR they aren't "correct" - then use a DED to set them how you want.

Considering that the automatical determination of the light's origin returns correct results 90% of the time, without ANY user intervention I feel it is a very useful feature.

For example I can play old TC's like AliensTC and the lamps all have lights & halos in the correct places.

Post by **Graf Zahl** » Sat Mar 11, 2006 1:12

DaniJ wrote: Considering that the automatical determination of the light's origin returns correct results 90% of the time, without ANY user intervention I feel it is a very useful feature.

It would be more useful if it wasn't on by default with no way to switch it off easily. But last time I checked it was all or nothing. Either you have to bother with the automatic lights or have no lights at all. It got really nasty with the Doom64 TC. It had to have lights on due to the glows but as a result all the pickup items which were bright so that they weren't affected by the colored light also emitted some lights which looked rather odd.

DaniJ · Post by **DaniJ** » Sat Mar 11, 2006 1:55

It would be more useful if it wasn't on by default with no way to switch it off easily.

I agree there should be a way to disable the automatical calculations. I'll add a CVAR to control this for 1.9.0

It would be nice to disable lights on full-bright objects on a per-object basis too, so I'll implement a new MF_NOLIGHTS flag also.

It got really nasty with the Doom64 TC. It had to have lights on due to the glows but as a result all the pickup items which were bright so that they weren't affected by the colored light also emitted some lights which looked rather odd.

Yes, from what I've heard from Kaiser this was one of the reasons he created Absolution.EXE rather than keep D64TC as a dll... rather OTT IMO. He should have simply made an RFE about that and I'm sure Skyjake would have implemented a CVAR in an earlier version.

The fact that D64TC decided to make ALL items full-bright was a rather strange decision in my book but given how odd the lighting in the original D64 is - I can understand why.

---

I'm sorry for my outburst over at DW. Now that I've calmed down a bit, I do think I overreacted somewhat but I hope you understand why I did react.