FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

New GUI system in development.
Goto page 1, 2, 3  Next
 
Post new topic   Reply to topic     Forum Index -> ArcLib
View previous topic :: View next topic  
Author Message
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Wed Jun 28, 2006 11:25 am    Post subject: New GUI system in development. Reply with quote

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
View user's profile Send private message AIM Address
Lutger



Joined: 25 May 2006
Posts: 91

PostPosted: Wed Jun 28, 2006 12:06 pm    Post subject: Reply with quote

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 Crying or Very sad 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
View user's profile Send private message
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Wed Jun 28, 2006 12:13 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
Phr00t



Joined: 03 Mar 2006
Posts: 203

PostPosted: Wed Jun 28, 2006 12:30 pm    Post subject: Reply with quote

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
View user's profile Send private message
Lutger



Joined: 25 May 2006
Posts: 91

PostPosted: Wed Jun 28, 2006 12:37 pm    Post subject: Reply with quote

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. Very Happy

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
View user's profile Send private message
gamerChad



Joined: 13 Aug 2005
Posts: 21
Location: Cydonia, Mars

PostPosted: Wed Jun 28, 2006 7:02 pm    Post subject: Reply with quote

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 Smile

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
View user's profile Send private message
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Wed Jun 28, 2006 10:03 pm    Post subject: Reply with quote

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 Smile


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
View user's profile Send private message AIM Address
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Wed Jun 28, 2006 10:09 pm    Post subject: Reply with quote

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. Very Happy


I'm going to hold off on making any sort of 'GUI designer'
Back to top
View user's profile Send private message AIM Address
gamerChad



Joined: 13 Aug 2005
Posts: 21
Location: Cydonia, Mars

PostPosted: Wed Jun 28, 2006 10:25 pm    Post subject: Reply with quote

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 Smile

Good luck with your GUI!
Back to top
View user's profile Send private message
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Thu Jun 29, 2006 9:16 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
Lutger



Joined: 25 May 2006
Posts: 91

PostPosted: Fri Jun 30, 2006 4:51 am    Post subject: Reply with quote

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
View user's profile Send private message
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Fri Jun 30, 2006 6:19 am    Post subject: Reply with quote

Thanks alot Lutger, I'll look into it.
Back to top
View user's profile Send private message AIM Address
DMINATOR



Joined: 20 Jun 2006
Posts: 15
Location: Tallinn, Estonia

PostPosted: Thu Jul 06, 2006 12:59 pm    Post subject: Reply with quote

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 Smile

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
View user's profile Send private message MSN Messenger
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Mon Jul 17, 2006 12:06 pm    Post subject: An update... Reply with quote

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
View user's profile Send private message AIM Address
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Tue Jul 18, 2006 12:28 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> ArcLib All times are GMT - 6 Hours
Goto page 1, 2, 3  Next
Page 1 of 3

 
Jump to:  
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