I just noticed that the Sleep function provided by the windows.h header is pretty inaccurate. I just wonder if there is a better solution to this problem. I already tried to come up with an accurate method, but while its more accurate it also consumes much more CPU-power than the regular Sleep-function
Sleep() also yields the processor. This is why it is both processor-friendly AND inaccurate. Once the processor slice is given up, the thread is no longer executing. It is then turn for the OS to re-schedule it at some point. Your code is not affecting the OS so by definition, user code cannot do any better, meaning your efforts are wasted, in my opinion.
I actually don't know about kernel mode programming, so I cannot really say if there is a way to improve your situation, so I leave it to you to investigate.
Bottom line: You either yield and be processor-friendly but inaccurate, or not yield and loop like you are doing now; you'll be accurate but processor-intensive. In Windows, a program cannot "twist Windows' arm" to force it to re-schedule a thread at a precise time. Windows will do as it sees fit and no program has any saying in this, AFAIK.
Thank you very much for the answer. The thing that confuses though is how you can create smooth constant framerate graphics without an accurate sleep function. It makes me believe that there must be at least a midway between accuracy and performance.
Doing low level stuff like kernel mode programming would be probably very unsave with my beginner programming knowledge and would likely lead to a disaster. I guess I have to search for a 3rd-Party solution and review this topic when I got more experience.
The problem is, traditionally PCs used an interrupt driven timer. This is inherently inaccurate. But more recent Windows boxes have an HPET (High Precision Event Timer), which is a proper hardware timer. You probably want to look into how you access it from Windows for your application level high-res timer.
High-res timing in Windows is akin to how we measure time. There are different ways to measure it and they all disagree.