Very bad performance with FX-heavy scenes

[Graf Zahl]

It contains a lot of checks. Some use ThinkerIterators, and with 14000 active thinkers on the map they are rather costly.

[AFADoomer]

Looking at the FThinkerIterator code, it looks like if I assign a specific statnum to certain actor types, then only iterate over that statnum, then the iterator would have less to process... Is that correct?

[Graf Zahl]

Yes. You only have to be careful where to put stuff. Normally, anything between 80 and STAT_DEFAULT should be fine if it's actually thinking. Higher numbers than STAT_DEFAULT should be used with care, though. because the stuff in there depends on running after the game actors.
The numbers between STAT_DLIGHT and 80 should be left alone in case the engine needs to allocate new numbers.

[Xaser]

A lot of what you want to do can be done simply with intense fog and at most 3 or 4 large sprites projected out in front of the player.

Hmm, this got me thinking -- is there a way in ZScript to limit visibility of an actor to a particular player? There's a map in The Adventures of Square (E1A6) with some annoyingly misperformant rain effects, and a multiplayer-safe way of limiting the spawns to a radius around the player sounds like it'd be worth exploring.

[Graf Zahl]

You cannot have actors spawn for one player and not the others and have it sync-safe.

[Ozymandias81]

Ok I have finally had the opportunity to test recent fixes done by AFA (yesterday ones) and I must admit that perfomance has increased a bit (on the old c2m5 map, Torm has already split it in 2 maps right now)...

Don't know if these would be of use for you, but here you are some crappy tests I did with stat think, stat rendertimes, stat fps and stat fps_accumulated on

I was even in the way to post becnhmarks, but while I am quite sure that these won't be of really use for you I thought it was good for comparison in general.
FYI here you are my specs:

• Windows 7 64bit sp1 Ultimate

• AMD Athlon X2 250 3ghz Dual Core

• GeForce GT-610 1024mb Palit (updated)

• 4gb Ram ddr3 1333mhz single bank

Tested with GZDoom pre3.0 r207, 1024x768 no refreshrate set (vid_refreshrate 0)

[Tormentor667]

I want to thank everyone involved in this for your help and technical support. Graf Zahl's improvement on the engine really gained a lot of speed and so do AFADoomer's and Virgilio's code changes according to the suggestions being made here. I also splitted the map now into two pieces which did the rest to it and making the map now run in a very reasonable speed.

Thanks kindly!

[Rachael]

I'm trying it out now - I played from the beginning shooting at the snipers until the transition from the train itself to the train depot in C2M5_B - and so far, the engine feels a lot smoother and a LOT more natural. I think you guys really hit it here - good job.

[Nash]

The intro fly-by cutscene of Episode 2 still runs 18 - 30 FPS for me...

Seems like SSAO is the biggest drain for my computer. Turning off SSAO, I get 24 - 45 FPS for the Episode 2 intro cutscene.

[Rachael]

Here's an issue I discovered with the newly split maps: C2M5_B - at the player start, turn around and view the sky - this is pretty glaringly visible.

[Tormentor667]

Thanks, should be fixed now.

For the intro sequence in C2M1, I'd really like to know what could be done here. I mean, it's not only the intro, you play that part later...

[Graf Zahl]

That intro looks mostly ok for me, the exception being the snow which really drags it down badly - very badly.

One other thing you may try is to assign some decoration actors that will definitely never, ever move, to STAT_INFO, that will also save some time, but be careful: Do this only when you are absolutely 100% sure that it's ok.

[Xaser]

You cannot have actors spawn for one player and not the others and have it sync-safe.

Uh, yeah. That's why I'm asking about visibility of actors -- the actors need to spawn, but the raindrops clustering around Player 1 need to not be visible by Player 2, and vice-versa.

This may not be a thing that exists (yet?), but I was curious if there was some underlying ZScript-controllable stuff the "VisibleTo[x]" actor properties wrap that allow for fine-grained control.

[Graf Zahl]

That won't help you. It's not the rendering but the movement causing the problems.

[AFADoomer]

I think you're essentially asking for DistanceCheck-like handling, but tied to player actors instead of a distance.

I don't think it's the visibility that's the problem... It's the fact that so many actors are spawning. Even if they're not visible (like when DistanceCheck keeps an actor from rendering), the actor is still present, and all of the internal actor mechanics are still firing, and that's what causes processing delay.

EDIT: ninja'd by Graf...