Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
en:toolworks:docs:apparatus:steady-tick [2021/04/02 20:06] – vladius | en:toolworks:docs:apparatus:steady-tick [2021/04/08 22:24] (current) – vladius | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== Steady Ticking ====== | ====== Steady Ticking ====== | ||
- | |||
- | < | ||
- | <img src="/ | ||
- | </ | ||
- | </ | ||
Almost all video-games (and thereby game engines) have a common technique for iterating on the game process. The game is basically run in a loop. This loop is thereby called a game loop. On each iteration of this loop the game should prepare and actualize the state of the game for rendering and perform the graphics rendering itself. These iterations are called Ticks within Unreal Engine. They are like a heartbeat to your game. | Almost all video-games (and thereby game engines) have a common technique for iterating on the game process. The game is basically run in a loop. This loop is thereby called a game loop. On each iteration of this loop the game should prepare and actualize the state of the game for rendering and perform the graphics rendering itself. These iterations are called Ticks within Unreal Engine. They are like a heartbeat to your game. | ||
Line 58: | Line 53: | ||
{{ : | {{ : | ||
- | This ratio, which is bound from 0.0 to 1.0 (both inclusively), | + | This ratio, which is bound from 0.0 to 1.0 (both inclusively), |
+ | |||
+ | Sometimes it's tedious (or kind of difficult) to manage both past and future states in some auxiliary separate variables. You may want to use the current object' | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | This node is similar to Steady Frame Ratio in that it is also returning a single float value bound to an inclusive [0.0, 1.0] range. It differs in the actual basis for this range. Let's illustrate it on the picture: | ||
+ | |||
+ | {{ :en: | ||
+ | |||
+ | As you see, the last change (be it steady or a usual tick) is tracked and remembered as a starting point for the relation. The second part is the same as for the Steady Frame Factor node and actually represents a timestamp of the next future steady frame. Using the future factor you can use the current actual state as a base for [[ue>BlueprintAPI/ | ||
+ | |||
+ | Both of these nodes can be used directly during | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | This event is run after your normal variable ticks (and hence after the necessary steady ticking) and is meant to be used for evaluating the visual feedback mechanics. Interpolating mechanics are logically and clearly one of those. Have a look at this complete position interpolation mechanic that is a part of our [[https:// | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | The most important Apply Offset function is implemented like so: | ||
+ | |||
+ | {{ : | ||
+ | Concluding the topic it should be said that the described technique is not mandatory at all. You can evaluate your mechanics anyhow you like and configure the engine to produce fixed FPS updates. We, however, presented you a way to achieve a consistent gameplay framerate and also recommend using it for stability reasons. | ||