Apparently you did not get the just of what I said, I do not Sleep() in my games or run this exact loop of doing 'nothing'.
I simply stated that I wrote a similar loop to this that also does OTHER operations.
For example:
Code:
do
{
if (TimeHasPassed)
{
GameObject->Cycle();
}
} while (true);
I said a similar loop - I did not say I was using a 'nothing' loop.
So when you say that I am wasting 'cycles', you are wrong. The reason being in the sense of what I just decribed. When someone plays a game, they have very little intention of doing much else... So think about what your point was against what I just said.
Which was my point about the 'faster code' versus sprintf.
Timers are inaccurate as the Sleep() function, THAT is my point. Windows is not a REALTIME OS.
The structure of my code in terms of accuracy is what I meant. In 'structure' where a similar loop (relative to all code) such as the example above - for ACCURACY, to ensure what I want to happen is done correctly. You stated that in your own post, which is WHAT I MEANT in my post previously. What you just did is take my idea of what I said, and acted as if I did not intend that - in a way, not to sound like I am 'baiting', but that I 'do not know what I am talking about.' When in fact I do.
A dummy Wait() would be a solution to allow some other process some clock time, and NOT wait for the entire period between 'Cycles'. A dummy wait for a portion, and this 'looping' until it's time to cycle.
As for the laptop issue... Yes, you are correct. That is common sense. It's just like sampling audio at 48000 instead of 44100, it takes up more harddrive space.
About what you said about a thread priority boost, that is due to the QueryPerformance functions, they are probably making a kernel call. Kernel code has priority over user mode code. And, by looping in this manner, creating that priority boost - I can get 'more cycles' for my thread, in which when the time comes to Cycle(), those cycles will be used for the game itself. Which means it will actually run SMOOTHER.
I can also take advantage of this in a worker thread, when it's time to do something, have that thread post to the Waiting() GUI thread (GetMessage() sits there and waits for a message to be inserted into the queue, therefore when the event is set that one has been, it gets a BIG priority boost, and even bigger still - the priority boosted thread that called SendMessage adds the priority to that thread, because it is the thread that sent the message.)
This has it's pros and cons. More pros than cons actually. You want to get a task done as quickly as possible, then you can allow things to be done by other tasking 'objects'.
This is actually a good solution in terms of writing a 'time critical' application due to the fact of using up cycles. GUI threads generically do not use many cycles, they wait until an event has been inserted into the queue. So I say, why not use as many cycles as I can, considering the importance of GUI applications over console ones. That is why I witness no apparent downside in my testing. The GUI threads get a large priority boost when an event is inserted into the queue - therefore, what's the problem?
Example:
Using GetTickCount() previously (which is horrendously inaccurate, it can be off my 1 millisecond) I wrote a sampling app (note the word sampling, not polling like a standard GUI application) that all it did was get the desktop window DC, and painted text on it that was different colors every time. I set it to try and go as many frames as possible (10000).
It only mustered at most 900 FPS.
However, when I changed this to use QueryPerformanceCounter? I was able to muster 9600 FPS.
