DWORD GetTickCount(VOID)
VirtualNext
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Oh well. Guess I just have to live with it.
int timerFrequency;
if (!QueryPerformanceTimer(&timerFrequency)) {
// Insert fall back code using GetTickCount here
}
else {
// A high resolution timer exists, the number of "ticks" per second is in timerFrequency
int currTime;
QueryPerformanceCounter(&currTime);
// Now we have the current tick count in currTime
}
So, basically you just need QueryPerformanceCounter and Frequency, and both can be included in with "winbase.h" (or i think if you use other WinAPI functions bay already be included)
I personally find seperating the game in 4 threads connected with queues very usefull. One for "AI" (essentially anything complicated that require lots of processing and doesn't need to update with the same frequency as the framerate), one for rendering, one for UI and one for networking.
/Niels
The problem with your multithreaded approach is that there are several more threads that you don't even seem. For example, Flip() spawns a thread, async WinSock spawns a thread, etc. At most I could definately see a need for a second thread that handle's non-framerate dependant low priority stuff like AI, but the rest you might as well put into a well-organized main loop that will in the long run save you debugging time, speed up your program, ease portability AND readability issues and just make for a better program
(35fps on a 90Mhz pentium with 4Meg VMem, 90fps on a 400 PII (limited by screen refresh rate))..
But you're right - unless you do a proper design, your threads will spend more time waiting for each other, than getting actual work done....
/Niels
[This message has been edited by Niels (edited October 14, 1999).]