Weird and randomly bug with timings
Author
Hi Folks !!
I have a weird bug in my GameCode:
When starting the program, I have randomly either 65 or ~200 fps. No, it is not about VSync. It is disabled in the program and disabled in the driver. So these reasons don't match. For Timings I use GetTickCount() rather than timeGetTime().
But this can't be the problem or ?? I mean it is the same code.
This problem exists as well in the debugger and when starting normally from the folder.
Did anyone encounter a similar problem ?? Can you tell me some tricks to figure out where the problem is ??
I know you are not here to solve my bugs, but I am really lost. I don't want this to happen on the users pc when releasing one time. :(
Thanks to all and rya.
Scorcher24
ramdomly is unlikely, unless you are doing something strange. Find the pattern and you'll probably find the problem.
Author
Hi Folks !!
@skillfreak
Well, its not the problem you mentioned with your link.
@mrbastard
Wel, I am sorry but it is relly RANDOMLY. I can start the Application 10times and perhaps 4 times it works as expected and 6 times it runs slower. It's not only that the Counter displays less, the App is REALLY running slower. I can see that on the rotations and animations.
I wouldn't post here if it would be just a normal bug about some calculating problems. A friend of mine, he is studying Electrical Engineering which includes the language C, looked at my Code and he could not find any miscalculations or similar things, too.
I thought it may be a problem with my ATI-Drivers, but I have changed them to previous version and updated them from 5.4 to 5.5 and it is still the same problem.
I have cut out some stuff from the scenes, I have deactiveted shaders and tried to log every action, but I still do not have any solutions.
Hope there is somebody who perhaps encountered similar or the same problem and
reads this...
rya.
Scorcher24
@skillfreak
Well, its not the problem you mentioned with your link.
@mrbastard
Wel, I am sorry but it is relly RANDOMLY. I can start the Application 10times and perhaps 4 times it works as expected and 6 times it runs slower. It's not only that the Counter displays less, the App is REALLY running slower. I can see that on the rotations and animations.
I wouldn't post here if it would be just a normal bug about some calculating problems. A friend of mine, he is studying Electrical Engineering which includes the language C, looked at my Code and he could not find any miscalculations or similar things, too.
I thought it may be a problem with my ATI-Drivers, but I have changed them to previous version and updated them from 5.4 to 5.5 and it is still the same problem.
I have cut out some stuff from the scenes, I have deactiveted shaders and tried to log every action, but I still do not have any solutions.
Hope there is somebody who perhaps encountered similar or the same problem and
reads this...
rya.
Scorcher24
Just a thought... Try setting timeBeginTime(1) which should 'force' the timeGetTime-function to have 1-ms accuracy. Dunno if this is the problem though. I remember this fixed my variable framerate a time back. If you try this, you should run timeEndTime(1) before you shut down the program. Don't know if this applies to GetTickCount...?
-Trond
-Trond
Did you test your game on other computers than yours ? Maybe it is a problem with your hardware/software configuration.
Just a thought. Do you use RAMs with different timings ?
Did you test other functions for timing, i.e. the RDTSC instruction ?
Are there applications in the background, like a virus scanner, that take up a significant amount of cpu time ?
Quote:
It's not only that the Counter displays less, the App is REALLY running slower.
Just a thought. Do you use RAMs with different timings ?
Did you test other functions for timing, i.e. the RDTSC instruction ?
Are there applications in the background, like a virus scanner, that take up a significant amount of cpu time ?
let me suggest using a QueryPerformanceCounter timer instead of getTickCount. It is more accurate by about 3 digits I believe. Qpc makes the difference between ms between frames and ns between frames. Naturally you want to check the nanoseconds to get a more accurate reading.
Visit this thread from vbforums I made. It is pretty old but it recently got revived by someone asking for my timer class. It is near the bottom, but download it and use it, very simple, may fix your problem. In the least it is still an improvement over getTickCount().
http://vbforums.com/showthread.php?t=305885
Visit this thread from vbforums I made. It is pretty old but it recently got revived by someone asking for my timer class. It is near the bottom, but download it and use it, very simple, may fix your problem. In the least it is still an improvement over getTickCount().
http://vbforums.com/showthread.php?t=305885
Author
Hi Folks !!
Thanks for contributing in my Post. I have really checked all Bottlenecks coming from the Environment like OpenApps, Services, Background Programs.
I have tested this on other Machines, too. On one machine this occured in the same way like on mine, on others not. But like I said, it is randomly and cannot be forced.
At the moment I built in the Timer class which was suggested to me, and I hope after that things are clearer.
@nmi and unfinished
All Textures and Fonts are loaded at Start so there cannot be any delay.
My VisualC++ would report me if I would cause any memory leaks what
would make the system slower with the time.(#included the crtdebug and set the flag) All allocated Memory has always a power of 2 to make sure to have efficient usage of the memory. new was
preffered to malloc, because there is always more heap than stack.
(Correct me, if I see things wrong).
There is only one open FilePointer open during the Run:
The LogFile. Thats all. Its closed in destructor.
RDTSC -> What is that ?? I do not know that Shortcut, sorry. Could you give me a link or a brief description ?? Would be very kind. Thanks.
So far.
rya.
Scorcher24
Thanks for contributing in my Post. I have really checked all Bottlenecks coming from the Environment like OpenApps, Services, Background Programs.
I have tested this on other Machines, too. On one machine this occured in the same way like on mine, on others not. But like I said, it is randomly and cannot be forced.
At the moment I built in the Timer class which was suggested to me, and I hope after that things are clearer.
@nmi and unfinished
All Textures and Fonts are loaded at Start so there cannot be any delay.
My VisualC++ would report me if I would cause any memory leaks what
would make the system slower with the time.(#included the crtdebug and set the flag) All allocated Memory has always a power of 2 to make sure to have efficient usage of the memory. new was
preffered to malloc, because there is always more heap than stack.
(Correct me, if I see things wrong).
There is only one open FilePointer open during the Run:
The LogFile. Thats all. Its closed in destructor.
Quote:
Did you test other functions for timing, i.e. the RDTSC instruction ?
RDTSC -> What is that ?? I do not know that Shortcut, sorry. Could you give me a link or a brief description ?? Would be very kind. Thanks.
So far.
rya.
Scorcher24
Quote:Read TimeStamp Counter (RDTSC) Description
Description
Loads the current value of the processor's time-stamp counter into the EDX:EAX registers. The time-stamp counter is contained in a 64-bit MSR. The high-order 32 bits of the MSR are loaded into the EDX register, and the low-order 32 bits are loaded into the EAX register. The processor increments the time-stamp counter MSR every clock cycle and resets it to 0 whenever the processor is reset.
The time stamp disable (TSD) flag in register CR4 restricts the use of the RDTSC instruction. When the TSD flag is clear, the RDTSC instruction can be executed at any privilege level; when the flag is set, the instruction can only be executed at privilege level 0. The time-stamp counter can also be read with the RDMSR instruction, when executing at privilege level 0.
The RDTSC instruction is not a serializing instruction. Thus, it does not necessarily wait until all previous instructions have been executed before reading the counter. Similarly, subsequent instructions may begin execution before the read operation is performed.
Linky
Here are two examples of how to use it
#include <iostream>__int64 ReadTimeStamp(void){ __int64 retVal; __asm{ push eax push edx rdtsc mov dword ptr retVal, eax mov dword ptr retVal[4], edx pop edx pop eax } return(retVal);}__declspec(naked) __int64 Read(void){ _asm{ rdtsc ret }}int main(){ // Either one of these works the same way either Read() or ReadTimeStamp() __int64 start = Read(); for(int i=0; i < 100; ++i ) { } // I could have also called Read() here again... __int64 end = ReadTimeStamp(); std::cout << "Starting Time = " << start << std::endl; std::cout << "Ending Time = " << end << std::endl; return(0);}Output:Starting Time = 558132456369400Ending Time = 558132456370292hth
moe.ron
[Edited by - moeron on June 15, 2005 1:06:29 PM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement