<br><br><div class="gmail_quote">On Wed, Aug 18, 2010 at 3:04 PM, SHOO <span dir="ltr"><<a href="mailto:zan77137@nifty.com">zan77137@nifty.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
I have some knowledge about these problems.<br>
However, there is not the tool to measure really correct time by Windows.<br>
It means that Windows have a problem about timeGetTime equally.<br>
Ability of timeGetTime is about 10[ms] order. Besides, its accuracy is affected by programs to work in background.<br>
In the scene using a highly precise performance counter, the performance seems to be insufficiency.<br>
<br>
I think the problem that QPC has is the defect of OS and machines.<div><div></div><div class="h5"><br>
<br></div></div></blockquote><div><br>I wasn't suggesting you use timeGetTime here :-) But I wanted to bring up the issues for anyone who wasn't aware. And, you mentioned<br>game programming in your original post. Game programmers are hyper-sensitive about this sort of thing, but generally don't actually *need*<br>
millisecond accuracy -- just consistency. However, one of the Game Programming Gems books includes a timer implementation that uses<br>QPC, but programmatically takes into account the potential for unexpected values. It would be nice to see a similar solution implemented<br>
here. Of course anyone using the StopWatch could implement their own solution to average out the values it returns, if they feel they need to,<br>but having it builtin would be sweet.<br><br>Just a suggestion. Even if you don't do it, I think this class would be a great addition to Phobos.<br>
</div></div><br clear="all"><br>-- <br>Mike Parker<br>