bug - SHOWSCREEN & GETTIMERALL

[retrotech]

Running with Windows XP
SHOWSCREEN becomes increasingly less smooth as a program runs and
when a GLBasic program is run again the problem continues with the
same degraded display intervals which were occurring at the last run.
So over time a program is unplayable and the only solution is to reboot.
When running this test program I discovered that GETTIMERALL will
eventually report *** negative *** time between frames!!!

[attachment deleted by admin]

[MrTAToad]

How long does it take before program degradation ?  I have had no problems within the few minutes I tried it, nor was there a problem when the program was repeatedly run.

However, I will leave it running for a half hour or so and see what happens.

Be aware that your OS may be tiding up the hard drive (or whatever it does whenever it thinks the hard drive isn't in use) which would affect performance.  There are also many other things that would cause irregular slowdowns too...

[Slydog]

How long is 'eventually' when displaying negative frame times?
About a month? (or about 2 billion ms)  That's if it's using a 4 byte *SIGNED* integer for the timer and it's rolling over to the negatives.
A 2 byte integer would only be about 32 seconds before it rolls over, which we all would have experienced by now.
Or your code is breaking some kind of light speed barrier.   

[retrotech]

I never noticed the slow down when I began to make games a few months ago using GLBasic because each game was simple and was run only a few minutes at a time each day.  This problem has been happening for a couple months and how long it takes before I need to reboot depends on how many times I close the game and make another change in the code and then do a recompile and run.  If I never start the GLBasic IDE but merely run the game which had been compiled earlier then it might take longer such as 45 minutes.  The more a game does between each SHOWSCREEN call, such as press the keys more, seems to be a factor which causes the intervals to get crazy.  The strange thing is that nothing else in the system is effected such as watching a movie while playing music and copying files to an external drive, but as soon as ANY GLBasic game which I have made is run the problem is seen exactly at the same level of effect as it was doing previously and continues to get worse the more that game is running.  It doesn't make a difference how much time passes between runs.  I can only make a wild guess as to what is happening but it seems there is some kind of system hook used for something by GLBasic which stays hooked so at the next run of any GLBasic program calling SHOWSCREEN the problem continues.

[Kitty Hello]

I have no idea. It works here. Maybe a driver issue? Try to get the latest.

[Moru]

Are you running any other application that uses OpenGL? I had some strange problems a few versions ago when I was running other OpenGL applications at the same time, one of them would go down to 1 fps while the other runs just fine. Update drivers, update GLBasic and shutdown all other programs and see if there is any difference.

[Slydog]

Could it be a memory leak?  Something isn't getting freed when the game exits?
Not sure of the best tool to check for this, but you could try Window's built in Task Manager, it has a memory tab.
Just note the starting memory, then run the game and see if the memory returns to the starting value when the game is exited.
And / or try the same code on another system and see if it happens there also, so you can figure out at least if it's your code or not.

[Wampus]

The built in Task Manager may not be adequate. System Explorer http://systemexplorer.net/ displays far more information about running processes and Process Hacker http://processhacker.sourceforge.net/ is good too. Spotlight on Windows can also be great too, as a general purpose resource monitor. If only there was something like that for monitoring OpenGL performance on Windows.

[Wampus]

Retrotech I'm going to leave one two copies of a game app running for a few hours. One will have a little GETTIMERALL() register in there to see if that makes a difference. Be interesting to see what will happen.

It might be an idea to post a rundown of your hardware and OS so people with similar set ups can try what you're doing. Also, if you could upload a small app that has the problem you describe then it would help also. <- ignore this. You already did that and I was just unobservant.

[Wampus]

Well, I ran three modified apps of mine (to make heavy use of GETTIMERALL) for over 7 hours on two separate computers with different CPU and GPU hardware. I was monitoring them with Process Hacker 2 and an OpenGL debugger called gDEBugger. All seems perfectly fine. Retrotech I'm going to examine the code of the app you uploaded, run it for a lot of time, etc. and see what happens. If I find anything I'll try to work out what's going on.

[Kitty Hello]

run it and view the memory useage with process monitor. Does it constantly rise?

[MrTAToad]

Ran mine for several hours and it was all constant.

Are you running a Quad core machine ?

[Wampus]

When running retrotech's test my memory usage was constant for two of my PCs. The third increased memory usage slightly for a couples of minutes before leveling off, but that is probably because of the bizarre way its been set up (it has no page file, caches as many system resources as possible, monitors & logs lots of things). All three showed constant framerates and didn't degrade in 3 hours of testing. The tests were ran on Atom,  Pentium 4 and P8600 Core Duo CPUs with onboard Intel GPUs and a Nvidia 320M GPUs and all in WinXP SP3.

[MrTAToad]

This bit of text describes the problem (I thought it was a problem with just Quad core machines, but apparently it happened with Dual core ones too) :

A more difficult problem occurs in dual-core systems. When gamers started getting dual-core processors, they began experiencing interesting and disturbing things, including jerky animation and negative elapsed times. It's very odd indeed to see your character jump back in time. Why this happens isn't immediately obvious until you realize that those two processors aren't exactly in sync. So, suppose the following happens:

QueryPerformanceCounter(&startTime);   // obtains from core 1
// execute code
QueryPerformanceCounter(&endTime);   // obtains from core 2
And since core 2 is lagging a little behind core 1, the returned endTime value is less than the startTime. All of a sudden, you have a negative elapsed time. An almost equally bad situation occurs if core 1 is lagging behind core 2. In that case, the reported elapsed time will be larger (sometimes up to 500 milliseconds) than the actual elapsed time.

Microsoft's SDK documentation for QueryPerformanceCounter says:

On a multiprocessor computer, it should not matter which processor is called. However, you can get different results on different processors due to bugs in the basic input/output system (BIOS) or the hardware abstraction layer (HAL). To specify processor affinity for a thread, use the SetThreadAffinityMask function.
Setting the thread affinity isn't always an option, though, especially in multi-threaded programs. In addition, there are some reports that setting the thread affinity doesn't always work, although I've been unable to confirm that.

Microsoft documented this problem in their Knowledge Base article 896256, which was updated last in August of 2006. A hotfix is available, which should alleviate the problem. The article tells you how to go about obtaining the fix from Microsoft.

If you're writing games or other programs that require high-resolution timing, you really should read Microsoft's Game Timing and Multicore Processors article for tips and techniques that will help you make the most of the timing services provided by Windows.

So, some things to try would be to make sure XP is fully updated and try running the program on just one core.

[Wampus]

MrTAToad if retrotech's problem was down to having a dual-core CPU, wouldn't we see this crop up a lot more? I have a couple of dual-core CPU systems and while GETTIMERALL() can be a bit unstable sometimes for various reasons multitasking related I don't get any choppiness.

Retrotech, have you tried any of the suggestions?