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?

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.

Rachael wrote: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.

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:

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.

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.

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.

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.