The Wait (seconds) block is inaccurate & I found a case where a longer wait times executes quicker than a shorter wait time.
I was going to test the new collisions and decided to make a more accurate FPS counter than the traditional method. Hours later I can definitively say that the wait seconds block doesn’t work as expected.
I tested using multiple texts with a simple counter:
when wait comes up for execution, we set a variable with a timestamp representing the current system time + amount to wait.
in each subsequent frame we execute, we check if the wait timestamp has arrived, if not, we skip to the next script
if it has arrived, we execute the next block after wait.
Since each frame takes a minimum of 0.0167 seconds (and can take longer depending on your device, your project, etc) we might run into race conditions when you set wait times that are close to the frame rate.
But, if we have time, we’ll look into what’s actually going on.
Thanks for the explanation. That’s always appreciated. The description is precisely what I had expected and had tried to use to make a more accurate FPS counter. My thought was to have an object with 2 different rules both executing Waits. The second wait would be slightly longer by a small amount, say .0001s. While both waits finish during the same frame you increase the wait time. Do this until the slightly longer wait takes 2 frames to execute while the 1st, slightly shorter wait only took one frame and you’ve found the seconds/frame. Then just continually increase & decrease to track to the SPF
However the Wait Seconds doesn’t seem to work as described. To the best of my recollection that is how the old Wait Milliseconds worked, but the Wait Seconds block is behaving differently.
