Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (535)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  GUI for Xith  (Read 3448 times)
0 Members and 1 Guest are viewing this topic.
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Posted 2005-07-29 18:20:55 »

Hello,

You may have seen many people asking questions about the actual Swing GUI ( that isn't working very good ) and being actively ignored (!)
I think it's because we don't use that and don't have time to study the code for an answer.
We had a discussion already on that, and I *bump* another time, hoping it will produce some programming efforts.

So I think it would be good to do a true 3D GUI, with the following ideas :
  - Emulate the Swing API, ( not the look )  with the following components :
    - XComponent
    - XContainer
    - XFrame
    - XPanel
    - XLabel
    - XTextField
    - XButton
    - XProgressBar
    - XImage
  - Use Java2D image generation from text for the XLabel, XTextField and XButton components
  - Do a beautiful ( skinnable ? ) and customizable ( colors ) GUI : with special FX as color blending, transparency, and so on...

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #1 - Posted 2005-07-30 04:18:25 »

man that would be awesome! 

Do you really need all the container classes though? 

We do already have an image class -  org.xith3d.geometry.Quad which can be textured nicely (fair enough if you want to add a redundent version for completeness though).

When you say "true 3D", are you talking about 3D ordering and effects (on 2D quads)?

The way I see it:  The UI elements are all implemented as textured Quads.  The Container is really just an extension of BranchGroup.

Mouse events are tricky -- if you want to be able to embed a text box in the scene then picking is your only choice.  If you make a constraint that input only works when the BG is attached to a  Foreground node, then you can just map the XY screen coordinates (a far easier solution I think -- text output though could be plonked anywhere).   Of course, you can get your jazzy translucent effects, Z ordering etc.

I would like to help define the API.

How dedicated to completing this are you?  Unlike most people who have attempted the same, you seem to be a forum regular with some projects on the go.  Will you stay the distance?

Will.

Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #2 - Posted 2005-07-30 14:41:39 »

man that would be awesome! 
I think so..

Quote
Do you really need all the container classes though? 
Er... maybe not, we should just define if we want to make a "layout-manager-type-GUI-system" or a "pixel-position-based-GUI-system".
The container stuff would be useful in the first case.

Quote
We do already have an image class -  org.xith3d.geometry.Quad which can be textured nicely (fair enough if you want to add a redundent version for completeness though).
We can use it. What image format can we use for transparency support ? PNG, JPEG ?

Quote
When you say "true 3D", are you talking about 3D ordering and effects (on 2D quads)?
Hum... I was wondering about doing some models ( rounded boxes ) to make the UI looking good, but it isn't necessary, after all.

Quote
The way I see it:  The UI elements are all implemented as textured Quads.  The Container is really just an extension of BranchGroup.
Yes, that's probably the most "reasonable" way to implement it.

Quote
Mouse events are tricky -- if you want to be able to embed a text box in the scene then picking is your only choice.  If you make a constraint that input only works when the BG is attached to a  Foreground node, then you can just map the XY screen coordinates (a far easier solution I think -- text output though could be plonked anywhere).   Of course, you can get your jazzy translucent effects, Z ordering etc.
Or may we attach the BG directly to a Foreground node in the XComponent constructor ?
In all case, I think Foreground node as you describe it is the best solution.
However, I have to study the sourcecode to know exactly how it's working.
I've seen a Xith test ( I can't remember which ) where some Text is written directly on a texture. Is it using Java2D ?

Quote
I would like to help define the API.
Well, all contributions are accepted.
My only problem is I don't have any CVS access for Xith so I would be obliged to work locally, and others can't contribute directly..

Quote
How dedicated to completing this are you?  Unlike most people who have attempted the same, you seem to be a forum regular with some projects on the go.  Will you stay the distance?
I think I'll finish that, as far as I don't stop programming ( very unprobable... Smiley )
I've got good reasons for that :
 - That would be a valuable addition for Xith, and would help all its users, who provided me advice during 1 or 2 years
 - It's really needed for the Gamma game engine
 - It's a cool Java experience, and will improve my ( our ? )  knowledge of Java
 - I think it's very interesting, and generally I do what I think is interesting... Cheesy

BUT I can't do that alone, and I'm waiting for others contributors ( arne ? )

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #3 - Posted 2005-08-01 13:48:20 »

Okay, some API designing now...
Basically, to create a GUI, you need :
- A Canvas3D
- The main BranchGroup
The position and size of the components are defined in %, relative to their parents. So the GUI can be any size.
We have to make one thing so the textured quad used to display the GUI is always entirely displayed ( some parts may be hide when the window is resized, with a non-4/3 ratio ).
We have to make too one thing to map the coordinates on the textured quad with the coordinates of the mouse on the screen. Has anyone one idea on how to do that ? I think it's the only thing I don't know how to do.
For the rendering, we may think of themes as "Displaying engines".
There would be interface with drawComponent(Point2f position, Point2f size, Component comp), and the function can test which type of component it is and call graphic procedure ( included simplified images-based procedures ). If the component type is unknown ( home-made ) then the drawing is delegated to the component itself, with the default look&feel.
What do you think of that ?

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #4 - Posted 2005-08-01 16:19:14 »

you could probably very simply get your graphics by using Component.draw(Graphics). This way we would be also able to add fancy swing stuff to xith3d like JTree.
To save processing time a pick should also only be made when there's actually a click or a drag.
Or you could also try to project the quad to the screen and make a simple projection formula. This would only be good I think, when the quad has a static position relative to the view.

:: JOODE :: Xith3d :: OdeJava ::
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #5 - Posted 2005-08-01 17:12:43 »

you could probably very simply get your graphics by using Component.draw(Graphics). This way we would be also able to add fancy swing stuff to xith3d like JTree.
To save processing time a pick should also only be made when there's actually a click or a drag.
Or you could also try to project the quad to the screen and make a simple projection formula. This would only be good I think, when the quad has a static position relative to the view.
We choosed to draw the UI on a textured quad with the Foreground node, and to make a new UI system, without Swing.
Because Swing isn't suited for complex, beautiful game UI, and is slow.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #6 - Posted 2005-08-02 07:02:29 »

Quote
We choosed to draw the UI on a textured quad with the Foreground node, and to make a new UI system, without Swing.
Because Swing isn't suited for complex, beautiful game UI, and is slow.

This is an assumption, but I agree it's probably true.


Regarding CVS and project coordination, this is exactly what the Xith Toolkit project was set up for, so my vote is that we use that.  This way anyone can contribute, and it can be included in the official distribution.  If you havn't already got Dev access, please apply for it.

The root Node of a UI instance should definitally be a Branch Group.  This way one can easily add it to the scene, either embedded in the scene somewhere (import support), or encapsulated in a Foreground node (input support).

Regarding input support, the way I see it we have two options - picking, and resolving the absolute screen coordinates to the relative foreground coordinates.  I am not sure that the former would work.  The latter option I am sure is possible, but not totally sure as to the implementation.  I worked on a project recently where we managed to map precicely the XY screen coordinates to a textured quad in the scene.  I did this by setting the FOV to 90 degrees, and moving the camera to half the quad's hight (IIRC).  There would be a mathematical formula I'm sure that one could use to calculate this, based on the FOV.  To be honest, I do not know it (I did experiment with trial and error to work it out, but failed), but I did get it to work for a 90 degree FOV.  Maybe if I read some more OpenGL books I could work this relationship out.

Does everyone here use the HIAL input abstraction layer?  I do, and it allows me to seemlessly switch between the JOGL and LWJGL frameworks.  My vote would be to use this library as the import for the system (one really big advantage is that our UI would be totally abstracted from the actual input, allowing future input libraries to be used with no changes to our code).

A low level design question:  What does our pipeline look like?
Components drawn to a Graphics2D -> Graphics2D converted to Texture -> Quad texture updated?

Obviously for a snappy, and resource friendly UI we are going to want minimal overhead.

Cheers,

Will.

Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #7 - Posted 2005-08-02 15:15:34 »

Quote
We choosed to draw the UI on a textured quad with the Foreground node, and to make a new UI system, without Swing.
Because Swing isn't suited for complex, beautiful game UI, and is slow.

This is an assumption, but I agree it's probably true.


Regarding CVS and project coordination, this is exactly what the Xith Toolkit project was set up for, so my vote is that we use that.  This way anyone can contribute, and it can be included in the official distribution.  If you havn't already got Dev access, please apply for it.

The root Node of a UI instance should definitally be a Branch Group.  This way one can easily add it to the scene, either embedded in the scene somewhere (import support), or encapsulated in a Foreground node (input support).

Regarding input support, the way I see it we have two options - picking, and resolving the absolute screen coordinates to the relative foreground coordinates.  I am not sure that the former would work.  The latter option I am sure is possible, but not totally sure as to the implementation.  I worked on a project recently where we managed to map precicely the XY screen coordinates to a textured quad in the scene.  I did this by setting the FOV to 90 degrees, and moving the camera to half the quad's hight (IIRC).  There would be a mathematical formula I'm sure that one could use to calculate this, based on the FOV.  To be honest, I do not know it (I did experiment with trial and error to work it out, but failed), but I did get it to work for a 90 degree FOV.  Maybe if I read some more OpenGL books I could work this relationship out.

Does everyone here use the HIAL input abstraction layer?  I do, and it allows me to seemlessly switch between the JOGL and LWJGL frameworks.  My vote would be to use this library as the import for the system (one really big advantage is that our UI would be totally abstracted from the actual input, allowing future input libraries to be used with no changes to our code).

A low level design question:  What does our pipeline look like?
Components drawn to a Graphics2D -> Graphics2D converted to Texture -> Quad texture updated?

Obviously for a snappy, and resource friendly UI we are going to want minimal overhead.
It's cool to see I'm not the only one who don't know the formulae to get foreground coordinates from absolute screen coordinates.
I think having a FOV of 90° isn't a problem. Can you post an example code of what you've done, so I don't have to recode that ?
I don't currently use HIAL but I'll switch to, for Gamma and my game.
For the pipeline, if we can have a function that is called each rendering in each component, we could do that : Graphics2D -> Graphics2D converted to Texture -> Quad texture updated.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #8 - Posted 2005-08-02 16:07:27 »

I really do recommend HIAL, it adds absolutally minimal overhead, and the benifits are many.  Glad to see you are looking at using it Smiley

Unfortunately we probably can't restrict the users choice of FOV so that's not a go.  In fact, I'm not sure my example will be of any use to a UI, except to prove that such correlation of screen to 3D coordinates is possible.  I'll dig up the code anyway.

Cheers,

Will.

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #9 - Posted 2005-08-02 16:07:50 »

The position and size of the components are defined in %, relative to their parents. So the GUI can be any size.

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 Grin

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.

malloc will be first against the wall when the revolution comes...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #10 - Posted 2005-08-02 16:13:57 »

The position and size of the components are defined in %, relative to their parents. So the GUI can be any size.

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 Grin

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

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #11 - Posted 2005-08-03 00:11:32 »

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.

Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #12 - Posted 2005-08-03 00:16:59 »

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.

:: JOODE :: Xith3d :: OdeJava ::
Offline endolf

JGO Coder


Medals: 7


Current project release date: sometime in 3003


« Reply #13 - Posted 2005-08-03 08:37:03 »

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

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 Smiley

Endolf

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #14 - Posted 2005-08-03 11:40:53 »

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 ?

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 Sad - 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 Smiley.

This works best with some utility layout classes, which are almost trivial to implement. e.g. I have several times (for different employers Wink) 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).

malloc will be first against the wall when the revolution comes...
Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #15 - Posted 2005-08-03 11:43:11 »

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.

:: JOODE :: Xith3d :: OdeJava ::
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #16 - Posted 2005-08-03 13:24:57 »

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 ?

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 Sad - 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 Smiley.

This works best with some utility layout classes, which are almost trivial to implement. e.g. I have several times (for different employers Wink) 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).
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 ?

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #17 - Posted 2005-08-03 13:28:35 »

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

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #18 - Posted 2005-08-03 13:30:20 »

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.
Yeah, that'd be very useful.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #19 - Posted 2005-08-03 14:26:10 »

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 ?

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.

malloc will be first against the wall when the revolution comes...
Offline Niwak

Senior Member


Medals: 1
Projects: 1



« Reply #20 - Posted 2005-08-03 15:49:37 »

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.
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #21 - Posted 2005-08-10 13:39:54 »

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

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #22 - Posted 2005-08-10 15:28:48 »

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.

Offline kevglass

JGO Kernel


Medals: 120
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #23 - Posted 2005-08-10 15:33:36 »

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

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #24 - Posted 2005-08-10 15:55:21 »

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

malloc will be first against the wall when the revolution comes...
Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #25 - Posted 2005-08-10 18:55:13 »

  - 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  Cool)

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)

:: JOODE :: Xith3d :: OdeJava ::
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #26 - Posted 2005-08-11 13:55:29 »

  - 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  Cool)

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.

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

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 ?

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #27 - Posted 2005-08-11 13:56:33 »

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

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #28 - Posted 2005-08-11 14:02:33 »

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

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

pw (37 views)
2014-07-24 01:59:36

Riven (38 views)
2014-07-23 21:16:32

Riven (26 views)
2014-07-23 21:07:15

Riven (28 views)
2014-07-23 20:56:16

ctomni231 (59 views)
2014-07-18 06:55:21

Zero Volt (50 views)
2014-07-17 23:47:54

danieldean (42 views)
2014-07-17 23:41:23

MustardPeter (44 views)
2014-07-16 23:30:00

Cero (60 views)
2014-07-16 00:42:17

Riven (57 views)
2014-07-14 18:02:53
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!