It's a problem caused by a limitation of AutoIt's sleep function that I only noticed after commiting the changes. Let me explain quickly: The tool locks its framerate in a pretty common fashion, aka by calculating the delta time (average milliseconds it should pass between frames minus time spent recieving and drawing a frame onscreen) and waiting that amount of time if it's greater than zero (if it's not then it means the program isn't keeping up with the framerate). Now, I knew that AutoIt's sleep function is kinda inaccurate - that's why I called this function experimental - but it would have worked just fine if its minimum sleep time wasn't limited to 10ms, which might seem like an incredibly small and irrelevant amount of time until you realize that sometimes the tool needs to sleep just a few milliseconds. Take into consideration this example: you set the framelock to 30 FPS which means that the average time between frames is 33.333... (repeating decimal) milliseconds and the tool takes 32ms to recieve and render the frame so the tool should wait a little bit more than 1.33ms before rendering the next frame, but since AutoIt's function can sleep for a minimum of 10ms it will end up sleeping around 7,5 times than the amount needed! This isn't an unsolvable issue, howerer - in the next commit I'll use timers instead of the sleep functions, which are much more accurate so they don't have this limitation.