DRD Team

1. Start "gzdoom.exe -iwad doom2.wad -file lag_test.wad lights.pk3".
2. Observe 1260 shotgunguy's. Watch how smooth your fps, for now.
3. Wake them up and note huge fps drop (it's ok).
4. Kill them using any weapon.
All dead, but your fps is still low.

Reproduce same steps, but kill them with "kill shotgunguy" in console.
All dead, but fps is still smooth.

http://www.mediafire.com/download/23po5 ... g_test.wad

Same here with development build 2.1.pre-1307-g4e1723e. It looks like the dynamic light objects, though invisible, remain in the world after being created (they'll remain as long as their creators exist in the world). If you turn dynamic lights off, the objects get removed and thus the framerate goes back to normal. Turning them back on, doesn't restore the objects, though, so the framerate stays at normal level.

It's been like this for a long while. You can notice it with iddtiddt: look at the map and you'll see the player arrow. Fire a weapon, and a triangle appears, corresponding to the dynlight. It stays there.

Move a bit, and fire again: the earlier triangle disappears but a new one has appeared at your new position, which will also remain there until you fire again and it's replaced by another.

Oukay. Now i understand how dynamic lights implemented. But still can't understand why same actor (corpse in this example) produce "invisible" light when killed after been "woken", and it dosen't when "kill" command used.
Sorry if i disturbing you with something oblivious, but i'am confused about this.

P.S. How about some render distance cvars ? (3d model-to-sprites, dynamic lights, sprites, geometry, hirestextures-to-lowres) so engine performance can be adjusted.

The reason is actually quite simple: Constantly deleting and respawning the dynamic light actors is rather expensive. So any actor that has a light will just keep the actor around, because the engine cannot decide whether it may not be needed anymore.

What I do not understand is how these can actually affect performance. They are completely inert and do not move so they shouldn't cause that much processing overhead.

It appears that the slowdown first happened when the engine was changed to gzdoom-G1.9

Be more precise. That's too vague.

I found some more GZDoom downloads on another drive. The slowdown happens earlier than gzdoom-G1.9.

gzdoom_1-8-04 does not slow down
gzdoom_1-8-05 I do not have
gzdoom_1-8-06 does slow down

Yuck! That's still 8 months of changes...

BTW, 1.9 is NOT newer than any of those. There has never been an 1.9 version. 1.9pre is just how the devbuilds parallel to 1.8 were named.

Well, ok, I know what the problem is. Some people insisted on adding an 'isVisibleToPlayer' check to the dynlight code. The only problem here is that this function is INCREDIBLY costly and unsuitable for what it's being used here - because it needs to be called for every light in the game affecting every sprite it may touch.

This also explains why I noticed some (far less pronounced) performance degradation on some maps I played recently.

So it's either breaking that feature or having lag. Argh! For now I'm taking this out, it's far too rarely used, the performance degradation is the bigger problem here.

For the sake of interest, tested gzdoom_1-8-04 and gzdoom_1-8-06 with heavy mods (BrutalDoom \ Russian Overkill) + slaughter-like maps (map28, CommunityChest3 \ map28 SpeedOfDoom).
gzdoom_1-8-04 have at least twice more FPS than gzdoom_1-8-06.

With your test map and all monsters dead, the time to render sprites was actually 10 times what it should have been - and all for calling a function that in most cases doesn't do anything at all! The slowdown is most likely related to the CPU instruction cache, I can't explain any other way why the impact was this severe.

Got it. So what the final of this discussion ? You disabling \ cut off this function ?

For now it's disabled. I need to do some checks if it can be optimized. The current setup for the check is total overkill.

Changed this so that ADynamicLight::Tick calculates the visibility state. That should eliminate the problem because all it requires in the critical render code is a simple check, plus the function will be called a lot less often.