GUI for Xith

Engines, Libraries and Tools Xith3D Forums
#10

You need more than that, only a little, but it makes a huge difference. For proper, real, automatically resizing layout you need to copy HTML ;D

  1. Each component has a size, that is either explicit (width=50px) or implicit ( width=75%; defaults to 100% if not specified).
  2. Implicit sizes are calculated “relative to the parent’s available area”
  3. The parent’s available area defaults to 100% of its size, but can be set to any percentage of this (available=90% would mean available-width is 90% of the parent container’s width), or to a fixed size relative to its size (available = -10px would mean “my area minus 10 pixels on top, bottom, left, right”)

This simple scheme is enough to do almost any conceivable layout in a very easy to maintain and non-verbose manner. W3C got it very right about layout; Sun got it very wrong.

#11

That’s what I wanted to say, except I don’t know how to make explicit sizes with the following base principle :

  • The GUI is by default made with a fixed resolution, e.g. 1024x768, and for the lower resolutions (canvas size changed : 800x600 or 640x480) the textured quad is resized : so the GUI looks exactly the same with any resolution with a 4/3 ratio.
    Do you see what I mean ?
#12

There are bigger problems than that: The GUI can be displayed at different aspect ratios. For example, on a widescreen computer the aspect ratio is different to that of a 4:3 monitor. While you can just add black bars, or stretch the widescreen one, it’s not the best solution to do this.

Take a game like Warcraft III - that will happily run on a widescreen computer, the GUI just magically “works” (maybe there’s some clever padding in there, I shall investigate). Interestingly (my brother and I did a test of this), when on a widescreen computer, you actually do see more of the playing field than when not, which suprised us both since it gives the widescreen player an advantage (however small).

In my game, where the “UI components” are manually placed, on the widescreen, they stay there but you can see more of the scene either side. Obviously I need to make them relitive to the left/right.

As far as changing the aspect ratios go, the UI can either be scaled to fit (like warcraft), or kept at it’s “native” resolution (like Red Alert 2). Idealy, the scalar components should scale smoothly (fonts, etc).

Good idea with the HTML-esk type layout blar - makes sense to me.

Cheers,

Will.

#13

Wouldn’t it be possible to get the positions on the plate to make picks at the corners of the screen and the interpolate between the intersection points? You’ll only have to do the picks once, so this will not be performance problem.

#14

Hi

The HUD system I created for Java3D had 3 types of positioning, fixed, relative, and mixed. fixed is obviously ‘place it 15 pixels across, 10 up’ type things, relative is ‘place it 10% of the way up the screen, 90% of the way across’ and mixed, was ‘place it 15 pixels up from 50% of the way up the screen’ type things. This worked great for placing the componenets, even on my widescreen laptop :).

However, I tried porting it to xith, but my hud relied on forground plates in the 3d world, and the texture coords were set by picking in each corner of the component. Under xith, you can only get the object picked, not the coords, so for now at least, it’s java3d only. Unless anyone fancies implementing picking that returns a point3f :slight_smile:

Endolf

#15

Not really, because it sounds like you are defining precisely the situation where you would want to use no explicit sizes at all. This is not the best terminology, I appreciate, but it made sense at the time :frowning: - recall that “implicit” just means “defined by a percentage not a pixel size”, i.e. the “size in pixels is implicit”, even though “the size is explicit, in the meaning of the english word explicit”.

If you define all sizes implicitly then the GUI automatically scales up and down independent of resolution.

Normally, you have some things you want to have actual size.

Most obvious example: the shortcut bar for things like WoW or the inventory window in an RPG. You have lots of icons for these bars/windows that are fixed size (e.g. 64x64). At higher resolutions, you want the whole GUI to scale up, EXCEPT FOR the inventory / shortcut bar, whose size you want to scale up (like everything else), but whose contents you dont want to scale: you just want to draw more cells (i.e. you get a shortcut bar with more options, or you can see more of your inventory without scrolling). This is a perfect case for defining your cells in the bar/window using explicit pixel sizes. Then everything “just works”: you get a GUI that resizes to be resolution independent, apart from the inventory etc that just draws more or less of it’s contents :).

This works best with some utility layout classes, which are almost trivial to implement. e.g. I have several times (for different employers ;)) written a “gridWithFixedSizeCells” class that acts just like you’d expect an RPG inventory window to work - you add things to it, and they all have the same fixed size, and it just displays as many of them as it can within it’s size (whatever size has been given to it by it’s parent).

#16

I’ve did picking that returns a point3d (there has to be some thread about that here around - do search) There is also some code in the xith-tk which does that.

Picking a point3f
#17

Okay, so I think there’s two manners to do.
Take a button for example. In a “Displaying Engine”, using the pre-defined image-based functions, you’ll have 6 little images composing the button + a grey fill hard-coded. ( See attachment )
If we do as I say ( resizing the entire GUI ) everything’s look good, and the border of the buttons will grow as its text.
If we do more in a way blahblahblahh proposes, the text will be redrawn larger, and the border will be still at the same size.
Hmmm… the best way’s probably the second…
The problem is if we want a game that looks exactly the same with a 640x480, 800x600, 1024x768 or 1280x960 resolution, we’re obliged not to define components size with explicit size. Maybe we can do an option, if components are resized or not when the screen size ( canvas size ) is changed ?

#18

( Note : it’s true not only with buttons border : am image will looks two times bigger with a 640x480 resolution than with a 800x600 resolution… maybe that’s not a problem… )

#19

Yeah, that’d be very useful.

#20

For that, I had either two types of button, or more normally a button with two constructors and a “mode” int:

MODE_NORMAL: the borders are fixed-size (explicit, pixels), and whatever is added as the image / text / content of the button (unlike Swing, I like to add( component ) to a button to make it’s content! Much much cleaner and more powerful) is given 100% of what remains.

If you think about it, this is all much simpler than swing: my buttons are just containers that take only one add()'ble element: they’re “avaialble area” is defined as “whatever is left over after the button has allocated space for its borders”. A default component (defaults to 100%) added to a default button will automaticaly render in the full space of the button’s center, and not overlap the borders.

EDIT: so, not only can you add anyting to become the rendered portion of a button, but you don’t need any special code (you don’t need all this crappy ImageIcon stuff from Swing just to put an Image object on a JButton). KISS…

EDIT: this also, obviously, makes animated buttons extremely easy: no special code!

MODE_FIXED_ASPECT: the borders are given implicit sizes (percentages), and all the other code remains identical.

The constructor would be e.g.: button( int mode, int borderDepth ), where depending upon mode, borderDepth is either a percentage or a pixel size.

There are, of course, cleaner OOP ways to do that method :wink: but this is just the quick-n-simple method I’ve used before.

#21

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.

#22

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.
#23

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.

#24

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

#25

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 :).

#26

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)

#27

“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.

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 ?

#28

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

#29

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