#Timer Performance

1 messages · Page 1 of 1 (latest)

icy pewter
# 
FTimerHandle StopTimerHandle;

float TickInterval = 1.0f;
float Duration = 5.0f;

void StartTimers()
{
    if (UWorld* World = GetWorld())
    {
        World->GetTimerManager().SetTimer(TickTimerHandle, this, &ThisClass::OnTickTimer, TickInterval, true);
        World->GetTimerManager().SetTimer(StopTimerHandle, this, &ThisClass::OnStopTimer, Duration, false);
    }
}

void OnTickTimer()
{
    // Repeating logic here
}

void OnStopTimer()
{
    if (UWorld* World = GetWorld())
    {
        World->GetTimerManager().ClearTimer(TickTimerHandle);
    }
}
# 

float TickInterval = 1.0f;
float Duration = 5.0f;
float ElapsedTime = 0.0f;

void StartTimer()
{
    ElapsedTime = 0.0f;

    if (UWorld* World = GetWorld())
    {
        World->GetTimerManager().SetTimer(TickTimerHandle, this, &ThisClass::OnTimerTick, TickInterval, true);
    }
}

void OnTimerTick()
{
    ElapsedTime += TickInterval;

    // Repeating logic here

    if (ElapsedTime >= Duration)
    {
        StopTimer();
    }
}

void StopTimer()
{
    if (UWorld* World = GetWorld())
    {
        World->GetTimerManager().ClearTimer(TickTimerHandle);
    }
}
#

Is better to have 2 timers one for Tick and one for counting to call the end, or to have 1 timer that calculates how much is it left?

#

And at the same time I'm wondering if for progress bar that g oes from 15s to 0s could I just call lerp once with constant and delta time world and it would also work? Rather than updating progress bar every 'tick interval'.

sudden bane
#

well you'd call lerp in a tick or some otherwise repeating function anyway

#

I would use a single timer instead of two if for nothing else managing two timers is double the annoyance

#

as for whether a timer is better than just handling it in a tick, the thing to think about is.. let's call it "storming". You may think that doing something less than once per frame is better, but if there's a lot of those things and you don't take the care to jitter them, they'll all bunch up together and have a less consistent frame time cost than just doing it per tick where the costs are immediate, obvious, and easy to profile

#

but if you are updating 5 progress bars in your UI, it won't matter too much

icy pewter
#

And so would you call then to update UI only by interval? Like currently my progress bars aren't beautiful because they are updating only in interval (0,2 / 0,5 depending) so some are looking more nice and some are not (depending on the 'update' rate). And I'm also wondering if adding lerp to these would make them much less performant. Or would you still use lerp to update from 1 to 0.8 and 0.8 to 0.6 so it looks nice?

#

and then there is also that idea to just start timer from 15 to 0 (not 'tick') it and at the same time start lerp from 15 to 0 in the UI.

sudden bane
#

if all were talking about is a smooth progress bar that represents time, and there aren't thousands of these happening constantly, you might want to just do it per tick. It would be smoother and simpler.

Ah when you say "lerp" you are talking about something above C++? Like timeline or some UMG feature?

#

even the lerp/interpolate BP functions are per frame

icy pewter
#

no, just normal node that lerps with some constant time?

sudden bane
#

nothing magic is happening

#

if you're fine performance wise lerping on tick in BP, you should be fine lerping on tick in c++

#

the BP will be slower of course

icy pewter
#

I cannot decide on the solution / standard to use for handling 'cooldowns' basically... if to update it every 0.1 / 0.5s and that's it or to use 2 timers + lerp in the widget

round gate
#

why not just tick? especially for such short times

icy pewter
#

but tick inside widget or inside the one that counts timer?

sudden bane
#

if you use tick you don't need any timers

round gate
#

on a gameplay side - ticking and float variable with current cooldown time left,
on a ui side - read remaining time or pass it to material
so both are independent, ui can have higher tick interval to reduce updates, material param will need none