View previous topic :: View next topic |
Author |
Message |
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Wed Jun 28, 2006 11:25 am Post subject: New GUI system in development. |
|
|
I'm going to develop a new GUI system for use of my Arc library. The GUI system will work like this...
Code: |
GUI gui = new GUI(); // use GUI("file.gui") to load a saved GUI
Layout layout = new Layout(200,200, TABLE); // RADIAL or ABSOLUTE
layout.setTableSize(1,3);
layout.addWidget(new Button());
layout.addWidget(new Textfield());
layout.addWidget(new Label());
gui.addLayout(layout);
gui.save("file.gui");
|
The GUI will be saved and loaded in XML format.
Layouts
A layout is a rectangular area where one can place widgets. A gui might consist of a number of different layouts, or only draw one layout at a time. Layouts could also be used to create dialog boxes. Layouts can be determined by a table, a circular clock digit like layout, or just use absolute positioning. Give layouts the ability to contain themselves.
Widgets
* Button
* TextField
* Label
* Image
* Box
Skin system
All GUI widgets will allow the user to give the option of giving it a multi or single animation skin ("button hover/click animations"). That way an artist could really create a nice looking GUI.
This will expand as I think about it more.
Last edited by clayasaurus on Sun Aug 13, 2006 5:18 pm; edited 5 times in total |
|
Back to top |
|
|
Lutger
Joined: 25 May 2006 Posts: 91
|
Posted: Wed Jun 28, 2006 12:06 pm Post subject: |
|
|
Cool. This can be a real boost for arc users, a gui can be a pain to get right and take quite some time. I had one coming along nicely in C++ just before moving over completely to D I'm still thinking of picking it up in D, I have some design ready.
I'm looking forward to see how it turns out, imho XML based gui is the way to go and of course skinnable is a must for games. |
|
Back to top |
|
|
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Wed Jun 28, 2006 12:13 pm Post subject: |
|
|
Yea, GUI systems are a real pain. In the past I've tried my hand at them twice, but I failed at the design both times. This time, I think I got the design right, however I'll leave it here to mature for a bit and get input from others before I start working on it. |
|
Back to top |
|
|
Phr00t
Joined: 03 Mar 2006 Posts: 203
|
Posted: Wed Jun 28, 2006 12:30 pm Post subject: |
|
|
I'm using some simple buttons I made in FreeUniverse... but I would like to switch over to something a little better (e.g. use textboxes to determine how many of an item you want to buy/sell) -- I'll be watching this! |
|
Back to top |
|
|
Lutger
Joined: 25 May 2006 Posts: 91
|
Posted: Wed Jun 28, 2006 12:37 pm Post subject: |
|
|
clayasaurus wrote: | Yea, GUI systems are a real pain. In the past I've tried my hand at them twice, but I failed at the design both times. This time, I think I got the design right, however I'll leave it here to mature for a bit and get input from others before I start working on it. |
Good idea. For what it's worth, here is my input:
- ability to create a gui completly in XML is a big plus.
- signal slots for hooking up gui and game code, I saw a signal slots library floating around somewhere at dsource, anyway it's not hard to create in D, I use this now instead of callbacks mostly.
- seperating visual style from widget logic code, I used the bridge pattern to connect a style with a widget which worked out nicely, in the beginning...
- one thing that helped me with positioning was the ability for each widget to contain children widgets, and letting children specify their position and size relative to their parents. I think my code was following the composition pattern.
I had, through macro hackery but it can be done nicely with versioning, a conditionally compiled version of the gui which you could alter at runtime and saved itself to xml at program exit. Sort of a runtime designer if you wil, resizing and dragging widgets was working. This way you'd have total WYSIWYG.
My gui broke apart when I got to things like sliders. Apparently, the seperation between visuals and logic was not done well. |
|
Back to top |
|
|
gamerChad
Joined: 13 Aug 2005 Posts: 21 Location: Cydonia, Mars
|
Posted: Wed Jun 28, 2006 7:02 pm Post subject: |
|
|
Hey how far along is this?
I ask because I happen to be doing exactly the same thing, that is, writing a GUI library that is intended for game development. I'm not very far into mine, about 1000 LOC and I haven't even done a test run yet (hehe, debugging should be fun...). It is probably better that we don't duplicate effort though
Here is the wishlist I am designing my GUI to meet:
- Virtual coordinate system: design on a 65535x65535 screen, scale the coordinates down for actual rendering. 65535x65535 not required, smaller resolutions may be used.
- For widgets, and parts thereof, that are on the part of the screen being refreshed every frame, blit them to the backbuffer every frame. For widgets not in that part of the screen, update them in an event-driven manner.
- Depends only on SDL. Might use SDL_TTF for fonts or something else if the something else is cross-platform enough. Other APIs can be swapped in with minimal effort, which should make an eventual OpenGL port easier. Being a game GUI lib, I figure native look-and-feel or such things are not needed, so I'm not putting any effort into OS specific code. No windowing planned either (unless it's from within the framebuffer).
- Skinnable (of course) |
|
Back to top |
|
|
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Wed Jun 28, 2006 10:03 pm Post subject: |
|
|
gamerChad wrote: | Hey how far along is this?
|
Design stage. I don't like to code until I think my design is solid because I've been there done that.
Quote: |
I ask because I happen to be doing exactly the same thing, that is, writing a GUI library that is intended for game development. I'm not very far into mine, about 1000 LOC and I haven't even done a test run yet (hehe, debugging should be fun...). It is probably better that we don't duplicate effort though
|
That's nice. I think the problem is that we are developing GUI's for two slightly different systems, I'm guessing yours is SDL software rendering, and mine is OpenGL rendering. Plus I'll be making use of features in my library which your GUI may/may not have access to.
Quote: |
Here is the wishlist I am designing my GUI to meet:
- Virtual coordinate system: design on a 65535x65535 screen, scale the coordinates down for actual rendering. 65535x65535 not required, smaller resolutions may be used.
|
#1) Who uses a square sized screen
#2) Why do you need so much resolution? I use 800x600 virtual coordinates for Arc, and you can get more 'detail' by using float coordinates.
Quote: |
- For widgets, and parts thereof, that are on the part of the screen being refreshed every frame, blit them to the backbuffer every frame. For widgets not in that part of the screen, update them in an event-driven manner.
|
I'm probably going to keep it simple and just update all GUI components every frame, as I don't think these are considerable performance gains.
Quote: |
- Depends only on SDL. Might use SDL_TTF for fonts or something else if the something else is cross-platform enough. Other APIs can be swapped in with minimal effort, which should make an eventual OpenGL port easier. Being a game GUI lib, I figure native look-and-feel or such things are not needed, so I'm not putting any effort into OS specific code. No windowing planned either (unless it's from within the framebuffer).
- Skinnable (of course) |
Mine will depend on my own game library, Arc. |
|
Back to top |
|
|
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Wed Jun 28, 2006 10:09 pm Post subject: |
|
|
Quote: |
- signal slots for hooking up gui and game code, I saw a signal slots library floating around somewhere at dsource, anyway it's not hard to create in D, I use this now instead of callbacks mostly.
|
I'll have to look into this, never done work with signals and slots. Could you find the library perhaps? And maybe a sample of how to use it.
Quote: |
- one thing that helped me with positioning was the ability for each widget to contain children widgets, and letting children specify their position and size relative to their parents. I think my code was following the composition pattern.
|
I think I'm going to make my 'Layout' class capable of this.
Quote: |
I had, through macro hackery but it can be done nicely with versioning, a conditionally compiled version of the gui which you could alter at runtime and saved itself to xml at program exit. Sort of a runtime designer if you wil, resizing and dragging widgets was working. This way you'd have total WYSIWYG.
|
I'm going to hold off on making any sort of 'GUI designer' |
|
Back to top |
|
|
gamerChad
Joined: 13 Aug 2005 Posts: 21 Location: Cydonia, Mars
|
Posted: Wed Jun 28, 2006 10:25 pm Post subject: |
|
|
Quote: | #1) Who uses a square sized screen
#2) Why do you need so much resolution? I use 800x600 virtual coordinates for Arc, and you can get more 'detail' by using float coordinates. |
1 - It's virtual. It can be any aspect ratio you desire. I prefer the max and then I will think in terms of fractions and hex, but the person using the library will be able to set it to something else as they desire. X and Y are scaled individually and will end up in the correct aspect ratio for blitting.
2 - Because I can have it. Aspect ratio issues aside, it should scale very nicely to any display device ever made by mankind. I'm also designing for an eventual pocket pc target, so floating point is a big no-no since xscale type arm processors don't have FPUs.
Quote: | That's nice. I think the problem is that we are developing GUI's for two slightly different systems, I'm guessing yours is SDL software rendering, and mine is OpenGL rendering. Plus I'll be making use of features in my library which your GUI may/may not have access to. |
Quote: | Mine will depend on my own game library, Arc. |
The only problem I see with that is you will be making a gui that only works with Arc, when it could work with any game. GUIs can be applied to far more than arcade games. You're probably fine with that though, so I'll shut up
Good luck with your GUI! |
|
Back to top |
|
|
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Thu Jun 29, 2006 9:16 pm Post subject: |
|
|
Thanks. Yea I'm not trying to make a universal 'fit all' GUI like you are, but rather a GUI that works well with Arc. |
|
Back to top |
|
|
Lutger
Joined: 25 May 2006 Posts: 91
|
Posted: Fri Jun 30, 2006 4:51 am Post subject: |
|
|
A gui made for 2D arcade library can be tailored to fit, I didn't really think a lot about how that will turn out but it will definitly be a plus in ease of use and implementation.
About signal slots, there is dcouple here at dsource. Check out the documentation, there's a fine introduction in there: http://svn.dsource.org/projects/dcouple/trunk/managed/doc/index.html
There will be a little code to set up classes that can use signal-slot connections, but then it's simply a matter of storing (connecting) callbacks (slots) in a signal. Firing the signal results in all slots being called. It will look something like this:
connect (button.quit, game.pause);
connect (button.quit, sounds.button);
connect (button.quit, dialog.areYouSure);
// ... then somewhere else in your code:
button.quit(); // calls game.pause(), sounds.button() and dialog.areYouSure()
The advantage of signal slots is easily managing multiple callbacks on the same event, automatic tracking of the validity of callbacks and decoupling classes thus reducing dependencies. |
|
Back to top |
|
|
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Fri Jun 30, 2006 6:19 am Post subject: |
|
|
Thanks alot Lutger, I'll look into it. |
|
Back to top |
|
|
DMINATOR
Joined: 20 Jun 2006 Posts: 15 Location: Tallinn, Estonia
|
Posted: Thu Jul 06, 2006 12:59 pm Post subject: |
|
|
I have also made a few gui systems before
This was my first attempt = failed
This is my latest gui, I am currently using for my game projects:
It is not that hard actually to make. Just a few base classes needed, then it is a matter of deriving classes, and extending their functionality.
I have a base class called Abstract which has all the basic properties such as position , size, skin Id to use for drawing , and so on.
There are 4 states of base class:
Normal , Hover , Clicked , Disabled. - They can be use for example to show different effects, and to operate with this object.
The skinning is not hard also, There is a list of skins, each skin in the list has 4 actions , the same as above. Now if we draw the component , it just calls to draw the skin, but selects the current state the component is in (mouse is hovered for example).
There were some tricky parts, the most annoying is the positioning of components on the parent, calculating the child coordinates on the screen, must take into consideration all their parents positions. Everything else is pretty fun and easy if you have a good design idea before you start to write a single line of code. And in D it would be extremelly fun
And about the functionality here is a part of options menu:
Code: |
//let's load specifig gui skin
gui.Start("gui/denny.cfg");
//Options window
GUI_Window menu_formOptions;
GUI_Button menu_closeOptions;
GUI_Button menu_saveOptions;
GUI_TabControl menu_tabControl;
GUI_TabPage menu_tabPageGeneral;
GUI_TabPage menu_tabPageVideo;
GUI_TabPage menu_tabPageAudio;
// Options - General
GUI_Button menu_GeneralButtonTest;
GUI_CheckBox menu_GeneralGrid;
GUI_CheckBox menu_GeneralBlocksDrop;
GUI_Label menu_GeneralGameplay;
gui.AddWindow(&menu_form1);
gui.AddWindow(&menu_formOptions);
menu_formOptions.AddComponent( &menu_closeOptions );
menu_formOptions.AddComponent( &menu_saveOptions );
menu_formOptions.AddComponent( &menu_tabControl );
menu_formOptions.visible = false;
menu_formOptions.left = 0.21f;
menu_formOptions.top = 0.2f;
menu_formOptions.width = 0.4f;
menu_formOptions.height = 0.4f;
menu_formOptions.caption = "Options";
//call back methods to activate on click
menu_formOptions.OnResize = &menu_formOptions_OnResize;
menu_closeOptions.caption = "Cancel";
menu_closeOptions.OnClick = &menu_closeOptions_OnClick;
menu_saveOptions.caption = " OK";
menu_saveOptions.OnClick = &menu_SaveOptions_OnClick;
menu_formOptions.close_button.OnClick = &menu_closeOptions_OnClick;
void menu_closeOptions_OnClick(GUI_Abstract *sender)
{
//hide window
menu_formOptions.visible = false;
}
//destroy the gui
gui.Destroy();
|
|
|
Back to top |
|
|
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Mon Jul 17, 2006 12:06 pm Post subject: An update... |
|
|
Here's an update on what I've figured out with my gui. First, the GUI will be dependent on 3 types of XML files.
1) Layout.xml -> Holds a layout, such as a 'dialog box' or 'game menu'
A layout is composed of a number of widgets with certain positions, sizes, and text. With a few simple building block widgets, complex game specific layouts can be created and reused between projects, plus people can share their layouts. All layout positioning will be abosolute.
2) Skin.xml -> holds all skin information, font, animations, sounds, and times between frames for each different type of widget.
3) GUI.xml -> Will point to the skin.xml file and the layout.xml files that are going to be used.
Since absolute positioning is a pain I'm going to create a visual layout editor so one can create layouts and view them with any skin they wish.
Here's my progress on the GUI...
1) Changed sprite class so it has 2 different types of collision, basic (which is what my gui uses) can collide boxes, cirlcles, and circles against boxes, and all of these against mouse x and y coordinates.
Polygon (which the new physics system uses) collides polygons against each other.
2) XML parser can read full Skin.xml file
TODO
1) Implement widgets and display them with given skins
2) Read layout.xml file
3) Layout editor
4) Putting it all together with GUI and callbacks, the callback setting system is for the most part designed. |
|
Back to top |
|
|
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Tue Jul 18, 2006 12:28 pm Post subject: |
|
|
Using this file
Code: |
<layout name="imagetest" skin="skin.xml">
<image x="0" y="0" width="100" height="125" name="img1">
<frame animation="default" image="penguin.png" speed="1000" soundfx="null"/>
</image>
<image x="100" y="125" width="100" height="125" name="myimg">
<frame animation="default" image="penguin.png" speed="1000" soundfx="null"/>
<frame animation="default" image="king.jpg" speed="1000" soundfx="null"/>
</image>
<image x="200" y="250" width="100" height="125" name="img2">
<frame animation="default" image="king.jpg" speed="1000" soundfx="null"/>
</image>
</layout>
|
I am able to load up the images widgets with all the correct settings and animations. the skin will have no effect on the image widget, since the purpose of this widget is just to display a possible multi animation widget with soundfx.
I also fixed 2 bugs in the texture loader...
1) toStringz to convert char[] to char* for IMG_Load() function... this function was picking up garbage otherwise
2) Convert surface to 32 bit RGBA if it is not already |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|