End

Code:

---

End

---

A statement which as far as i know doesn't close you program properly and hides errors. Right now i'm being forced to use end because i don't know how else to close my program properly. I'm not sure where my problem is but some of you should be able to fix it. I'm trying to make a game using directx with a game loop. This code is the skeleton of what i'm making.

Code:

---

Public Class Form1
    Private ProgRunning As Boolean = True

    Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Me.Load
        Me.Show()  'Make the form appear
        Me.Focus()  'Give the form focus

        GameLoop()  'Start the game loop
    End Sub

    Private Sub GameLoop()
        Do
            REM Draw whatever i want to draw here

            Application.DoEvents()  'Allow other things to happen before drawing again

        Loop Until ProgRunning = False
    End Sub

    Private Sub frmDNMain_Disposed(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Disposed
        ProgRunning = False

        End 'The end of it all
    End Sub
End Class

---

This code runs alright because end is being used but if you rem end out the error which it's hiding comes out. The error is "Object reference not set to an instance of an object." I'm not totally sure but i'm guessing that the error is refering to the form.

Have you tested

Application.Exit()

yet?
It works with me. That is the command I use in my application menus in the item «Exit Program».

I have not used directx in VB.Net, but surely going into a loop stright from a Load event is a bad idea? The load event basically never finishes until the game has ended. It is like trying to paint a wall before the plaster has dried. Using a timer control would be far better than using a DoEvents (which could cause choas like you have above), I do not know if this causes any conflict with directx which may need a tight loop for drawing however.

It is my understanding that the Dispose Event will be thrown when everything is about to be cleared from memory. So, what happens if you do not put END there? I think it should still end the program.

That seems a bit off. Why run the gameloop in the Load event if you want to force the form to show first? You can always start the gameloop in a later event, such as the Shown event. However, when it comes to game loops, it seems like this might be a better application to start with a Sub Main rather than one that starts with a form.

I'd also try moving the setting of the flag into an earlier event such as the Form_Closing event.

I agree with SH... seems like maybe there's a design flaw here... but at least it seems to be easily correctable.

I'd probably create a main sub, make it the start up object, and in the event, create an instance of the form, then showdialog it... then in the shown event of the form, run the game loop. your loop exit condition ( ProgRunning = False) probablty should be behind a button or something, but not the dispose event for sure... then after exiting the loop, use me.close to close the form, which will return to the main sub, where the app then ends gracefully (don't forget to dispose the form).

-tg

Ok, i'll need to rework my code to use a main sub. I've got a question about the form dispose evemt though. I used it because i was trying to get the same event as form_unload in vb6. What would be the proper event for this? Closing the form when clicking on a button would work but that doesn't account for when the form is closed another way.

Form_Closing should be raised whenever the form is closed.

I'm not actually sold on the Sub Main, it's just that I don't like the idea of running the game loop inside a form like that. I haven't dealt with game loops in VB, so I don't know what the standard would be. When I dealt with it, the program largely consisted of a single function that set up any global variables, loaded any resources, and that sort of thing, then went into a perpetual loop for the life of the game. Inside that loop, the input was processed, the AI was performed, and the new image was rendered, but that's probably way out of date these days. To do someting like that, you'd start with a Sub Main, then inside the game loop you'd be updating the display. On a form, that may not make all that much sense. It just seems like sticking a game loop into the form will mean that the UI thread will be mostly occupied by that loop when it should be mostly occupied with getting and responding to user input. The way that loop will work, user input is only solicited once every time through the game loop. A Sub Main solution would have a similar design, but back in the days of DOS, from whence I came, that was how it worked. In event-driven Windows, subordinating the events to a loop running in the UI thread seems like a bad idea, as does a Sub Main for the same reason. I don't know what the typical pattern in Windows is, though.

I'm not so sure about using a sub main now. To

Quote:

---

create a main sub, make it the start up object, and in the event, create an instance of the form, then showdialog it... then in the shown event of the form, run the game loop. your loop exit condition ( ProgRunning = False) probablty should be behind a button or something, but not the dispose event for sure... then after exiting the loop, use me.close to close the form, which will return to the main sub

---

seems a bit useless because a main sub doesn't do anything there, just shows the form.

Quote:

---

In event-driven Windows, subordinating the events to a loop running in the UI thread seems like a bad idea, as does a Sub Main for the same reason.

---

This isn't a problem. Notice the line "Application.DoEvents()" If i don't include that you can't even close without breaking and ending but with it all events run as usuall (there will be lag of course if the time drawing is really long though).

Thanks for the event tips though, i've managed to remake my process much more efficiently like this. If uses the form show event and the form closing event.

Code:

---

Public Class Form1
    Private ProgRunning As Boolean = True
    Private Sub Form1_Shown(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Shown
        GameLoop()
    End Sub

    Private Sub GameLoop()
        Do
            REM Draw whatever i want to draw here

            Application.DoEvents()  'Allow other things to happen before drawing again

        Loop Until ProgRunning = False
    End Sub

    Private Sub Form1_FormClosing(ByVal sender As Object, ByVal e As System.Windows.Forms.FormClosingEventArgs) Handles Me.FormClosing
        ProgRunning = False
    End Sub
End Class

---

This makes it start and end "gracefully" and i'm vert happy with it.

I did notice the DoEvents line. However, you will also find that I am one of the few people here who don't object to it. Without that, you'd freeze the UI entirely, as you have noted, but it is generally a sign of a design that could be improved. Since I don't know what the typical VB game loop design looks like, I can't say more than that, except that it sure seems like the game loop might run in a different thread. That can't be all that common, either, though, because multi-threading is relatively new in the grand scheme of things.