ZDoom

So I checked out the latest Blade of Agony commit to give Episode 2 a spin and man, that intro scene with the moving camera and the trees... that scene completely murders my framerate. Is there anything that can be done to make models render faster?

Here are my specs

Win 8.1
Intel i7 950 3.06 GHz
15 GB DDR3 triple channel
NVidia GTX 960 2 GB

It does that to me, too.

I think there's a problem with the effect spawners. There's way too many actors in the scene and it's bottlenecking the CPU.

In Paranoid back in ~2010 or so we fixed this with A_CheckSightOrRange checks - but I doubt any of those fixes ever made it upstream for the original author of the effects.

Ah, so it's the effects, not models eh? If only we could assign a "particle" statnum to actors, so that they will be treated the same as the built-in particles, but with the addition of custom sprites and animation. :D

Rachael wrote:I think there's a problem with the effect spawners. There's way too many actors in the scene and it's bottlenecking the CPU.

So I guess it's the trees and the snow particles which are visible at the same time, right? The question is definitely: What can we improve without ripping the atmosphere off?

@Nash - Would you mind trying how the performance actually is at the beginning of C1M0 as well as the beginning of C2M5? Maybe we can track down if it is the weather particles or the model objects drawing performance. I really would like to test it but unfortunately I don't suffer any slowdowns at all - I have to say I have a very powerful machine after all.

I am near to find a somewhat solution, but the situation is very complicated it seems.

My performance on C2M5 is just plain bad. But C1M0 is just fine.

Intel(R) Core(TM) i7-4710HQ CPU @ 2.50GHz
NVidia GeForce 860M

I don't think that it's the models that are your issue.

When I type "stat think" at the beginning of c2m5 it's obvious what the problem is - 15-16k+ thinkers. I'd guess most of them are special effects. When I initiate the "freeze" cheat the frame rate smooths out dramatically.

EDIT: After noclipping around a bit, portals seem to be an issue, too. Flipping gl_portals on and off has a slight effect on the frame rate. My guess is the scene complexity is not helping matters, in this case.

Maybe the extended particles I asked about is worth considering for situations like this...

[I've also updated the thread title because I was wrong about the models]

Keep in mind that particles themselves use resources, too. The only way to know if this would save any time is to transform these SFX systems to particles, even without sprite replacements, and see how they perform. After sprite replacements, they will perform on nearly an identical level, anyway - maybe slightly slower due to the additional checks needed for particles to set up the sprite replacements since in this case we're expecting there will be a lot of particles - which by itself will automatically make all particle functions time-critical.

If you go at least that far, you can make a much stronger case for sprite particles.

I wonder if something like DistanceCheck could be implemented where any actor farther away than the specified distance from a PlayerPawn or camera would effectively be frozen.

EDIT: Something like that can already be done in ZScript - I just don't know how much overhead it would incur by not being native code. Can't test until I get home tonight.

Rachael wrote:I don't think that it's the models that are your issue.

That was what I assumed.

So according to your post it's simply the "actors in movement", am I right?

But why I get 12-16fps when I remove SmallTree2 actors? Are you totally sure too? Also do not forget that AlertLight actors checks a peculiar script each tick... Also noticed that sound channels are flooded on c2m5 ( checked with stat sound), even if I set them to 256, and if I remove ambientsound actor I still get a slightly improvement (3-5 fps)

Ozymandias81 wrote:But why I get 12-16fps when I remove SmallTree2 actors? Are you totally sure too? Also do not forget that AlertLight actors checks a peculiar script each tick... Also noticed that sound channels are flooded on c2m5 ( checked with stat sound), even if I set them to 256, and if I remove ambientsound actor I still get a slightly improvement (3-5 fps)

AlertLight actors don't touch ACS unless the player is within their radius...

I might eventually be able to even get rid of all of the visibility ACS altogether, but not in time for Episode 2.

Can you give me map coordinates for where the trees are worst for you?

Ozymandias81 wrote:But why I get 12-16fps when I remove SmallTree2 actors? Are you totally sure too? Also do not forget that AlertLight actors checks a peculiar script each tick... Also noticed that sound channels are flooded on c2m5 ( checked with stat sound), even if I set them to 256, and if I remove ambientsound actor I still get a slightly improvement (3-5 fps)

I didn't test GPU bottlenecks. My GPU is powerful enough that it blows through most of them.

In fact, I hardly even worry about GPU bottlenecks because GPU's are upgradeable. CPU's stay mostly as they are no matter what - there are no CPU's officially reaching above 4GHz clock speed without overclocking - so CPU bottlenecks are much more of a concern for me because what we have now is about as fast as we're going to get it with them.

Is it worth testing for GPU bottlenecks? - yes, it is - and in this case, the heavy use of models will cause them. But in more modern systems, CPU bottlenecks need to be hit, first.

Things that will plague CPU performance are linedefs, too many nodes visible at once on the screen, and moving actors.

Tormentor667 wrote:

Rachael wrote:I don't think that it's the models that are your issue.

That was what I assumed.

So according to your post it's simply the "actors in movement", am I right?

That is correct. Every actor that executes physics code of any sort is capable of causing framerate issues. I can compile a debug build of GZDoom - that will run sufficiently slow, even on your processor, that you can test some of these bottlenecks, yourself.

EDIT: @Tormentor667: Here's a debug build for you -
https://mega.nz/#!kFsSjLKR!h4tjNxYSlG4U ... 9NVYNWaYpY

The performance issues should be big enough for you in this build that you should be able to test some of the problem areas yourself. It doesn't have to run perfectly in a debug build, but if you see areas where framerate really tanks, at least you'll know it'll run poorly for other people.

Thanks for the detailed information, that helps us to know what we have actually to improve: It's the moving actors that make the problem in C2M5 and C2M1, I would ignore sounds and models in this case as C1M0 is running smooth and uses similar amount of tree models in the outside areas.

The question now is: How can we improve C2M1 (snowy forest) and C2M5 (rainy forest) without killing the atmosphere?

*EDIT*
I just tried C2M5 with weather/effects activated and deactivated (through menu), the thinkers only change from 16.500 to 15.000 - what else is causing the slowdown?

Rachael wrote:EDIT: @Tormentor667: Here's a debug build for you -
https://mega.nz/#!kFsSjLKR!h4tjNxYSlG4U ... 9NVYNWaYpY

Oh yes, that really sucks now - unfortunately it sucks that hard that even C1M1 isn't playable anymore