I’ve run into a VERY awkward problem. I have a lot of things that rely on the event tick firing at a constant rate. Everything works smoothly in editor but as soon as i switch the viewmode to fullscreen (F11), event tick is slowed down.
I came to this conclusion because, basically, I have a character with a jetpack, and I’ve been implementing my own jetpack system where when you turn on the jetpack, character gets a mild jolt up into the air using “Launch Character” with a strong z vector and then, the same function is used to hover in that position by delivering microjolts by basically taking a fraction of the vector and applying it to the character over and over again. And the “over and over again” functionality is driven through the event tick. So I did ALOT of tweaking and found the perfect value of z vector and a tiny time delay between each jolt to achieve equilibrium. If i were to increase the delay, the timing of the jolts would be decreased and my character would start to descend. If increased, my character would begin to rise.
This system works flawlessly except when I try to go full screen, my character begins to descend. And since in my system, descending is done through increasing the time delay, I came to the conclusion that the time delay is being increased due to the event tick firing slightly later than my system is sync for, when in fullscreen, thus being slowed down basically.
Is there a way to mitigate this issue? Because if event tick is being slowed down, then shouldn’t any loop that I try to use instead of event tick also suffer from the same problem?
I’m guessing this question will awail moderator approval forever, Neverthless, if anyone else comes across this problem, I’ll let you know that “there is no escape from the enemy within”.
The “enemy within” here is the slow system I am developing on. No amount of timers, delay-loops or timelines will mitigate this issue as the engine itself is slowed down due to my slow system.
The only way I found to mitigate this is to purposely add a delay of .1 seconds or so to the eventtick/timer/timeline/loop/whatever you are using and then adjust the values in your code to sync with this delay. The resulting code will be a bit wonky, but it’ll be fps-drop proof.
In my case, I had a jetpack which was having a steady impulse being applied to it through a timer. adding the impulse every time using the event tick, inside the editor was nice as i adjusted the impulse power and since the event tick was adding impulse at a stable rate, my character was hovering, but it all went to ■■■■ in fullscreen cause event tick slowed down in fullscreen due to the whole editor lagging and the amount of impulses per second dropped, this my character dropped from the sky too.
With the purposely added delay, I was able to readjust the impulse power to make up for the time lost by the delay and while this new, higher impulse power made the hovering a bit turbulent and wonky, it fps-proofed it as a lower fps due to the editor slowing down no longer had a effect on the loop i was using as the loop was already purposely slowed down substantially, with a higher preset impulse power making up for the slowed down loop. So even the editor slowing down had no effect on my gameplay.
Hope this helps someone out.
Tick executes every frame, so it frame dependent and executed in same rate as oyu got fps. Which means when you got full screen you fps drops and oyu code is effected by that.
Thats why Tick comes with DeltaTime argument which contains estimated time passed between ticks, you can use that to scale delta values in you algorithms to be time dependent not frame, so for example:
Y += X * DeltaTime;
Effectively turns X in to Y increase per sec
Also note that putting delay on tick only delays the tick calls not change it rate of execution.
You can also use timers, they are a lot easier to control with time passing, while in tick you would need to count up deltatime to count time