On Fri, 26 Oct 2001, Alexander R Angas wrote: > > Does DirectX 3 have the timers necessary? If possible, I'd like this to > > work on NT4 (which only has DirectX 3). If not, can we settle for DirectX > > 6.1 (what I belive win98 shipped with)? > > I'm fairly sure that DirectX 3 does not have the timers necessary. If we're > linking against DirectX 8.x, doesn't that mean that FreeSCI would need that > as a minimum requirement regardless?
Not necessarily. You can instantiate an instance of a specific version of the interface. At least, that's what I read in my "DirectX 7 in 24 hours" book 6 months ago. If I get time, I'll revisit it and let you know if we're missing anything. > What I might do, once stages 1-3 have been completed, is try a few timing > implementations for stage 4 (the Win32 event ss plug-in). Now that I think I > know about every possible high-res Windows timing implementation on the > planet, the options are: > > a) using the current IReferenceClock::AdvisePeriodic() function > b) using a worker thread and GetTickCount() > c) using a worker thread and QueryPerformanceCounter() (perhaps) > d) using a worker thread and Intel assembler code > > That should make it clear which implementations have the best performance, > and which take up the most CPU. Makes sense. I'd say it's safe to assume at least a Pentium CPU is being used if there's any instructions at that level that are useful in the assembly implementation. Then again, putting CPU dependant code in there would make it more difficult to port to other win32 platforms (sega dreamcast, Windows CE, etc). Most implementations I have seen for high precisions timers have used QueryPerformanceCounter, including the previous version of usleep.c in FreeSCI. Once CVS is back up, you may want to retrieve the previous version to see how it was used. Alternately, you could download the source tarball for the 0.3.2a release and look as usleep.c there as well. Let me know how it goes, good luck! -- http://www.clock.org/~matt
