Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (581)
games submitted by our members
Games in WIP (500)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 2 [3]
  ignore  |  Print  
  ui xith3d  (Read 10542 times)
0 Members and 1 Guest are viewing this topic.
Offline arne

Senior Member




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


« Reply #60 - Posted 2004-12-19 16:57:53 »

Quote

Quote:
I think it would be better not to use picking and instead just convert the coordinates.

whats the best way of doing this?


Because the virtual Plate on which the ui is shown is paralel to the real screen, couldn't we just assume a linear relationship between the positions? e.g. by getting the virtual positions by xplate = m*xMouse+n, where m and n are constants, dependent from the distance to the plate, etc.

:: JOODE :: Xith3d :: OdeJava ::
Offline aNt

Senior Member




AFK


« Reply #61 - Posted 2004-12-20 10:00:31 »

what if the ui isnt a billboard facing flat to the screen?
being we are in a 3d world why are we thinking in 2d when it comes to the ui? most ui's are made up of 2d
layers and more modern ones are 3d objects.

i do think we should be thinking along the lines of a set
of event containers (button, popup, text...) that have
behaviors for 3d elements.

button -
          rollover         -
                       callbackevent - with model
          mouse down -
                       callbackevent - with model
          .....
          getModel - return model
          setModel -

etc... this maybe more then most want at this time in
there application/game. but it does give us more scope
to do any type of ui you like. things do get tricky with
scroll panes etc where the model would be contained
within another models area- i have seen a xith demo of
this mind Wink.
Offline arne

Senior Member




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


« Reply #62 - Posted 2004-12-20 12:47:53 »

How right you are  Cool

In Java3D it was possible to do picking along only a liitle segment of a ray. Couldn't we just implement this and use it instead of a picking ray through the whole world? I think this would really speed thinks up.

Arne

Edit: Or to use the picking on only the ui part of the scenegraph.

:: JOODE :: Xith3d :: OdeJava ::
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline arne

Senior Member




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


« Reply #63 - Posted 2004-12-20 13:07:43 »

Hey ... I got an idea of using complex swing or awt containers in the 3D-world!!!  Cool :

We could use the Component's getImage method and use this Image as the Texture for the ui components. This could we do every time repaint or s.th. else is called (i don't know the function that's called by subcomponents, when changes should be processed).

*this is no solution to overcome the problem with converting the coordinates!!

Arne

:: JOODE :: Xith3d :: OdeJava ::
Offline itistoday

Junior Member




There's too much blood in my caffeine system.


« Reply #64 - Posted 2004-12-20 14:40:52 »

Right, and I don't think Billboards work with the foreground node, not at least not in my tests with Text2D, I had to convert it to a regular shape3d using quad geometry.

Offline aNt

Senior Member




AFK


« Reply #65 - Posted 2004-12-20 15:42:12 »

arne- yes thats how it works at the moment. and i think
using awt/swing components is a sound thing to do. it
does seem to come down to event handling in the end.
and working out what component in the world u are
over/click/draged. then dressing components up is a
case of your design needs. you may find u end up not
seeing a need for awt/swing Wink

texture the object and set it to setDirty(true) and you
can dynamicly change the texture.. this is all cool and
known... just we need a realy nice picking lookup ray.
we need to start at the start to move forwards.
Offline arne

Senior Member




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


« Reply #66 - Posted 2004-12-20 16:01:25 »

As far as I know there's only one way until now to perform a pick in xith: a pick that goes through the whole scene.  :-/ But, if (as said earlier) we could perform a pick only in a part of the scene (eg only in the foreground node), it would probably save very much time.

Or even better: couldn't we just convert the edges and stuff from the ui to screen coordinates, because then we never have to convert the mouse pos every time the mouse moves!! Wink

Arne

:: JOODE :: Xith3d :: OdeJava ::
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #67 - Posted 2004-12-20 23:39:43 »

Quote
Right, and I don't think Billboards work with the foreground node, not at least not in my tests with Text2D, I had to convert it to a regular shape3d using quad geometry.


That would be because Billboards and Foregrounds serve mutually exclusive purposes and are not designed to work together.

Will.


Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #68 - Posted 2004-12-20 23:42:07 »

Quote


Because the virtual Plate on which the ui is shown is paralel to the real screen, couldn't we just assume a linear relationship between the positions? e.g. by getting the virtual positions by xplate = m*xMouse+n, where m and n are constants, dependent from the distance to the plate, etc.


I think we can assume a linear relationship.  I think that using picking for a 2D UI is overkill.

Will.

Offline aNt

Senior Member




AFK


« Reply #69 - Posted 2005-01-10 10:19:37 »

Will; indeed its overkill- but thats what the kids want Wink
plus you can aways make a flat branchgroup UI.

we also need ray intersection (an example would help)
so i can look at 'text' area highlighting. i'm back on it.

hows the rest of u dudes doing?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline arne

Senior Member




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


« Reply #70 - Posted 2005-01-10 16:17:27 »

Heya!!

ray intersection is what we need, but also with the ability to do it only in a part of the scenegraph (e.g. the foreground node) then it wouldn't be overkill  Wink
too bad i'm not very interested in this kind of ui yet - so i probably wouldn't do very much else then checking from time to time this forum and speaking my ideas out aloud.  Cool
Hopefully anybody works something out, until I'm back at this ui stuff.

arne

:: JOODE :: Xith3d :: OdeJava ::
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #71 - Posted 2005-01-10 21:22:01 »

What I'd love to see is simple label and input text boxes and basic buttons with nice alpha transparency and using the Foreground node.

Everything else can be build on later.  We just something that people can use.

Will.

Offline SpuTTer

Senior Member


Medals: 1


Lazy Middle Class Intellectual


« Reply #72 - Posted 2005-01-10 21:42:21 »

I'd like to see ... ANYTHING! Smiley

I've had a game almost ready for at least 6 months now and I haven't wanted to continue development or show anyone because the UIWindow GUI is all messed up on non windows platforms, etc...

It doesn't appear that anyone is actively working on a GUI system for Xith.

I know I've brought it up in the past and I've been told that Xith isnt dead, but it doesnt really seem that anyone is using it for any games. I think I'll start a subthread labeled that Smiley

Sacramento Volleyball
"Whitty phrase goes here."
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #73 - Posted 2005-01-11 01:44:03 »

Would you like to do it?  Perhaps the two of us should join forces and come up with something.  I was really hoping not to have to but maybe nothing will happen unless we do.

What are your needs?

Currently, all I really need is a text display and input boxes.  My game does not have a mouse cursor, so I have no need for a clickable UI (this reduceses the complexity of the UI substantially, but I don't know what your needs are).

I will be using AWT/Swing for my pre-game dialog's for now -- I can't see any reason not to until Java makes it onto a console.

I have actually resigned from my day job, effective 11 February 2005.  From that date, I am intending to dedicate about half my working week to my game (and related technologies such as Xith3D), and the other half trying to get some $$$.  Until then however I am extreemly busy, so I can really only guarantee my efforts after that date (I'll still try and do a bit before then, but my plate is quite full).

Cheers,

Will.

Offline Abanti

Innocent Bystander





« Reply #74 - Posted 2005-04-02 22:11:49 »

Is anyone doing anything with this?  Has hasait given up?

I am entirely new to this whole discussion, but after reading the threads I've found on xith3d ui issues it seems that there are three problems preventing the development of a decent xith3d ui:

1. Everyone is waiting for someone else to do it.
2. Those who do try it burn out - building a ui system is a big job, and probably not one that should be attempted by one person working alone.
3. The whole issue of UI elements in the scene - this is like trying to build a supersonic aircraft before figuring out how to build an aircraft at all.

UI seems to be the issue facing all the rendering engines that are freely available, and in every case that I've looked at it seems to be because of the reasons listed above.

I would be interested in participating in an attempt to construct a UI framework for Xith3D, but I certainly am not inclined to do it alone.  Are there any such efforts that would be reasonable for me to join?  If not, why don't those of us who are interested in this issue team up and give it a go?  I can't do it all myself - I lack the expertise and the time - but if I could get some help I'd be interested in trying.
Offline Alistair_Dickie

Senior Newbie




Java games rock!


« Reply #75 - Posted 2005-04-03 09:51:05 »

I have not "fixed" the ui stuff currently built into Xith but think I have used if pretty extensively in my game (currently beta). I use quite a bit of the functionality that is descirbed as lacking in thread. Have a look at http://zplax.alistairdickie.com

- Semi Transparant buttons that react to MouseOver (see the six buttons at the top). I had to slightly modify UI window manager for this. Essentially these buttons are each UIWindows with a single JButton in them.

- Text output to a semi transparent ui window (press c to see the frame rate thing). This is a JText area on a UIWindow.

- JLabel output to a semi transpared UI Window (The score and time windows).

- 2D graphics in a semi tranparant UI Window (the water level window).

- A custom component made up of a JTextField two JButtons and a JLabel (see the JSpinner like thing in the game settings window).

- Text written onto the graphics object of a BufferedImage (actually a DirectBufferedImage) that is placed as a texture on some geometry (see the banner by pressing b)

-I pop another frame over the top of the main one for my About dialog.

A few tips that I ended up applying.

- Set the Layout of any component you are going to add stuff to to null. Then use setBounds on the objects you are going to add for positioning. That way you will always know where you stuff is going to do without having to rely on one of the funky swing layouts.
-Use setColor(0,0,0,0) to make something transparent or setColor(0,0,0,128) to make it kind of tansparent. Do this all over the place and all will be well.

Don't get me wrong. I think the UI stuff that currently exists can go a long way. I think when David Yazel made it he was very focused on being able to drag UIWindows around - that is whey they move if you click in the top left 15 pixels or so (I also changed UIWindow to customize or disable this)

Regards,

Alistair

Offline Niwak

Senior Member


Medals: 1
Projects: 1



« Reply #76 - Posted 2005-04-03 13:02:40 »

I'm working on a UI system. That's the reason why I recently implemented render to texture.

The fact is that I need a full 3d UI system. I used to use the Swing integration from David Yazel (which worked perfectly for me) but I had to move to a system that will allow me to have a unique system for UI widgets as well as game objects. Therefore I made a 3D UI system.

It does work but is very preliminary.

For the moment it has the following features ;
- Full 3D ui based on 3d widget - allows you to have 2d widgets as well as game object widgets,
- Container & Layouts (swing like)
- The following widgets are already implemented ;
    - Frame (draggable and resizable)
    - ImagePanel
    - TextLabel
    - Button
- A skin system

It only works with JOGL for the moment. I'm thinking of adapting the base framework to be able to use LWJGL as well.

Anyway, it's nothing near finished so I don't expect to release it anytime soon.

I will post a preview when I will have something ready.

By the way, I think that any UI system that we will develop will need an abstract frame system (a bit like OpenProducer of OpenSceneGraph) to abstract the event system and make it single threaded. Has anyone created and released this ?

    Vincent

Here is a screen shot showing a Frame (composed from other widgets) with the game board beneath. One of the board square is a bit lighter (next to the duck) ; this is because the mouse is over it. It shows as well 2 text labels (bottom of the screen and title of frame).

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #77 - Posted 2005-04-04 13:40:46 »

I don't think there is anything inherently wrong with the David's user interface package, in fact it is a pretty amazing feature (Swing rendered to OpenGL).  However, it has had some "bad press" recently.  The main problem is that nobody is supporting it.

What we need is someone who has used it extensively, and has looked at the source code and understands what's going on to take on the maintenance of it.  A number of Issues have recently been closed as WONTFIX which can be re-opened.  Please raise your hand if you are willing!

Now this UI is pretty heavy, it's more suited to rich UI's.  For something simple like a framerate indicator a more lightweight solution is needed, but this isn't to say the two can't co-exist.

Niwak,

Your screenshot is impressive.  Hopefully your UI effort may produce a usable UI API for all to use Grin  A great many people will thank you if that happens, myself being one.

Cheers,

Will.

Offline Amos Wenger

Senior Member




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


« Reply #78 - Posted 2005-04-04 16:19:47 »

One question I'm thinking about is : Is it REALLY possible to do a true, polished, UI for a game with AWT/Swing ?
Is the skin system extended a lot so that we can do sort of things like Niwak's screenshot ?

"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 Alistair_Dickie

Senior Newbie




Java games rock!


« Reply #79 - Posted 2005-04-04 20:45:02 »

I have just done some memory profiling for my game. I was amazed at the rate that objects are created and destroyed in Xith3D. I seem to be churning through thousands of primitave arrays (of every type) every frame. Not to mention a bunch of other objects to do with rendering. The GC has a lot of work to do.

With the UI stuff turned on things are worse. I am not sure if that is just because there is more stuff to render, or if swing is making it even worse. In any case there is more investigation required.

I think I can answer a few questions on David's UI Interface stuff. I have spent hours looking at that code and am pretty sure I understand at least the basics.

Regards,

Alistair

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #80 - Posted 2005-04-05 00:56:51 »

On a Swing interface, I guess it's a trade off between development time, complexity of the UI and frame-rate.  If you want to create a very complex UI in a short amout of time, Swing lets you do that, but it has a cost.    Have you played Alistair_Dickie's game?  It uses the Swing UI extensivly.


Alistair_Dickie,

Do you want to take charge of the UI code?  It's all yours if you want it.  Please contact me by email if you do, and I will get you set up.  What we will do is move the package into the xith-tk as an optional package, not tied to the core (thus, no bloat).


Regarding excessive garbage collection, if you identify the wastage and submit a patch, I will commit it in.

Cheers,

Will.

PS.  Here are two UI bugs which you can look at if you like.   W

Offline Alistair_Dickie

Senior Newbie




Java games rock!


« Reply #81 - Posted 2005-04-06 11:52:08 »

Will,

These are both a little harder than they should be.

I am going to do some more work on my program and will do a little on the interface package but will not get to it for a few weeks.

I am currently looking at getting a really nice Text3D shape done. You should see that in the next few days.

Regards,

Alistair
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #82 - Posted 2005-04-06 13:35:34 »

That's great Smiley

If you are interested, you can add Text3D as a package of the Xith3D toolkit, and it will be distributed with every copy of Xith3D downloaded.

Cheers,

Will.

Offline jaakko777

Senior Newbie





« Reply #83 - Posted 2005-12-30 01:22:48 »

Hi, im new here and want to first tell you all that Xith3D is great and thanks for your fantastic work!

On this thread earlier...

As far as I know there's only one way until now to perform a pick in xith: a pick that goes through the whole scene.  :-/ But, if (as said earlier) we could perform a pick only in a part of the scene (eg only in the foreground node), it would probably save very much time.

What about making a bit unconventional renderloop like this:


BranchGroup mainScenGraph;
BranchGroup foregroundScenGraph;

public void run() {
      while(true) {

            // render once with the main scene picking disabled
            mainScenGraph.setPickable(false);
            foregroundScenGraph.setPickable(true);
            view.renderOnce();
           
            // do picking to see if the GUI is picked
            ...
           
            // render once with the main scene picking enabled
            mainScenGraph.setPickable(true);
            foregroundScenGraph.setPickable(false);
            view.renderOnce();
           
            // do your normal game logic checking
            ...
      }
}


This should speed things up since if the root of the scene is disabled from picking, the picking will pass over the scene without picking it. Now the picking speed will be determined only by the GUIs complexity and that cant be very huge...

Then after picking for the GUI the states are reversed and normal game logic take place, maybe including picking on the scene triggered by a mouse click etc...
Offline arne

Senior Member




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


« Reply #84 - Posted 2005-12-30 11:50:15 »

I've already written some code, where you can perform a pick on branchgroups directly without this setPickable stuff. (make a search in the forums) It would do the job, too. But I actually favor the way of rendering twice( first the scene and then the gui in PARALLEL_PERSPECTIVE) with jogl this should work and is probably much faster.

:: JOODE :: Xith3d :: OdeJava ::
Offline Matthias

Senior Member


Medals: 3
Projects: 1


TWL - Themable Widget Library


« Reply #85 - Posted 2006-01-11 01:29:50 »

I have just done some memory profiling for my game. I was amazed at the rate that objects are created and destroyed in Xith3D. I seem to be churning through thousands of primitave arrays (of every type) every frame. Not to mention a bunch of other objects to do with rendering. The GC has a lot of work to do.

That is not completely true http://www-128.ibm.com/developerworks/java/library/j-jtp11253/ explains how the generational garbage collector in the 1.4.x, 1.5.x  and even 1.6.x work. There are two main parameters which will greatly improve the application performance and reduce the pause times:
-Xnm8m -XX:SurvivorRatio=6
this will create a young generation of 8 MB minimum size and 6 MB for eden and 2 times 1 MB for the survivor space.

With these parameters I was able to create a Java abased image viewer that did only pause for about 3 ms every few images (1280x768xRGB => 4 MB per image). Without theses parameters the allocation of the BufferedImage alone took 130ms according to Netbeans profiler.

And you have to be very careful with object pools because once you modify an old object (which was promoted to tenured generation) may keep the new object alive until the next major collection - this can cause very long pause times.

The same is true for objects that are larger then the survivor space. But this should not be the case in Xith3D - only textures are this large and are normaly long lived. Otherwise increate the young generation or reduce the SurvivorRatio  (like 2 -> e.g. 4 MB eden, 2x 2MB survivor).

I hope this can help to demystify the Java GC a little bit Smiley
Pages: 1 2 [3]
  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.

xsi3rr4x (57 views)
2014-04-15 18:08:23

BurntPizza (55 views)
2014-04-15 03:46:01

UprightPath (68 views)
2014-04-14 17:39:50

UprightPath (51 views)
2014-04-14 17:35:47

Porlus (68 views)
2014-04-14 15:48:38

tom_mai78101 (92 views)
2014-04-10 04:04:31

BurntPizza (153 views)
2014-04-08 23:06:04

tom_mai78101 (249 views)
2014-04-05 13:34:39

trollwarrior1 (205 views)
2014-04-04 12:06:45

CJLetsGame (212 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
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!