Thread: End
-
Jan 6th, 2012, 06:37 AM
#1
Thread Starter
Addicted Member
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.
-
Jan 6th, 2012, 09:32 AM
#2
New Member
Re: End
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».
-
Jan 6th, 2012, 10:07 AM
#3
Re: End
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.
-
Jan 6th, 2012, 10:20 AM
#4
Re: End
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.
More important than the will to succeed, is the will to prepare for success.
Please rate the posts, your comments are the fuel to keep helping people
-
Jan 6th, 2012, 10:28 AM
#5
Re: End
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.
My usual boring signature: Nothing
-
Jan 6th, 2012, 10:39 AM
#6
Re: End
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
-
Jan 6th, 2012, 12:22 PM
#7
Thread Starter
Addicted Member
Re: End
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.
-
Jan 6th, 2012, 01:41 PM
#8
Re: End
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.
My usual boring signature: Nothing
-
Jan 7th, 2012, 04:09 AM
#9
Thread Starter
Addicted Member
Re: End
I'm not so sure about using a sub main now. To
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.
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.
-
Jan 7th, 2012, 11:28 AM
#10
Re: End
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.
My usual boring signature: Nothing
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|