[2.3.2 and up] Particle rendering slowness

[PillowBlaster]

I'd report this sooner if I didn't think I was seeing things or thought that it was my own fault, given that mods tend to get complex and more resource-intensive over time, but after commiting to actual tests instead of relying on a feeling, I am convinced that this is an actual engine-related problem. Take note I didn't test this on zdoom\software mode as I am talking truecolor sprites with translucent areas here. That'd work ugly with software mode by default.

At some point I could've sworn that the particle effects that got cooked up back in the day didn't lag as badly, especially when stared at from up close. KeksDose and I performed some tests, here are some screenshots proving there is something wrong here - check the fps counter in the top right corner. I have a medium-end laptop from 2015; this used to work at 60fps on a milquetoast computer from 2013. I did update my drivers. No change here.

---

OS: Windows 10 64-bit
Processor: Intel Core i7-4702MQ CPU @ 2.20GHz 2.19GHz
VGA: NVidia GeForce 840M (DDR3, 2k MHz, 2048 MB)
RAM: 8,00 GB

Gzdoom 2.1.1 works fine. Also tested but not pictured is 1.8.6 - also works as intended there.


Gzdoom. 2.3.2 is where I noticed things go haywire; I didn't test any versions inbetween 2.1.1 and 2.3.2 as I don't have them, but it might be worth investigating when exactly that happens.


Gzdoom. 3.5.1, for posterity's sake, also obviously has that problem.


I included the file for tests if there are still any doubts about it. Just warp to SUPERMAP and click the button to emit the blast and then run up towards it - it won't hurt as it got modified for that matter.

[Graf Zahl]

That thing runs at 220+ fps for me when the smoke goes off.

[Nash]

That is a ton of actors - could be that with the introduction of ZScript in 2.3.0 onwards, the CPU overhead for actors just got more expensive because of scripting?

[Graf Zahl]

Unlikely. For me VM time peaks at 0.03 ms per single frame. To have any impact you'd need a CPU 50 times slower.
What this post is entirely missing is hardware specs, though.

[PillowBlaster]

They are in the OP in the spoiler? Guess I'll just use code box or quote next time.

Code: Select all

OS: Windows 10 64-bit
Processor: Intel Core i7-4702MQ CPU @ 2.20GHz 2.19GHz
VGA: NVidia GeForce 840M (DDR3, 2k MHz, 2048 MB)
RAM: 8,00 GB

If that proves to be not enough data, just say what else you'd need and I'll provide.

[Graf Zahl]

Don't hide important info in spoilers!

You can do one more thing:

Enter

vid_vsync 0
stat rendertimes
stat renderstats
stat vm
stat think

at the console and then make a screenshot when it really gets slow. Do the same (without 'stat vm') on the older version.
Looking at your hardware's specs, the graphics card in your system is not the fastest thing around. It may just be that some added processing that got added around version 2.3 pushes the processing time over the 60 fps threshold, but for that to recognize I need to see the actual numbers.

[PillowBlaster]

Alright, here's the 2.1.1.



And 3.5.1, respectively.

[_mental_]

While newer version is slower indeed, 42.5 ms is significantly more than 16.6 needed to have 60 fps.

[PillowBlaster]

Ah right, I knew I forgot about something - the joys of being on a laptop. Forgot to plug myself to power so that also makes a difference in performance - otherwise I clocked around 19-21ms. Also the results keep being slightly disparaged, as the distance to the nuke also makes a difference. Guess maybe I should get the spawner closer so it's always the same result, but there's no denying something is up.

[Graf Zahl]

This is entirely GPU related. I cannot say what may be at fault, but in both cases the time is entirely spent on waiting for the graphics card to finish rendering.

If you want to test other versions before 2.3.2, you can find them here: https://zdoom.org/files/gzdoom/bin/

[PillowBlaster]

So I made screenshots on double-nuke (stand in front of the button, freeze, click twice, unfreeze) with versions 2.1.1, 2.2.0, 2.3.0, 2.3.1 and 2.3.2 respectively, at roughly same moment each. The render time between 2.1.1 and 2.2.0 oscillates around 1.1, while anything from 2.3.0 and up goes to around 3.3 and higher. Here are those shots.

[drfrag]

Here's 2.3.0.
First version with official ZScript support.
Screen space ambient occlusion (SSAO) for the OpenGL renderer, written by dpJudas
UDMF-configurable fog density per sector
Glowing flats settable through UDMF
Proper rendering processing of large actors
Improved IWAD picker, allowing to choose the active renderer, or autoloading lights and brightmaps.
Proper dynamic light definitions for Freedoom.
Multithreaded software rendering
Some improvements to the console
Fixed the pitch issues that were warned about for 2.2.0.

Do you have SSAO enabled?

[PillowBlaster]

Nope. No SSAO, no tonemap, no bloom, no lens distortion. I keep that stuff off.

[Graf Zahl]

I'm closing this because it looks like an underpowered system reaching its limits. Unfortunately sometimes it happens that changes to the code can push such setups over the line where the lack of computing power becomes apparent.