GUI for Xith

[Niwak]

In my WIP ui system (which was started with Xith but has moved to my own engine since), I run against the choice you are talking about.

It turns up that, as soon as you start some complex widgets like a game UI, automatic resizing behaviors are not satisfying (either fixed ot not). I choosed to use a design similar to the one of Swing (LayoutManager interfaces for container widget and LayoutConstraint for contained widget) and it solved everything.

The layout classes are really easy to develop and they are much more flexible. So I think you should think about using this type of design.

Good luck

Vincent

Note : by the way, here are a few of the problems I encountered that, I think, are quite usual when building an ui system ;

. Requirements ;
I found that the requirements for a game ui are rather higher than for a more traditionnal ui system. In particular ;

• you have to handle 2D objects as well as 3D
• you have to have a very powerfull skinning system or the ui will only work for one game…
• you must be able to adapt to different screen resolutions
• your system must be able to live beside itself and the OS ui (for example when you have a non fullscreen application with more than one view canvas)
• you have to design an efficient ressource manager since OpenGL needs you to handle it (texture leaks, vertex buffer leaks,…)
  It appeared that these requirements should be taken in account from the beginning of the design since they have quite a big impact on it and were difficult to add in the system later.

. General hierarchy ;
I tryed different hierarchy and finally ended with a main Shell object which was the main container. The shell object was in charge of forwarding canvas events to widgets. It was also in charge of keeping track of the focus.
I had to split the hierarchy betwwen IWidget2D and IWidget3D obviously corresponding to 3D objects (for example a player in the game) and 2D objects (for example abutton).
When events occured in the canvas, the shell would first check if the event should be routed to the IWidget2D object hierarchy (simple 2D math) and, if not, then perform picking in the scene (ray casting and bounding volume checking).

. Skinning ;
I started with a somewhat unflexible skinning system. I finally moved to a factory pattern for skinning ; the skin is a factory wich creates the basic widgets (button, list, frame, …) and ui parts (title bar, frame border,…).
A default factory implementation provides default implementation for complex widget (frames, list,…) using the ui parts which are not implemented in the default factory implementation (abstract methods which are implemented by skins).

. Widget hierarchy against Scenegraph hierarchy ;
I made some mistakes by not keeping in mind that Widgets are Scenegraph node but there hierarchy is not the one of the scenegraph.

[eMKa]

It’s just so cool to see all the ideas on this thread, but… We have to make a choice.
Now I’ll say what I think is cool (and will probably makes me some enemies that will think I don’t like their ideas ;D ;D ;D) :
I think it would be cool to do a simple alternative HUD system, with the following features :

• There’s no hierarchy, all components have a Z position
• There’s no layout handling, all objects are foreground textured quads that have size relative to the view and resize automatically with the canvas (done by OpenGL, not by me 8))
• The input is made by picking, using Arne picking function, with the HIAL input layer
• For the skinning : There’s a factory that draws basic elements, you can set a different factory for each component, you can make your custom factory, and there’s a factory that use images (that you should specify).
  Actually I work a lot on the Gamma game engine, but I’ll soon find some time to implement this basic HUD System.

[divzero]

Pretty good.

However, I can really see the point of including of blar’s fixed aspect ratio option. This means that people with more screen real estate can get to see more of the game (if you let them). I also don’t see the problem with having layout functions like 10 points from the top of screen, etc, nor do I think this would be particularly hard to implement. It’s just so much more maintanable for the end-developer than having everything as absolute coordinates. This is less than a complete layout manager, easier to implement, but still powerfull I think.

Will.

[kevglass]

True, but the stuff blah outlines can just be an extension to the base package that Magic describes. Best to get something simple, working and tested in first. Then build from there?

Kev

[blahblahblahh]

@kevglass

True, but the stuff blah outlines can just be an extension to the base package that Magic describes. Best to get something simple, working and tested in first. Then build from there?

Yes, but…this really is so simple to implement, it’s IMHO worth getting in from the start. I’d go looking for some of my code from previous runs with swing, and pass it over, but … it’s so simple its patronising :).

[arne]

> link=topic=10310.msg82525#msg82525 date=1123673994]

• There’s no layout handling, all objects are foreground textured quads that have size relative to the view and resize automatically with the canvas (done by OpenGL, not by me 8))

Umm what do you mean by “all objects” ? Every button, even border segments? Or do you want to make internal layouting in these Quads also? - then you would be there, whats blah^3 is talking about all the time. If not I think you’ll end up creating lots of triangles which could result in a slowdown (you’ll have to test much more quads with the picking algorithm + the renderer will have to render also more triangles)

[eMKa]

@arne

> link=topic=10310.msg82525#msg82525 date=1123673994]

• There’s no layout handling, all objects are foreground textured quads that have size relative to the view and resize automatically with the canvas (done by OpenGL, not by me 8))

Umm what do you mean by “all objects” ? Every button, even border segments? Or do you want to make internal layouting in these Quads also? - then you would be there, whats blah^3 is talking about all the time. If not I think you’ll end up creating lots of triangles which could result in a slowdown (you’ll have to test much more quads with the picking algorithm + the renderer will have to render also more triangles)

“All objects” mean “All components” : button, text field, lable, are components and they all have a textured quad.
And it can be a 3D geometry instead of a textured quad, permitting complex 3D GUI.

@blahblahblahh

@kevglass

True, but the stuff blah outlines can just be an extension to the base package that Magic describes. Best to get something simple, working and tested in first. Then build from there?

Yes, but…this really is so simple to implement, it’s IMHO worth getting in from the start. I’d go looking for some of my code from previous runs with swing, and pass it over, but … it’s so simple its patronising :).

I prefer not to start with that. Pixels have no sense in the concept I defend. To map Pixels with 3D Coordinates you need picking at the four corners of the screen and then interpolate between them. And after that, you’ll need to resize all the textured quads to be coherent. Is this what you call so simple ? Or I didn’t understand what you mean ? I don’t think so, but if you want you can implement it ( I’ll be pleased to implement UI components on this base ).
If we were using some AWT methods, drawing directly on the window, your positionning system would be easy to implement, yes, but with textured quads it’s really more difficult ( IMHO… ).
Do this image describe what you want to do ?

[eMKa]

Comment : The GUI Surface fit the bigger Screen surface possible, KEEPING THE SAME ASPECT RATIO.

[eMKa]

( Now excuse me but I feel a bit confused, because I blend the different notions you exposed… )