GzDoom produces project slide like lags on slaughterfest wad

[cs89]

I started a slaughterfest wad (Slaughterfest 2012) with Colorful Hell and Russian Overkill because I thought this combo would be so much fun. On the first five level there were not performance loss, but on the later maps I got some lags by a lot of particle effects.
I have a PC with Intel Core i5 7500 CPU, Geforce GTX1060 6GB GPU, a Kingston HyperX Savage SSD and 2*8 GB DDR4 2400 Mhz Ram.
I doubt this configuration would suffer performance loss from very large maps with 500-1500 monsters. I get worse and worse lags when I fire any of 5 superweapons to a demon invasion.
There are any tips to reduce effectively the lags inside GzDoom? The priority setting would help to increase performance?

[Graf Zahl]

The problem is not the number of monsters but more likely the mods you are using. Some replace stock monsters with heavily scripted variants, and that can take a heavy toll on the engine if there's too many of them.

[Kinsie]

In addition, Russian Overkill's weapons throw around a lot of effects that also have a bunch of scripting behind them.

Mods aren't necessarily coded in the most-efficient ways, and the gameplay part of the engine runs on a single CPU core for this-is-still-technically-a-game-from-1993 reasons, which is why you can still run into FPS issues while running on a supercomputer cooled by an arctic glacier.

[Apeirogon]

this-is-still-technically-a-game-from-1993

Why is this so? Something related to bsp or inner logic?

[wildweasel]

this-is-still-technically-a-game-from-1993

Why is this so? Something related to bsp or inner logic?

Inner logic. Remember that Doom was written before we'd really figured out stuff like parallel processing, and at the time, nobody really had a reason to have more than a hundred-some actors doing their thing at a time, so for the purposes of the original Doom, simply running down the list of stuff in the level and processing it one-by-one was perfectly fine. Modern maps are pushing hundreds, if not thousands, of monsters, their projectiles, their behavior, more complicated collision data (remember GZDoom has to make sure they know how to process stuff like 3D floors, polyobjects, and other constructs not possible in vanilla), and a lot of other things. Then consider that a projectile in a modern Doom mod is a lot more than just a single moving sprite, usually throwing off particle effects (each particle is an actor in itself, and a fancy explosion effect could be throwing out 30+ of those). If it's a FastProjectile, it's running its collision checks several times per tic to make sure it's not going to bypass a wall that it's not supposed to get through. If it's a Russian Overkill projectile, it's probably doing all that and more, and the game is still just going down the list of active actors one-by-one, only the list is now roughly a thousand times as long as it was in 1993.

And because Doom's game logic heavily relies on everything being in sync (exponentially true for multiplayer games), it all has to run on a single core, which is why your shiny new AMD Threadripper Turbo Ultra Deluxe Vantablack Edition with its 1,024 cores doesn't do it any faster than last year's model.

[Apeirogon]

So to teach gzdoom how to throw bunch of actors in different cores require rewriting almost all engine?!

[_mental_]

Exactly. Modern game engines are designed around multithreading from ground up.
Of course someone can make "multi-core" GZDoom by creating bunch of worker threads and guarding every shared variable withing gameplay code. This only makes everything slower and much more buggy.

[Graf Zahl]

It wouldn't all be that bad if not every single actor being checked would directly manipulate each other it somehow affects. If all manipulations were routed through a network stream, for example, a lot could be done here. But as things stand, the only thing on the playsim side that could theoretically be offloaded to a worker thread is the particle processor, but that doesn't normally run for a significant amount of time to be worth it.