Fri Dec 25, 2020 5:08 am
Both in latest GZDoom and LZDoom. I was playing DYINCAM3.wad and in MAP09 the game almost froze, stat think peaks at 170ms and there are less than 400 monsters.
With profilethinkers most of the time is taken by InternalDynamicLight, i guess becouse the architecture is a bit complex in that area.
To reproduce it warp to -150 -2700, turn around, press the button and fire. When the monsters teleport in i get 1 fps on my machine. Turning dynamic lights off doesn't make any difference in performance only that you don't see them. Is this a bug? The only way to prevent the slowdown is not loading lights.pk3.
The wad is DyingCamel's Demons #3: https://www.doomworld.com/idgames/level ... s/dyincam3
Fri Dec 25, 2020 5:54 am
That room has > 6000 lines and > 2000 flats being rendered - and then adds a slaughter-style invasion to the mix. It's not surprising that this tanks performance quite efficiently.
The small detail on those pillars is a bit excessive.
Last edited by Graf Zahl on Fri Dec 25, 2020 5:55 am, edited 1 time in total.
Fri Dec 25, 2020 5:55 am
There's obtusely hypercomplex geometry in that room and it seems that yes, lights completely tank the framerate around them.
I wonder if this may be related to massive slowdowns in other maps with excessive sector overdetailing, like bastion of chaos.
Fri Dec 25, 2020 6:35 am
Sorry but that won't work. You're introducing rendering data into the game sim here. That's a recipe for disaster with demo/multiplayer desyncs and stuff.
Fri Dec 25, 2020 6:51 am
Oops. Then i guess i need another server CVAR.
Fri Dec 25, 2020 7:15 am
Dynamic lights are not part of the playsim, not even the thinker part. They just need to be ticked there if active. I think the real issue here is that the lights get created even when the CVARs are off.
Fri Dec 25, 2020 9:18 am
Of course, then no need for the server CVAR.
Mon Jan 04, 2021 5:14 pm
So I guess the issue of lights themselves tanking can't be solved?
Tue Jan 05, 2021 4:20 am
What do you mean? In the end i used a CVAR (but not a server CVAR) to prevent them from ticking when not active. Destroying and recreating them everytime you change the option sounds more complicated and may be could lead to problems.
Tue Jan 05, 2021 6:59 am
The way I am interpreting things is that Graf said I was wrong to worry about what happens to the playsim concerning the lights, but that they still should not even be created if they are turned off. If what Graf said is true, it should not cause any problems at all to destroy them when they are not in use.
Tue Jan 05, 2021 7:55 am
Now they are created once when you autoload lights.pk3 i believe. With that approach you have to destroy and recreate them everytime the user changes the option in the menu so it's not as simple as before.
Tue Jan 05, 2021 8:38 am
That's ... not how it works at all.
Loading lights.pk3 only pulls in the definitions for them. The map objects and thinkers are responsible for their creation and destruction as appropriate, as defined by loading the definitions.
Tue Jan 05, 2021 1:49 pm
So you need the definitions... most of them will be still created at once right? Or may be it happens when you look at them? What happens if you try to destroy them when they have not been created yet? Or if you try to create them before they've been destroyed? And that about the overhead? How much time would it take? I dunno, just some thoughts.
Tue Jan 05, 2021 2:06 pm
The definitions are just that: inactive data. But if you have no definitions there won't be any lights that are created from them.
Powered by phpBB © phpBB Group.
phpBB Mobile / SEO by Artodia.