Brightmaps: Topic Resurrection

[phi108]

Yeah, there are still strange wavy rendering problems with brightmaps on my machine, but when I change resolutions, it's fixed.

But could there be a hardware or graphics problem that just keeps textures from working at all? It seems so, because I'm sure my format is correct.

[Wagi]

What's the reason behind not being able to have lightmaps in software rendering? Is it just too complicated to implement or is it just flat-out impossible?

[XutaWoo]

Considering it's lacking OpenGL, or even something more basic that supports stuff like that., I'd say impossible.

[phi108]

This is why I want A_GunFlash for monsters, so Instead of brightening certain areas of the sprite, it leaves the whole sprite dark dark and draws a new sprite on top that is fullbright. This fullbright sprite would be the same size as the base but it would just have the muzzle area drawn and the rest would be transparent, so the dark sprite shows from underneath.

I know that multiple sprites can be drawn on a hud weapon with A_GunFlash, but I don't think there is any way to draw multiple sprites at one time on a monster actor.

[bagheadspidey]

Why would it be impossible just because of no OpenGL? If randy managed to add additive, subtractive rendering styles, etc, couldn't the brightmaps be applied using one of those filters? If not, couldn't a new zdoom-only filter only to be used for applying brightmaps be created?

[Graf Zahl]

The software renderer lacks any kind of intelligence concerning lighting. It is all colormap-driven so in order to achieve this the code has to be changed considerably.

[HotWax]

Why would it be impossible just because of no OpenGL? If randy managed to add additive, subtractive rendering styles, etc, couldn't the brightmaps be applied using one of those filters? If not, couldn't a new zdoom-only filter only to be used for applying brightmaps be created?

None of the filters ZDoom supports don't change the fact that it does single-pass rendering on the sprite. i.e. it takes one brightness level and one colormap and one filter (optionally) and applies it across the entire image. That's why you'll never see an enemy straddling a sector in such a way that they are half colored and half not, or half in shadow and half in light. It's also why you can't have an enemy that has transparent areas while other parts are solid. With lightmaps, you'd have to change the rendering code drastically to support performing a multi-pass on the sprite or the ability to change lighting from one pixel to the next.

GZDoom of course has the benefit of OpenGL rendering, which has tools for doing these things directly built in.

[phi108]

Again, the solution is drawing two sprites for the firing frames of a monster. I guess it would require new decorate, but perhaps there could be an "overlaysprite" namespace or something, and the sprites there are the same name as the sprites they go on top of, and they are drawn fullbright, while the sprite underneath them is left dark. They would be just like brightmaps PNGs, except in color and with transparency and in doom sprite format in a wad.

[Nash]

Again, the solution is drawing two sprites for the firing frames of a monster. I guess it would require new decorate, but perhaps there could be an "overlaysprite" namespace or something, and the sprites there are the same name as the sprites they go on top of, and they are drawn fullbright, while the sprite underneath them is left dark. They would be just like brightmaps PNGs, except in color and with transparency and in doom sprite format in a wad.

Maybe doing this with the code is not as easy as you think it is... ?

[phi108]

Ha, yeah I forgot about that issue. That last post made it a bit much, but I still wonder about A_GunFlash.

[HotWax]

Ha, yeah I forgot about that issue. That last post made it a bit much, but I still wonder about A_GunFlash.

A_GunFlash works because the gun has a clear spot in the drawing priority for sprites. The world is drawn, then the gun, then the gunflash (if present), then the HUD. To implement this the way you want it, sprites in the game world would need a clear-defined draw priority, which Graf has pointed out does not exist in a form capable of allowing this to happen consistently.

What you seem to be assuming is that A_GunFlash causes a single entity (namely, the player's gun) to be drawn with 2 sprites, when in actuality the two images are very separate items and the gun flash effect is a hack which simply draws the flash over the gun, both of which are fixed in location on the screen. It's not nearly as simple when you're talking about an object with AI that will be moving throughout the world and can be observed from multiple angles.

[phi108]

I ALMOST have a working method for a software brightmap effect. Load the attached wad in e1m1 UV and check out the shotgunguys.

I removed BRIGHT from the shotgunguy (replaced with DarkShotgunguy), and I put an A_CustomMissile in his missle state.

The CustomMissile is BrightShotgunguy, a missle with sprites that are transparent except for the bright spots of the ShotgunGuy's sprites. THESE sprites have the BRIGHT aplied to them.

There are various problems. I had to give the missile a speed (.1) to make it face the player, but this makes the bright spots separate from the shotgunguy as he fires. And the missle stays around for 10 tics when the shotgunguy enters the pain state or is killed while firing.

[Project Shadowcat]

That's pretty friggin' neat, but there lies one critical flaw; when the shotgunner is injured in mid-fire, that over-lapping sprite will still linger. It's a trippy -- almost ghostly effect when the light shine is still there for roughly .2 second and the body's hit the floor.


ED: Then it hit me; expand the firing frame to ten identical frames -- one per tic -- each doing that flash. Then you will not have that problem.
The only problem then would be bloating code.

[phi108]

Yeah my EDIT didn't work. The bright sprites stay for 10 tics no matter what. How can I make it behave the same as the shotgunguy? MAkle the missle a monster with +DONTCOUNT and the same painchance?

EDIT: And would your suggestion mean each tic of DarkShotgunguy firing would summon a 1 tic BrightShotgunguy?

[Project Shadowcat]

If using my strategy, make sure its state lasts exactly one tic as the new shotgunner "launches" a new one each tic.

Re ED: YES.