Back in early 2017 (or possibly even earlier) I changed the debris actors in Hideous Destructor from being bouncing projectiles to
using a custom Tick() override and I remember getting significant performance
improvements doing so. I have not tested this recently so it might have gotten worse with more features added to ZS, but ever since I made the switch it has never been a problem.
EDIT: Just a couple thoughts:
-
yeah, +nointeraction is definitely way less overhead than any possible tick override.
- The main Tick() itself is actually a lot smaller than I had been expecting.
- I'm pretty sure calling Super.Tick() in an override would still leave you calling the virtual machine every tick, so it should be guaranteed have that extra overhead if there's any override at all no matter what's in it.
- I still want to know if the virtual machine overhead applies to anonymous functions - i.e., whether putting a complicated repeating code into a looping spawn state and then using +nointeraction would make more sense.*
*EDIT: For what it's worth, relying on +nointeraction and relying on an anonymous function would shave off the ClearInterpolation() and frame-advancing stuff, all of which add to the VM overhead. As far as I can tell the only good reasons for a tick override are:
1. Something that
must happen continuously on an actor regardless of its states (e.g., it's burning and smoke is coming out of it) and it's stupidly unmaintainable to explicitly call it in every single frame
2. You're overriding the basic movement code so that "vel" should not be applied directly (+nointeraction will still have the actor move according to its own internal velocity
; however, looking at the code again this might be avoided with +noblockmap?)
Back in early 2017 (or possibly even earlier) I changed the debris actors in Hideous Destructor from being bouncing projectiles to [url=https://github.com/MatthewTheGlutton/HideousDestructor/blob/master/zscript/effect.txt#L24]using a custom Tick() override[/url] and I remember getting significant performance [i]improvements[/i] doing so. I have not tested this recently so it might have gotten worse with more features added to ZS, but ever since I made the switch it has never been a problem.
EDIT: Just a couple thoughts:
- [url=https://github.com/coelckers/gzdoom/blob/ef867c3415cef8fbfb93c9a2bf3f84d4da324442/src/p_mobj.cpp#L4093]yeah, +nointeraction is [i]definitely[/i] way less overhead than any possible tick override.[/url]
- The main Tick() itself is actually a lot smaller than I had been expecting.
- I'm pretty sure calling Super.Tick() in an override would still leave you calling the virtual machine every tick, so it should be guaranteed have that extra overhead if there's any override at all no matter what's in it.
- I still want to know if the virtual machine overhead applies to anonymous functions - i.e., whether putting a complicated repeating code into a looping spawn state and then using +nointeraction would make more sense.*
*EDIT: For what it's worth, relying on +nointeraction and relying on an anonymous function would shave off the ClearInterpolation() and frame-advancing stuff, all of which add to the VM overhead. As far as I can tell the only good reasons for a tick override are:
1. Something that [i]must[/i] happen continuously on an actor regardless of its states (e.g., it's burning and smoke is coming out of it) and it's stupidly unmaintainable to explicitly call it in every single frame
2. You're overriding the basic movement code so that "vel" should not be applied directly (+nointeraction will still have the actor move according to its own internal velocity[s]; however, looking at the code again this might be avoided with +noblockmap?[/s])