As many of you probably know, Scratch usually runs at 30 frames per second. Sometimes a little more (31 FPS), sometimes a little less (20 FPS). This means that if you put a "move 1 step" block inside a forever block and run the code, the sprite will move ~30 times in each second. However, Scratch isn't limited to just 30 frames per second. This may seem contradictory to the first paragraph, but you have to know how the Scratch blocks work. Some blocks, like the move block, take some amount of time to execute. However, blocks like variable changes *don't* take up that much time at all. Thus, Scratch can also run at much greater speeds. On my computer I've achieved ~150,000 FPS. Next, we have to know how the Scratch timer* works. The timer rounds to the millisecond, or one thousandth of a second. You can get times like 3.523 or 9.384, but never more accurate than that. The "days since 2000" block rounds to the centisecond, which is even less accurate. But if we can get a loop that runs at a super high speed as mentioned before, could we analyze the time between each frame and thus get an insanely accurate timer? The short answer is... no. We would have to take the time between each frame, which is impossible since the timer isn't that accurate. The time between frames would just end up to be zero. Here's where it gets a little bit complicated. You *can* actually estimate the elapsed time between each frame by analyzing the rate at which the loop is running. If you look at the smallest amount of time possible with respect to the timer (namely 0.001 seconds), you can figure out how many frames have passed in that time period. Then, you could repeat the process for the next 0.001 seconds. But as you can probably see, the timer is always going to be a little bit inaccurate. This is because we have to estimate the framerate before getting the elapsed time, which itself takes time. At that point, the thousandth of a second would be gone and a new thousandth of a second would arrive. The framerate of a rapid loop isn't constant like a normal loop is - it can be anywhere between 140,000 and 160,000 FPS, or perhaps outside of that range too. However, it may be possible to analyze the *rate of change* of the frames passed for each thousandth of a second - for example, 144 frames passed in the first thousandth, 153 frames passed in the second, and so on, and you might be able to estimate quite accurately the next thousandth, eliminating the problem described in the previous paragraph. I hope at least some of that made sense. Wish me luck as I try to execute this idea of an accurate timer ;)
