In this thread I will discuss how to create a managed game loop in a proper manner. First I will identify ways that are most commonly used and explain why they should not be used. Then I will explain how to set up the proper managed game loop as well as why it works the way it does.

Currently there are two common ways that most programmers use as game loops. The first is using a timer to act as a game loop where as the second method is to use a backgroundworker or some other thread other than the UI to act as the game loop. In both cases, Application.DoEvents is generally used. First let me explain why you should never use Application.DoEvents in your game loop. What Application.DoEvents() does is it processes all Windows messages currently in the message queue. In theory this sounds great, it processes all the messages that are waiting. However, what this can cause is some tearing in your graphics. That is my warning with DoEvents, if you are interested in some more reasons as to why you shouldn't use DoEvents, simply search for "DoEvents considered harmful" and you'll get plenty of examples.

Now I mentioned that timer's are used as a game loop, which I actually encourage beginners to use the Timer class. The way that the timer works is at a set interval amount, the tick event gets fired. This sounds like it should work flawlessly, the issue comes with the message queue mentioned earlier. If you set the interval too low, like 1 or 15 for example, the message queue gets tied up and the event doesn't get fired at the desired interval. This can cause not only some tearing in the graphics, but it can also cause your program to 'skip'.

The last method that I will tackle is using a backgroundworker or some other thread other than the UI. Generally what you'll see is something along these lines:
Code:
        Do Until True = False
            'Do stuff here

            Application.DoEvents()
        Loop
If you weren't doing anything at all, just killing time in a code it would be considered a 'Busy Wait', but even if you were using it as your game loop it's still just as harmful if not worse. I'm going to refer to this method as a Busy Wait even though it wouldn't be used as a waiting method in a game loop just for simplicity. The reason why a busy wait is considered so harmful is because it keeps the CPU running at 100% for the entire loop which can kill laptop batteries and overheat systems.

So what alternatives are out there? Well, this is one that I personally use:
Code:
    Private quit As Boolean = False
    Private Sub GameLoop()
        'Update

        'Loop
        If quit = False Then
            ExecuteAfterPause(CInt(8.3), New MethodInvoker(AddressOf GameLoop))
        End If
    End Sub
A lot is going on here, and leads me to the root of it all. The ExecuteAfterPause is a method that JMcIlhinney came up with and the full module can be found here. Basically what happens in the module is it pauses your code in a safe and efficient manner.

I do a bit of XNA work and the flow of a typical XNA game would be: Initialize -> Load Content -> Update <> Draw -> Unload. Where you call update and draw repeatedly until you're ready to quit or Unload. So to give you an example of how my XNA Pong's game loop looks like:
Code:
    Private Sub GameLoop()
        grafix.Clear(Color.White)

        Call Draw()
        Call advanceFrameRate()

        grafix.Present()

        If quit = False Then
            Call MovePaddle()
            ExecuteAfterPause(8, New MethodInvoker(AddressOf GameLoop))
        End If
    End Sub
With that right there, I'm able to keep a steady Frames Per Second(FPS) at 64, which if you want to get into game programming the target is typically 60 FPS.

Well I hope that you enjoyed my version of a managed game loop, if you have any questions or concerns feel free to post them here.