An accurate form of Sleep()?

[SuperKoko]

do
{
    if (TimeHasPassed)
    {
        GameObject->Cycle();
    }
} while (true);

This code is equivalent to:

do {
  GameObject->Cycle();
  AbominableSleep(frame_time - time_to_compute_the_cycle);
} while(true);

When someone plays a game, they have very little intention of doing much else

Wrong.
They can still compress files in background.
And if they don't, they may not like to see their battery power vanish if they use a laptop computer.

So when you say that I am wasting 'cycles', you are wrong.

No, you are WASTING CPU cycles. If GameObject->Cycle() takes, say, 10 milliseconds and your game runs at 30 fps, then, your program will try to use 3.3 times more CPU cycles than needed.

About what you said about a thread priority boost, that is due to the QueryPerformance functions, they are probably making a kernel call.

No, I was talking about an hypotetical case where someone would manually boost the priority of your process and notice that normal priority processes (e.g. explorer) are frozen forever.

Which means it will actually run SMOOTHER.

If you think that you get an artificial priority boost, then, it's a shame, not an honor.

GUI threads generically do not use many cycles, they wait until an event has been inserted into the queue.

Which is a good behavior.

So I say, why not use as many cycles as I can, considering the importance of GUI applications over console ones.

Because MY COMPUTER IS NOT MONOTASKING.

Assume that my computer is much faster than required for your game.
I compute every frame in 1 millisecond.
Assume that I compress a big file, using as much CPU power as it can, and I run your game.

If your game used Windows Sleep() operation; My compression operation will be very very slightly slowed down. Every 30 milliseconds, it'd loose 1 millisecond.
If your game use this do-while loop, it'd claim that it constantly needs CPU, and my compression operation will be exactly TWICE slower than normal.

That is why I witness no apparent downside in my testing.

Because you use your system like a monotasking system.

Using GetTickCount() previously (which is horrendously inaccurate, it can be off my 1 millisecond)

timeGetTime() has the accuracy of 1 millisecond.

BTW, what is the point of eating all the CPU if you want a fixed frame rate?

In a single CPU machine, only 1 thread can be executing at any one time (although for such a minute time, it seems like everything is going at the same time) so when my thread is using cycles, it's technically not robbing from any other.

You definitively don't understand what cooperation between threads mean.
You're not really stealing, as the system accepts to give you what you ask, but you're asking more than you need.

Suppose there is a big cake.
Two persons want to eat the cake.
But YOU are allowed to take a part of the cake, because the law says so.
However, suppose that you've just eaten for the dinner and aren't hungry anymore to the point that you cannot eat anything anymore.

If you're a good man, you'll say to the two men: "Cut the cake in two and take the two parts. I won't take my part. I'm not hungry".
If you're not a good man, you'll say: "Cut the cake in three and give my part", then, you'll drop your part on the floor and jump with your two feet right on it so that REALLY nobody will ever benefit from it.

This is the game you're playing with the CPU. The CPU is a cake. You shouldn't claim that you need to eat it if you don't.

Games require that code do not take very long to execute in their minute selves, as a whole - the calling of all those functions, etc... must add up to less than the intended cycle time for a frame, otherwise... It will run at a slower framerate than the target.

A proper Sleep() operation in a variable framerate game doesn't prevent that.
Maybe you never played to GlQuake?
This is instructive.

It's not my applications fault - it's the design of the OS.

No. Your application is too badly programmed to have a variable framerate. This is its fault.
BTW did you search MSDN for multimedia timers?

My app in that situation due to the OS's design, is what is keeping the CPU actually doing something.

Mhhh... How do you think that GlQuake is perfectly smooth and yet, don't eat my CPU? Is it some sort of black magic?


Anyway, I feel that the discussion won't go anywhere.

Could you give the name of your application(s) so that I can avoid to ever install it on my computer?