Timers (advanced question, not beginner)
Author
I'm using windows functions: QueryPerformance...
QueryPerformanceFreq() in DevC++ returns 3.5 e6 (3.5 Ghz which I'm on AMD 3500+)
QueryPerformanceFreq() in VS2005 returns 7.0e+010
Acutally after copying this its strange that they are very very close to a 2.0 multiplier. (I didnt show every digit thats why im saying close). Maybe because its running in debug? I couldnt get release mode to work cuz of a library issue. I'm going to try to get that up and see.
Author
Well I got the release mode working but its the same result. I'm going to test this on some other machines at school with different processors.
The AMD 3500+ doesn't run at 3.5ghz. It runs at 2.2ghz. That, and 3.5e6 is actually 3.5 million (which would, by your metric, be 3.6mhz) and not 3.5 billion. Also, the difference between 3.5e6 and 7.0e10 is a lot more than 2x. It's more like 4 orders of magnitude.
Besides, it shouldn't matter. The results of QueryPerformanceFreq() should only really be used in conjunction with the results from QueryPerformanceCounter(), so the timer results will be consistent either way.
Besides, it shouldn't matter. The results of QueryPerformanceFreq() should only really be used in conjunction with the results from QueryPerformanceCounter(), so the timer results will be consistent either way.
Are you sure you handle 64-bit integers the same way on both platforms? Maybe the one in DevC++ got shortened.
Author
Well your right in the math logic.
The thing is, DevC++, my particles work correctly I took the final time in seconds and multiplied by the framerate given from Fraps, and I got 1.
In MSoft, uhm my particles move like a hair each frame and I think its cuz that 7.blah e10 is so damn big.
The thing is, DevC++, my particles work correctly I took the final time in seconds and multiplied by the framerate given from Fraps, and I got 1.
In MSoft, uhm my particles move like a hair each frame and I think its cuz that 7.blah e10 is so damn big.
I love "advanced, not beginner" questions :D
You have a bug somewhere; there's no way a timer is running at 70 GHz.
Quote:returns 7.0e+010
You have a bug somewhere; there's no way a timer is running at 70 GHz.
Author
Its not my code, how can there be a bug. I call a windows function and it gives me that number.
Anyway, you're supposed to use the ".QuadPart" right? I mean like i said, this all works in DevC++.
LARGE_INTEGER freq;
freq = 9813606787
freq.QuadPart = 10311586962
freq.HighPart = 2
freq.LowPart = 2092886133
Should I just use a different timer method all together?
Anyway, you're supposed to use the ".QuadPart" right? I mean like i said, this all works in DevC++.
LARGE_INTEGER freq;
freq = 9813606787
freq.QuadPart = 10311586962
freq.HighPart = 2
freq.LowPart = 2092886133
Should I just use a different timer method all together?
Quote:Original post by dpadam450
Its not my code, how can there be a bug.
Can I use that as my signature?
Look at the way they do it in Ogre3D source code since they compensate for speedstepped cpu's.
Author
It got solved. Sent it to a friend. Really weird how he fixed it though. Didn't make sense.
As for the Scuppy guy, I figured someone would think I'm saying that in an amateur way, but what I meant was this way: If I call a void function taking void as the paramter and it returns 455, but its returning -1, then I have no damn effect on that function. And if it is said to be an algorithm and work all the time, then its not a bug, its some other b/s happening somewhere.
As for the Scuppy guy, I figured someone would think I'm saying that in an amateur way, but what I meant was this way: If I call a void function taking void as the paramter and it returns 455, but its returning -1, then I have no damn effect on that function. And if it is said to be an algorithm and work all the time, then its not a bug, its some other b/s happening somewhere.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
