Small Gui System (SGS for short) for Xith

Engines, Libraries and Tools Xith3D Forums
#1

Okay, so me and jaakko777 have decided to make a GUI system for our own games, but in a common effort.
This is intended to be developed relatively quickly, and (I hope) it don’t need to be sophisticated.

Here are the defined concepts :

  • Uses Xith multi-pass render capability (class MultiPassView still to add to Xith core)
  • Uses Textured Quad in PARALLEL_PROJECTION mode
    [li]Doesn’t need picking, (maybe just for calibrating when the application is started or the GUI resized ?)

Other features/ideas need to be discussed.

I think we can start doing a sort of Panel object, that is just a colored quad. Then we can do TexturedPanel, a textured quad. Then we can do TexturedButton, a textured quad with mouse reaction. Then we can do TextLabel, using font -> texture generation. Then we can do TextButton and we will have an “acceptable” GUI system.

#2

@BlueSky: I suggest we start a shared project and set it up in either a cvs or svn repository. I can provide the former, if we want svn i might be able to set it up on friend’s server. But before that maybe we should exchange some mails to define the precise targets and the implementation. You got mail…

In the meanwhile others can post here wishlists on features (preferrably accompanied with some sort of implementation suggestions). That doesnt neccessary mean that we will do it, but atleast we’ll think it and hopefully we will atleast be able to leave room for implemeting it without hacking it. :wink:

#3

Why dont you set the targets out for the project and how its supposed to work out before attempting the fine detail of what projection policy to use ?

This way, more people will understand the uniqueness of the project and what its aimed at instead of saying “yeah, its another GUI tool…great”

DP

#4

;D Well, I guess mostly since threads about developing guis seem to draw out very long and we are both in urgent need of a gui. Im sure that as we get rolling this will change. I dont think that we are aiming at a complete solution, instead at forming quickly a extendable base to work from.

But this dont need to mean that we will develop this “in the dark”, im sure we will post here our targets so you can see whay we are up to.

#5

Hi,

I’d love to see a GUI library actually get released!

One important widgit that I think should be on the initial list with your other three would be a text input box.

Will you be using the 2D text classes already in the Xith-tk project?

One CVS option would be to use the xith-tk project, this is essentially why the project exists. That would have several advantages over a private server:

  1. It’s alrady setup and ready to go
  2. When I release a Xith3D build, your API would be included (also the javadocs on xith.org/javadoc)
  3. Easy for other people to contribute (with your permission)
  4. When the initial development has subsided, it can be easily maintained or further developed. Especially important if the Xith3D API changes
  5. It would increase the visibility of your API

Good luck!

Cheers,

Will.

#6

I agree, that would be required.

I dont know. I must say its a pretty way to do the 2d texts. However, one thing disturbed me when i checked it out, that the text was allways evenly aligned like in TrueType even if the font wasnt one. If we could change that im sure that would be a strong candidate. Another option would be to draw entire strings in the same manner. Or maybe support both ways. :-\

That sounds like a good idea!
How should we proceed to get the xith-tk repository in use?

Thanks :slight_smile:

#7

Ok, here are my toughts on the GUI, how i would do it…

1) Rendering the GUI on top of the Scene
The GUI will be implemented trough multipass rendering, where the GUI will be rendered last in PARALLEL_PROJECTION.

2) Receiving User Input
User input needs to be sent first to the GUI logic. If the GUI is not interested in the input then the scenegraph may have it. The GUI will have its own methods for receiving the input and the game will be responsible for forwarding the input to it. This approach also abstracts the input system and the game may implement whatever input system it likes. I must admit i have little or no experience with any input system exept the AWT Events, please point out any stupidities i may assume…

3) The GUI Structure
The GUI should be structured in components (UIComponent) and containers (UIContainer). Containers extend the component and can hold several other components as well as containers. These are base abstract classes that should be extended. The primary GUI object will be a UIFrame that extends the UIContainer. The frame will be able to receive the user input and will also be responsible for determining if the input has any effect on the GUI and for passing it on to affected component or container. A container upon receiving input will check on what of its components/containers the input has effect and pass it on. A component receiving input will call its attached UIListener if it has one. The UIListener interface is where the game should implement the functionality of the GUI.

4) Positioning of the Components on the Screen
The GUI should be able to position the components automatically to the appropriate Z-depth. This could be determined from the nearClipDistance or it could be set by the game. There should be enough room for the components to be layered on different Z-values. A component (and container) will always be lying on top of its parent container.
The coordinates for the component positions should be abstracted to screen coordinates (pixels). This is one thing that I’m not sure how to accieve… Needs research and helps n’ hints would be appreciated.

5) Extensibility of the GUI
The GUI base classes should be designed to be easily extended to create new components and containers.

6) 2D Components
These components are probably just colored/textured quads and should support adding Appearance objects to them.

7) 3D Components
These could most likely be treated as Shape3D’s in all aspects.

#8

One thing to consider is the “skinning of the GUI”

In my GUI components, based on the Xith UI, Each UI part has a know set of components, title lable, ui type icon, exit button, filler backgrounds texture etc. When I create a instance of a dialog for example, I pass in an adaptor structure (an array of textures) the dialog box displays based on the textures in each position, exit button is texture position 6, title background is position 2 for example. This allows me to reuse the same dialog, a collection of UI elements, but also allows me to override the display of these components by passing in different sets of textures.

I have a generic 512x512, a 256x256, and a 128x128 versions of the same components, appropriatewly resized. If the dialog does not require a title the the underlying panel, which is not opaque, is not displayed, Each GUI component also has a user-content panel allowing me a “add GUI elements” to the generic component. The added element may be a simple dialog structure or a tile game. This lets me reuse, extend and redesign a large set of GUI element using a small core set of classes. Does this make sense??

A game has a full set of textures, title, exit button, background textures, etc and a panel containing the actual game which is added to the user content panel.

A simple info box has almost all of textures undefined so that the associated parts don’t display and an alpha texture for the info. This approach allows me to display a comic type bubble window image with text and the rest of the rectangular dialog is transparent…in a sense allowing tme to displa non-rectangular alpha texture in a rectangular but transparent dialog.

#9

Wow! Sounds great.
Thats basically what i had in mind also, although i havent really tought that far yet.
Can you tell if you encountered any problems that should be assessed in design phase?

#10

Sign up for a dev.java.net account, and apply for “Developer” access to the Xith-TK project. I will approve it within 24 hours, then you are good to commit. I believe MagicSpark is already a developer of the TK project.

More info about the TK project:
http://xith.org/XithTKGovernance
http://xith.org/XithToolkitContributions

You will need to decide on a package name before committing anything. org.xith3d.ui.sgs perhaps? David’s unmaintained Xith3D swing UI is there named org.xith3d.ui.swingui.

Up to you really, I do think that the benifits of using the xith-tk project for this sort of undertaking are good though :slight_smile:

Cheers,

Will.

#11

The main thing in my setup is handling events. I use the hial lib to gather and store keystrokes and mouse events. For my simple purposes at the moment GUI’s retain their own events “exit button pressed” and the render loop queries the GUI for their indidvidual events and does the appropriate thing.

Dont overlay Xith UI componetnts GUI A with button B may/does not work if on top of GUI C. I thinl the Event the Xith GUI elements handle are based on mapping screen space to on event such as a mouse click if N GUI’s are on the same block of real estate the system falters…cant decide who got the evednt.

#12

Hmm… I was really intending to do components that can be layedred. Im pretty sure that if you keep record of their Z-value this can be done. But you would have to do it manually. And not only keeping record but updating the Z-values as the focus changes.

A component would allways be closer than its container. And no container should be at the same distance. Actually when this is done in PARALLEL_PROJECTION they can be spread over a huge distance as that has no meaning for their presentation, exept for what gets drawn on top of what - and thats just what we want.

Then you would just keep a record of their “distance” and based on that determine who gets the event if there is a conflict.

Im still considering also the picking since i cant believe that it would be a performance hit since there arent that many shapes in a gui to test for.

#13

@jaakko777 I totally agree with you on all you’ve said in your post with 1), 2)…

I agree. Picking is really practical for me because it permits me to converts easily mouse coordinates into world coordinates. For the Z-value stuff, I think it’s not really hard to do. Okay so we can begin soon (CVS stuff).

#14

Ok, now then as Will pointed out we need to choose the package name.
Do we use org.xith3d.ui.sgs or maybe something a bit more descriptive?

Im short of ideas, does anyone want to suggest something that goes with what we are planning?
This is something that cant be changed later so i guess its quite important —> youll have to live with it when its decided :P.

I took a dictionary/thesaurus to my aid and decided to whip up a few suggestions and here they are:

  • We are doing a really basic gui that is intended to be easily extended/modified. —> org.xith3d.ui.modular or org.xith3d.ui.abstract
  • Our gui is based on scenegraphs as opposed to swing. —> org.xith3d.ui.graph
  • It will make the renderer work in multiple passes. —> org.xith3d.ui.multipass

Dont get me wrong, org.xith3d.ui.sgs is fine by me but honestly I couldnt tell what it is by the package name…

#15

org.xith3d.scenegraph.ui ?
(jaakko777, look at the subject I just started on this board about Xith toolkit and all that stuff).

#16

My 2c: I think it would make sense (whatever the name) as a subproject of “ui” since it is a GUI related tool and can accompany the others already in there.

Will.

#17

I agree it should be there…
I’ll think about the name a few more days.

#18

I propose the name “Guild”. It stands for “Graphical User Interface Library for Developers”. I think it’s a funny name that goes well with this project and is pretty explicit because it has “Gui” in it. Note that if you find a better signification for the last “D”, you’re welcome.
So the package name would be org.xith3d.ui.guild.
I currently have to work a bit on my physic engine (hopefully it won’t be long), and then I’ll probably do an “implementation draft”, cause I need it for my physic test/debugging, and for my level editor too.

Oh and I also work on a triangulation algorithm (using the Two-Ears Theorem). Since my levels’ terrains are made of non convex 2D polygons, I need to triangulate them for displaying them and for collision checking. If it works well I’ll put it in the toolkit too, although it’s pretty more of a geometry library. Then I can put it in Gymli (By the way I have to set up a dev.java.net account for that project soon).

#19

Didn’t you want to call it sgs? Guild ofcourse is a funnier name :slight_smile:

[quote](By the way I have to set up a dev.java.net account for that project soon).
[/quote]
I’d hurry if I were you - they might take ages to approve your project :wink:

#20

Yes but, first Guild is a funnier name, as you said, and second it’s much more explicit (because containing the GUI letters in it).

I’d hurry if I were you - they might take ages to approve your project :wink:
[/quote]
Then they’ll wait… I don’t want to mind about making this project available to the other developers until my game is functional. Seems very selfish, but it’s really wise to do so, I just don’t want to make the same experience as I did with Gamma. (Although my personal libs are really better now than Gamma was… :slight_smile: )