EagleEye
13-03-2006 23:21:47
For those of you who want to develop the core of your game first, without having to mess around with CEGUI right away, I have a nifty solution for you.
See, I got tired of CEGUI because it was limiting my ability to develop the core of my game... specifically data manipulation, transmission to the server, and thus, server development. I couldn't do much of this IMPORTANT stuff, because my GUI had to be in place to present all of that data (and the GUI elements to manipulate it) before I could continue with the behind-the-scenes stuff.
Enter Windows.Forms!
At first, I thought I would simply transition to having the Ogre render window be encapsulated inside a panel control on a windows.forms form, and do all of my GUI work in Windows.Forms. This was an attractive solution, simply because of how cumbersome CEGUI can be, especially without the fully featured forms designer that you have available for Windows.Forms. I understand CEGUI has its own WYSIWYG editor that writes XML layout scripts for you, but this wasn't an attractive option for me (I want all of my window layouts done in-code... and you may have other reasons for not liking this solution)...
What I've moved to is a HYBRID solution! Instead of working so hard on getting my in-game GUI done, I have started creating Windows.Forms controls, and am using them as temporary GUIs until I can dedicate the time I need to creating those in-game GUIs. In the meantime, I'm able to use the Windows.Forms forms to present and manipulate data, so I can move on to more productive things like networking and server development.
But, how do you do it?
First, you have to create an instance of the form in your application.
You may, if you like, create an instance when you NEED the form, then dispose of it when it's done... Personally, I'm just creating a new instance of the form at run-time, and using show/hide to control when the form is in view.
In your main module (the one that creates your main Ogre Renderer Window), simply declare some public variables as new instances of those forms.
For example, in mine:
MainWindow is my container class for the Ogre Render Window. Those others are all Windows.Forms.Form objects. I simply show/hide them as necessary.
One of the problems I ran in to was that since there is no main controlling window (A Windows.Forms.Form object is not set to be the startup object for the application), the Windows.Forms.Form objects were not running in a master control loop. Events weren't being processed off of the message queue. This means my windows would appear, but be "blank" or just "white", or they wouldn't update.
The simple solution was to put the following inside "sub new" for each of my Windows.Forms objects:
You may recognize the first part, where it does the "MyBase.New()" and "InitializeComponent()". Those are inserted automatically by the forms designer.
"Created" is an inherited property of Windows.Forms.Form objects. Basically, it's almost like a "While ThisForm is not disposed".
Then you simply tell it to "DoEvents"... this will process any pending events in the message queue, including drawing, redrawing, refreshing sub-objects (buttons, textareas, etc)... and make the form act as it should.
It's important to note that I have
in my header for each of these Forms classes.
You may now use your form as you would any other CEGUI form... pass it data, have it handle events, etc, etc...
You can also use this little tidbit to create quick and dirty windows for testing things that aren't meant to stay in your application. Why bother going through the trouble of using CEGUI to develop a GUI, when you can create a quick Form with a button and an textarea for output, just to test something?
Anyway, hope this helps!
See, I got tired of CEGUI because it was limiting my ability to develop the core of my game... specifically data manipulation, transmission to the server, and thus, server development. I couldn't do much of this IMPORTANT stuff, because my GUI had to be in place to present all of that data (and the GUI elements to manipulate it) before I could continue with the behind-the-scenes stuff.
Enter Windows.Forms!
At first, I thought I would simply transition to having the Ogre render window be encapsulated inside a panel control on a windows.forms form, and do all of my GUI work in Windows.Forms. This was an attractive solution, simply because of how cumbersome CEGUI can be, especially without the fully featured forms designer that you have available for Windows.Forms. I understand CEGUI has its own WYSIWYG editor that writes XML layout scripts for you, but this wasn't an attractive option for me (I want all of my window layouts done in-code... and you may have other reasons for not liking this solution)...
What I've moved to is a HYBRID solution! Instead of working so hard on getting my in-game GUI done, I have started creating Windows.Forms controls, and am using them as temporary GUIs until I can dedicate the time I need to creating those in-game GUIs. In the meantime, I'm able to use the Windows.Forms forms to present and manipulate data, so I can move on to more productive things like networking and server development.
But, how do you do it?
First, you have to create an instance of the form in your application.
You may, if you like, create an instance when you NEED the form, then dispose of it when it's done... Personally, I'm just creating a new instance of the form at run-time, and using show/hide to control when the form is in view.
In your main module (the one that creates your main Ogre Renderer Window), simply declare some public variables as new instances of those forms.
For example, in mine:
Public Engine As New MainWindow
Public OP As New frmOptions
Public CW As New frmCharacter
Public SW As New frmSkills
Public GW As New frmGuild
MainWindow is my container class for the Ogre Render Window. Those others are all Windows.Forms.Form objects. I simply show/hide them as necessary.
One of the problems I ran in to was that since there is no main controlling window (A Windows.Forms.Form object is not set to be the startup object for the application), the Windows.Forms.Form objects were not running in a master control loop. Events weren't being processed off of the message queue. This means my windows would appear, but be "blank" or just "white", or they wouldn't update.
The simple solution was to put the following inside "sub new" for each of my Windows.Forms objects:
Public Sub New()
MyBase.New()
'This call is required by the Windows Form Designer.
InitializeComponent()
'Add any initialization after the InitializeComponent() call
While Created
Application.DoEvents()
End While
End Sub
You may recognize the first part, where it does the "MyBase.New()" and "InitializeComponent()". Those are inserted automatically by the forms designer.
"Created" is an inherited property of Windows.Forms.Form objects. Basically, it's almost like a "While ThisForm is not disposed".
Then you simply tell it to "DoEvents"... this will process any pending events in the message queue, including drawing, redrawing, refreshing sub-objects (buttons, textareas, etc)... and make the form act as it should.
It's important to note that I have
Imports System.Windows.Forms
in my header for each of these Forms classes.
You may now use your form as you would any other CEGUI form... pass it data, have it handle events, etc, etc...
You can also use this little tidbit to create quick and dirty windows for testing things that aren't meant to stay in your application. Why bother going through the trouble of using CEGUI to develop a GUI, when you can create a quick Form with a button and an textarea for output, just to test something?
Anyway, hope this helps!