So the theory is that Event Tick shouldn’t be overutilized because it can cause excessive overhead with your game and that it’s also inconsistent because fluctuations in your FPS can cause it to run at an inconsistent speed. Because of this, I started using Set Timer By Event instead of Event Tick, however, for certain situations, like when I’m setting up pawn movement, it seems like I can’t get the speed of an Event Tick to be high enough.
For example, if I’m just adding a simple Actor Rotation based on Input; If I drive it via Event Tick, it’s butter-smooth rotation even though I seem to be capped at 60 FPS in the editor. However, if I use a timer instead and set its time to 1/60 or 0.166, the actor stutters like hell. Bumping the Timer speed up (or rather down) to .00833 to approximate 120FPS is almost there, but there are still micro stutters. It’s not butter-smooth until I crank it up to about 240FPS or .00416.
I’m just trying to understand why this might be. Is there some limitation of Event Timers that I’m not aware of, or is Event Tick actually firing more than once per frame?
Tick by itself doesn’t have any particular overhead, in fact Timers have more overhead than tick if you want the timer to “tick” very often.
The benefit of timers is that they don’t have any noteworthy overhead between their ticks so it is better than a normal tick making its own individual check on every tick on every actor. The TimerManager schedule each timer efficiently.
Timers lose their benefit when they have to trigger almost as fast as a normal tick since tick has no overhead between ticks, it just ticks unless if the TickInterval is greater than 0.
Remember to stop Ticking Actors from ticking when the tick isn’t needed though instead of adding a bool check at the beginning of the tick.
My rule of thumb is that when something needs to tick more than 10 times per second use Tick (you can set the rate of Tick on the Actor) otherwise use a Timer.
Either way remember that Tick by itself is not demanding it is what it does that can be demanding and the amount of Actors it is Ticking on concurrently.
I think you meant to say “Stop Ticking Actors from ticking BY adding a bool”
Okay, so it’s good to know that tick itself doesn’t actually add any overhead, but your answer (as nice as it was) is missing the point of my question. I was trying to understand WHY Event Tick seems to work better than a timer for processes that require a faster update.
As I said in my example, if my game is capped at 60FPS, then my Event Tick is only going to update 60 times in 1 second. Mathematically, you would assume that setting my Timer to loop at 1/60 (0.0166) would give the same result, but it doesn’t. THAT is what I’m trying to understand.
The TimerManager also has logic that causes your events to be called potentially multiple times depending on the timer rate and the current tick rate. E.g. lets assume your game ticks at a constant 60 FPS and you set your timer to a timer rate equal 120 FPS, the timer event will be called twice every game tick (ignoring any potential floating-point inaccuracy for a moment). If you stop/clear the timer in one of the events, then any consecutive calls that would have happen will be skipped.
Your game will most likely not be running at a constant frame rate however and it would be a bad idea to count on that. So while tick can easily account for this using DeltaTime your timer event has a hard time doing that (even if you use the Worlds DeltaTime). This effectively makes your rotation speed up or slow down causing it to stutter.
No there is a function called SetActorTickEnabled you should use.
The frame-time is not constant even if the timer is set to be called at a constant rate. Similar to how physics are calculated it might be called several times in one frame if tick is slower than the timer interval.
Things that are rendered should use Tick and compensate for the tick variance using delta-time in the calculations.
Wait a minute, I thought timers fired independently of your frame rate. I thought that was the whole point of a timer. That it wasn’t firing on a tick, but instead on a specific timed duration and thus operated independently of frame rate fluctuations. Are you guys saying that a timer is still affected by frame fluctuations?? The way you all just described it was how I understood Event Tick to work. I thought timers were another thing entirely and their whole purpose was operating outside of the frame draw/buffer.
That I know of everything gets checked and ran before every frame (tick) starts rendering… so even timers when set for 1 second can take 1.012 second to fire if it has to wait an extra frame to complete the requiered time.
Tick just runs once per frame regardless of frame duration.
That is the golden question. I guess I assumed that frame rate was only a factor when something was being drawn on screen and I thought that somehow timers could operate on their own FPS independent timing. If not, then likely they’d be worse for overhead rather than better. I’ve noticed a trend for people to use timers instead of event tick because they thought it was somehow going to require less overhead, but clearly this isn’t the case. Unless someone else knows more of the technical side to counter this?
Better to treat timers as a scheduler rather than as a replacement for tick.
adding to what UnrealEverything said. Timers that fire off faster than tick are queueing multiple events to fire on the next tick. That’s why it seems to stutter at 1\60, Sometimes the timers’ scheduled time is after the tick, in which case it is rolled over to the next tick, at the same time, the next timer is scheduled before the third tick. So you skip one tick where the timer does not fire, then you fire the timer twice on the next tick which makes the obvious stutter.
To be honest I hadn’t heard of anyone replacing tick with timers. If you really needed something to be a slowed version of tick, you can adjust the tick rate in the class defaults. And forget about running events faster than tick unless you’re trying to do your own substepping.
I’m assuming you’re talking about the “Tick Interval (secs)” in the class defaults. But if I set my tick interval to be 1/15 of a second, what happens if I get a framespike that freezes the game for a whole second? During that second, the “tick interval” of 1/15 secs is faster than the actual tick. What happens with those updates?
After the freeze you’ll get a single Tick call with a DeltaTime roughly equal to 1,0.
If you used a Timer instead (1/15 rate, looping), you’d get roughly 15 calls after the freeze.
Tick Interval is always the minimum interval. If your frame rate drops below, it won’t magically tick faster than the frame rate. Always rely on DeltaTime.
