Small Gui System (SGS for short) for Xith

Engines, Libraries and Tools Xith3D Forums
#21

Whats your progress <MagicSpark.org [ BlueSky ]>?
Communication has been almost zero between us during the project, and as a matter of fact all that there is is on this forum… :-\
I have progressed to a good start on my behalf and now i wonder weather to recheck and try to bring up some cooperation or should i just burn more gas and head on out finishing one GUI system by myself.
I dont really mind working alone, infact i prefer now that since i feel that i have formed a good start by myself and feel confident in developing it alone and the way that i want it to be.

Do you have any comments on this before i start my own thread about it?

:slight_smile: Cheers,

#22

I have not progressed, cause I didn’t even started to code Guild.
The reason is I didn’t realized physic simulation was a sooo complex topic and I just underestimated the needed time to implement it… An additional factor is my requested feateures list has been dramatically growing recently…

That’s right, but communication between us can be made on this forum.

If you prefer to work alone, I won’t put my big bears paws in your work 8)
However if you don’t mind having some help (assuming I wouldn’t have the same level of authority over the project than you), just put it directly in the xith-tk CVS, because it’s here intended to put the work I wanted to do.

Actually I have to test and tune 2D physic simulations and I have already done a level editor (using Xith) but I don’t know wether it’s a good idea to use Guild instead. If it was the case I would contribute a lot because I need it for level editing and also for testing/tuning.

Why would you start your own thread about it ?
Don’t forget to share your work ! (if you make it alone)

#23

Hey Boys!

Sorry that I havent posted on this earlier! I really should read the forum more carefully (bad johannes, bad, bad Johannes) :slight_smile:

I am working on something quite similar, though for a broader audience. I remember the days when I developed a flight simulator entirely in Xith for a computer graphics grad. course at my Univ. Back then I used Xiths pretty neat Swing-to-Texture mapper to display a simple Swing GUI as an in-game element.

Long story short, maybe you know FengGUI already? If not you can check it out here. And I would like “to sense” the possibilty for us to join forces in order to build a really cool GUI system. :slight_smile:

Johannes

#24

I think this is really cool, and if I had time I really would join this project.
Unfortunately I’m actually learning about physic simulation and this takes me loads of time.
Anyway this is a really good initiative and I’ll probably use it (and why not contribute) when I’ll need a GUI system.
But how will it be integrated in Xith ?

#25

[quote="<MagicSpark.org [ BlueSky ]>,post:24,topic:25935"]
But how will it be integrated in Xith ?
[/quote]
Yepp, that’s exactly the problem. I and this is where I am hoping you can help me out.

FengGUI supports currently two rendering peers, namely LWJGL and JOGL (btw, FengGUI stole the concept of rendering peers from Xith, though it is a bit modified). The rendering peers are mainly implementations of this interface (a subset of required gl commands) and this interface (an interface to handle a single texture).

If we could somehow implement this interfaces to run on Xith, the intergration would be piece of cake. However, I can imagine, that this approach pays the simplicity with a rather odd design from an architectual point of view, which I cannot decide since I have no inside in Xith. So what do you think? :slight_smile:

Johannes

#26

It seems possible (I just looked at the interfaces and I don’t think there are Options Xith3d doesn’t support).

Maybe we could also make it acces directly Xith3d’s jogl or lwjgl renderer? Then it really could be a no-brainer :wink:
To do this, we could simply let it render in another Render-Pass on top of the scene

Arne

#27

Cool! I love no-brainers!

I am afraid I cannot really answer the question because I know zilch about the internal organs of Xith. But it sure sounds good!

Don’t you feel like joining FengGUI as a developer? ;D

Johannes

PS: Unfortunately, I leave on vacation today (for two weeks) and I am not sure if I have an Internet access there…

#28

Some update from my progress:

I have a very well working system for the basis of any kind of gui. I have made two abstract classes (component and container) that are capable of handling the positioning, sizing, and such. Infact they handle everything exept two things that they require a subclass to implement; first they need to provide a method returning a node that will be used to render the component, second they need to provide a geometryUpdater method that can handle updating the geometries in the node it provided. Both can be left empty, of course you wouldnt want to leave the first one empty, if you leave the latter empty then the component will not be able to for example resize should it be needed.

In addition to those two forming the base of the system i have extended one container (UIPanel) and one component (FPSCounter). In the FPSCounter i used the DText2D class from the toolkit but i had to do a lot of customization so i might have to make a new one (maybe UIText) just for the gui.

Last night i squeezed in one more thing; support for layout managers. I made the interface and implemented a swinglike GridLayout. Im still just beginning to think about the layoutmanagers so ill elaborate on that when i know im doing it the right way (maybe taking a peek at awt sources :D).

Oh, i almost forgot; the gui is interactable by implementing a listener on your topmost gui container and then delivering events from your input layer. The methods return boolen so you can know weather the gui “consumed” the event or was it targeted at the scenegraph. The components are currently draggable and clickable, and some attributes can be defined to them that changes the behaviour they react to these events: they can be draggable or not draggable, they can cross the screen borders or not cross, they can dock to the screen borders or not dock, they can be auto resizing or not.

Lastly, using the multipass rendering the screen scale is set relative to that of the screen pixel size (for a 800x600 window the screen scale is set to 400) in the pass when rendering the gui. This enables to position and size the components in pixel scale. This also enables the gui components to remain of constant pixel size even if the window is resized. I made the first prototype without this feature, it worked fine but i had to do a lot of extra computing to get the locations right and the components were also resized when the window resized. Maybe i will provide both options.

Ill clean up the code, javadoc it and post some screens next. :wink:

#29

Good work !

#30

Here is a screenshot, although its not intended to be pretty yet, you can see that it actually does work :stuck_out_tongue:

There are some more stuff visible since from my last post; the button and a “panel” showing the wireframe of a shape from the scene selected by picking.

Edit: Dont pay attention to the FPS of 77. That has nothing to do with the gui but with the scene… It’s ~750 without the scene and only the gui.

#31

looks good :smiley:

#32

indeed :slight_smile:

#33

jaakko777, what’s the development status of your GUI lib ?

Since we talked of that, I became (almost) the 3rd release man of Xith, I changed of game project (which don’t need complex physic sims) and I now have the worry about a GUI (besides network, game logic, …).

First I thought I’d do my own small GUI solution then I remembered you worked on that. So I looked back at this thread and saw what you done is pretty much all I wanted… I don’t mind to contribute if I find time and need for that.

#34

Well, I was 2 months traveling and recently came back. Now i havent restarted yet with it but i can share what i have - i only have to separate it from my other project first.
I’ll come back on this with a post when I have done that.

#35

OK. I can integrate it into the toolkit, we will see if it’s too big we can make a seperate project.

#36

Im sorry i still have been pretty busy… :frowning:
Its better that i dont promise anything at the current but well see…

#37

OK, no problem.