So, I never figured it out, exactly how long is 0 delay? (I know 1 is 1/10 of a second and so on, but what is 0 then?)
Essentially it is no delay, but practically I think it ends up being 1 frame.
One frame huh? Thanks!
well now I need to know, what is the base framerate of flowlab?
There are two:
The rendering & behavior logic runs at 60 FPS.
Physics run at 30 FPS ( by default, this can be changed: https://flowlab.io/behavior_handbook/#game-flow-frame-rate )
Ok @grazer I go to the link to read about frame rates
A single tic is a frame? Or is a frame faster than a tic? A delay of 1 is 1/10 of a second, but a delay of 0 is one tic? Do timer delays In the logic and animation delays Between frames line up if you do the math right? Or is there always some funky timing due to logic position, wire length and whatnot that it’s impossible to predict with certainty (bc that’s how I feel when I get a bunch of timers on repeat to operate reliably.)
Try to explain in terms of animation or drums and not in overclocking and processing rates if at all possible bc that’s how I think and program. Hahaha!!
Hey @todorrobot think of it this way. There are three things that need to happen to move the game forward: Physics, Game Logic, and Rendering (drawing the result of the first two). I tried my best to come up with a sensible drum analogy and couldn’t. Let’s try an animation one instead:
Rendering happens always, and at the same rate (60FPS in Flowlab).
Imagine yourself as a Disney animator in 1935 drawing dwarves. You have to draw 24 pictures of Sneezy for every second he’s on film (is that a real dwarf?). It doesn’t matter how fast or slow he’s moving, you always have to draw the 24 cells to be filmed. This is the rendering step, and the rate does not change in Flowlab.
Logic also runs at 60FPS, but you can skip frames
You can make your animated disney dwarf move as slowly as you want by skipping frames (i.e. using a Timer block) or by just moving him less in each cell (i.e. using a smaller increment in a Position block). He is moving slower, but still rendering at a smooth, cinematic 24 FPS.
Physics is different because you don’t control it
The new FrameRate block affects physics only. It doesn’t effect rendering because that would make things look bad (imagine taking extra photos of each animation cel, or leaving some cels out). It doesn’t effect logic because that’s not necessary (you have direct control over the logic).
The physics engine is a special case because you don’t directly control it. You basically set up some rules about the “physical world” of the game like gravity, the placement and materials of each object, and then it just runs along deciding how everything should react as various forces act on each object. Each frame that renders is just a “snapshot” in time, like taking a picture of your world at that point. When you slow down or speed up the physics rate using the FrameRate block, it literally just speeds up or slows down time in the world you have configured, while the engine still happily runs along taking snapshots of the world at 60 FPS.
Does this make any sense, or did I just make it more confusing?
I always just use 0 delay like an always behavior with a specific amount of repeats.
Wait so FPS affects the physics, does that mean it makes objects appear to fall slower and stuff? Amazing
Also, so 0 delay, being a behavior, is 1/60th of a second? wow, amazing