Very bad performance with FX-heavy scenes

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is OFF
Smilies are ON

Topic review
   

Expand view Topic review: Very bad performance with FX-heavy scenes

Re: Very bad performance with FX-heavy scenes

by Graf Zahl » Sat May 20, 2017 1:46 am

The best way to handle is would be the same as ZDoom's own SpawnBlood and SpawnPuff implementations, i.e. set the render style to 'none' if the console player is not the one the item is for.

Re: Very bad performance with FX-heavy scenes

by Nash » Fri May 19, 2017 9:16 pm

Xaser: the mechanics to filter it to specific players already exist - this is how the speed trails in gzdoom.pk3 work. Basically, you check against consoleplayer.

Code: Select all

class LADPrecipitation : Actor
{
    // snip
    
    override void Tick()
    {
        Super.Tick();

        // snip
        
        if (!tracer)
        {
            return;
        }

        // destroy precipitation from other players
        if (tracer && tracer != players[consoleplayer].mo)
        {
            // Hexen speed trails are doing this
            //bINVISIBLE = true;
            
            // but instead, I do this
            Destroy();
        }
    }
}
 
I talked about this issue briefly in the ZScript thread when ZScript was still very new (I can't find the post) but my solution involves destroying the precipitation immediately if the check fails. As Graf said, this is a recipe for sync disaster, which is why I was very, VERY careful in how my precipitation stuff is setup.

They have absolutely no chance to interact with anything else in the game, so the way I've set it up, it doesn't ruin multiplayer.

And yes I've tested this in actual MP games, it works. :)

Obviously if GZDoom supports true C/S then I'd do it differently, but given the currently available mechanics in the engine, this is all that I have to work with for now.

NOW! That said... you'd probably be disappointed in how it actually looks in-game. You always get the feel that the precipitation is following you. Like it's only raining on you.

Things I have also tried and the results were "meh"

1) Hard-offsetting the precipitations' position relative to the camera. This has the "Oblivion" effect where the rain/snow is stuck hard on to the screen. It looks ridiculous

2) Soft offset via checking the player camera's current velocity and spawning the precipitation at an offset. Well it sort of works but sometimes when the player moves too fast, you will notice the precipitation density be sparse until you stop moving

I have settled with (2). Precipitation effets have come a long way in my weather system Bumi since a few years back but there's still plenty of room for improvement.

Re: Very bad performance with FX-heavy scenes

by Xaser » Fri May 19, 2017 5:04 pm

Man, how many times am I going to have to ask a simple question before getting an actual answer and not a non-sequitur?

I guess since it's necessary to explain this now: I'd like to limit the weather spawning to a radius around the player (I figured this part was clear given the post snippet of Rachael's I was quoting). This will increase performance by spawning less actors. Success and whatnot.

The caveat though is if there's two players in the area, Player 1 will see rain FX around oneself, but also catch glimpses of distant rain spawning around Player 2. That's ugly, hence my actual question (for the third time): Is it possible to make the rain actors spawned around Player X only visible by Player X?

Re: Very bad performance with FX-heavy scenes

by Graf Zahl » Fri May 19, 2017 4:35 pm

It's not the enemies which cause the problems in this map, though. It is fully sufficient to have inert actors doing minimum checks to add up to several milliseconds if there's several 1000.
The only chance I see to get processing time further down is to explicitly put those into a non-thinking statnum.

Re: Very bad performance with FX-heavy scenes

by Rachael » Fri May 19, 2017 4:25 pm

AFADoomer wrote: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.
Exactly this.

At 8000+ actors, this is what will get you - every single time.

One thing you might try is put enemies to sleep if they are more than 5000 units away from the player. In the spawn state, do a distance check since it's relatively uncostly, and just have the actor sit in a single frame for 70 tics and then check again before reverting back to its spawn state. Don't even A_Look when they're far away.

Doing a distance check every 70 frames is a LOT easier on the CPU than doing A_Look every 8-16-ish frames. Especially if you number your enemies in the thousands.

Plus - there's absolutely no reason for any of them to be active in the cinematic intro, except the ones that are actually in the cinematic itself.

This will have to be applied to every single enemy to be effective, though...

Re: Very bad performance with FX-heavy scenes

by AFADoomer » Fri May 19, 2017 4:21 pm

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...

Re: Very bad performance with FX-heavy scenes

by Graf Zahl » Fri May 19, 2017 4:18 pm

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

Re: Very bad performance with FX-heavy scenes

by Xaser » Fri May 19, 2017 4:10 pm

Graf Zahl wrote: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.

Re: Very bad performance with FX-heavy scenes

by Graf Zahl » Fri May 19, 2017 1:58 pm

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.

Re: Very bad performance with FX-heavy scenes

by Tormentor667 » Fri May 19, 2017 1:46 pm

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...

Re: Very bad performance with FX-heavy scenes

by Rachael » Fri May 19, 2017 1:17 pm

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.
Attachments
Screenshot_Doom_20170519_151540.png

Re: Very bad performance with FX-heavy scenes

by Nash » Fri May 19, 2017 12:59 pm

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.

Re: Very bad performance with FX-heavy scenes

by Rachael » Fri May 19, 2017 12:48 pm

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.

Re: Very bad performance with FX-heavy scenes

by Tormentor667 » Fri May 19, 2017 11:57 am

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!

Re: Very bad performance with FX-heavy scenes

by Ozymandias81 » Fri May 19, 2017 11:22 am

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)

Top