BackgroundWorker issue

[Andre S. Veteran]

I am writing a little game (for school, hence the mandatory nonsensical design choices). The top-level component is a Winforms C# application. This is just supposed to provide a window, some basic menus and redirect input events to a C++ dll that does all the rendering and game logic processing.

I'm trying to see where I'm supposed to put my game loop in there. I assume the basic loop has to be in C#, and call native methods like update() and draw(). Since I don't want to stall the GUI, I created a background worker and passed it this method:

        void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e) {
            CycleTimer.TriggerUpdate += CycleTimer_TriggerUpdate;
            CycleTimer.TriggerDraw += CycleTimer_TriggerDraw;
            CycleTimer.Start(30);
            while (true) {
                CycleTimer.Update();
            }
        }

... where CycleTimer is my own class that I've used in a previous game entirely in C# and it was working really well. However I wasn't hosting it in a WinForms app. Now in this situation, I've noticed Update() is called every 25 milliseconds. This is completely unacceptable. It should be called at least every millisecond (and it should even be MUCH faster than that on my pc). Even when I comment out its body entirely so that it is merely called and exit, doing nothing, it is still called no more often than once every 25 milliseconds.

I suppose this is due to backgroundWorker being a somewhat low priority thread? Where is my approach wrong? I'm open to suggestions that deviate a lot from what I've did there. For instance if there was a way to manage the game loop in the C++ dll only, without stalling the WinForms host, that would be great.

Edited September 2, 2010 by Dr_Asik

[Andre S. Veteran]

Mk small update: I've replaced my background worker method with this:

        void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e) {
            var stopWatch = Stopwatch.StartNew();
            while (true) {
                Console.WriteLine(stopWatch.ElapsedTicks);
            }
        }

Here's a sample of the output:

6441918
6441929
6441941
6441952
6441964
6441977
6441989
6442002
6442015
6442027
7010387 WTF?!
7010427
7010444
7010461
7010478
7010494
7010510
7010527
7010544
7010561
7010577

So basically it is called super-often and then there are long random pauses every now and then.

[Andre S. Veteran]

Ok nvm all this. The variability observed is normal and I can compensate for it with an intelligent game loop. I get very stable results using a compensating algorithm. Also, the long delays I had observed at the beginning stemmed from doing a Console.WriteLine every time through the loop, which would result in a deluge of output and create some delays.

All is well. I use a normal System.Threading.Thread now but I guess BackgroundWorker would have done the trick too.

[Kami-]

Got to love threading eh?

[MrA]

6441918
6441929
6441941
6441952
6441964
6441977
6441989
6442002
6442015
6442027
7010387 WTF?!
7010427
7010444
7010461
7010478
7010494
7010510
7010527
7010544
7010561
7010577

So basically it is called super-often and then there are long random pauses every now and then.

If this was Java, my first thought would be "garbage collection". Everyone I know that runs a production Java service has nothing but bad things to say about it. You're using .NET, but I can only assume it has a similar problem.

[Andre S. Veteran]

If this was Java, my first thought would be "garbage collection". Everyone I know that runs a production Java service has nothing but bad things to say about it. You're using .NET, but I can only assume it has a similar problem.

It might also just be the OS deciding that my thread doesn't get CPU time for a few thousand ticks, and the same issue would happen in a non-gced environment.

[Prince Charming]

Yeah, looks like the OS just doing it's thing with regards to thread priority.

[boogerjones]

It might also just be the OS deciding that my thread doesn't get CPU time for a few thousand ticks, and the same issue would happen in a non-gced environment.

Yep, you'll notice the same thing in native code. Create 2 threads that do nothing other than increment an integer and you'll see marked variation in the progress of each thread.