I came to the same conclusion too PhyloGenesis...by (no login)
Thank you for explaining the problem so clearly in that thread. In fact QB64 already only refreshes the screen data only 60 times per second, the "usual" refresh rate of a monitor. Your solution is of course correct but totally neglects the fact that it is often very difficult to assess whether QB code is simply waiting for a key press to happen, unless they use the INPUT statement but this wait was already catered for.
I said in a previous post I was using Sleep(1) at regular intervals to lower CPU usage. As you say this was silly because it could have been slowing down a program trying to run as fast as possible. Sleep(0) on the other hand is a totally different situation, because when you call Sleep(0) it only sacrifices the rest of its allocated cycle if another thread is not waiting. If no other thread is waiting then Sleep(0) returns control to the calling thread immediately. I'm now only using Sleep(0) in the main thread. But you cannot just call it before every loop because calling the function (even if it is returning "instantly") still takes time. So the solution is still to estimate the amount of time since the last call to Sleep(0) using simple/fast integer maths and only call it after a certain interval.
Later I'll have to add a few waiting commands (like SLEEP but more accurate) to allow programmers to better manage CPU usage. But for now, if the program isn't calling a SLEEP, WAIT &H3DA,8 or INPUT etc. command then it'll use as much CPU cycles as it can get. It's not appropriate to have INKEY$ wait because it is a function which returns immediately.
PS. This solution will still fix Pete's problem with INKEY$ returning 40 chars a minute.
Return to Index