Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (109)
games submitted by our members
Games in WIP (536)
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  
  Getting FengGUI run with Xith  (Read 3943 times)
0 Members and 1 Guest are viewing this topic.
Offline Schabby

Junior Member




The Receding Brow Worm will eat your code!


« Posted 2006-10-03 11:07:07 »

Hi guys,

I am currently trying to make FengGUI render on top of Xith which is what we talked about a while ago. I grabbed the HelloXith3D example and mangled it such that it calls FengGUIs render routine after Xith finishes traversing and rendering its scene graph... Well that's the plan at least. I have elementary questions that hinder me at the moment to fulfil that plan Smiley

From what I can tell without having digged in the Xith code too deeply is that it uses JOGL per default (right?). In order to instantiate FengGUI, I need to get the javax.media.opengl.GL instance from somehwere. Where can I get it? I checked RenderPeerImpl, CanvasPeer and Canvas3D before I came to the conclusion that it is probably smarter to ask you guys.

Thx,

Johannes

PS: btw, me managed to get FengGUI run together with jME. Check out here: http://www.jmonkeyengine.com/wiki/doku.php?id=integrating_fenggui_with_jme

Offline bohdan

Junior Member




Java-positive...


« Reply #1 - Posted 2006-10-03 14:18:36 »

Well, I'm not 100% sure, that this is the answer on your question but you can get GL instance in CanvasPeerImpl... getGL() method, for example, or you can probably dig in to CanvasPeerImpl.display(GLAutoDrawable drawable)....
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #2 - Posted 2006-10-03 14:43:35 »

Try something like this:
1  
GL gl = ((CanvasPeerImpl)(myCanvas3D.get3DPeer())).getGL()


Marvin

PS: What's this HelloXith3D class you're talking about?
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 2006-10-03 18:21:28 »

@Schabby : 2 questions before answering to yours :
  • Does FengGUI support both LWJGL and JOGL JSR-231 ? (IIRC you had an abstraction layer.. please detail how it works)
  • Could we provide you a generic GL with basic OpenGL functions which semlessly calls *real* ones (JOGLJSR-231 or LWJGL, depending on the OpenGL layer choosed by the dev)

"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 Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #4 - Posted 2006-10-03 18:26:49 »

Could we provide you a generic GL with basic OpenGL functions which semlessly calls *real* ones (JOGLJSR-231 or LWJGL, depending on the OpenGL layer choosed by the dev)

I stormed my brain a lot about that. It would be quite handy and we could simplify the Renderer abstraction very much. But... On the other hand, this would mean one more method call for each single OpenGL call. This will certainly be very slow Cry. So I really think this can't be done efficiently.

Marvin
Offline cylab

JGO Ninja


Medals: 38



« Reply #5 - Posted 2006-10-03 19:30:22 »

Would it not be cleaner to create an own FengGui node type for the scenegraph and implement RenderAtomPeers for it? Ultimately it would be nice to use a FenGUI as arbitrary Shape, so you can create computer terminals with a GUI in a game.

Could we provide you a generic GL with basic OpenGL functions which semlessly calls *real* ones (JOGLJSR-231 or LWJGL, depending on the OpenGL layer choosed by the dev)
I stormed my brain a lot about that. It would be quite handy and we could simplify the Renderer abstraction very much. But... On the other hand, this would mean one more method call for each single OpenGL call. This will certainly be very slow Cry. So I really think this can't be done efficiently.

I don't think the overhead would be much, since most performance critical work should be done by the GFX-Card anyway (DLs, VBOs, Shader etc.).

The JSR itself defines an abstract wrapper around the GL functionality, so you could even create a LWJGL binding with an JSR interface (croft did something similar  afaik with the jGL software renderer)

Mathias - I Know What [you] Did Last Summer!
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #6 - Posted 2006-10-03 19:42:20 »

Would it not be cleaner to create an own FengGui node type for the scenegraph and implement RenderAtomPeers for it? Ultimately it would be nice to use a FenGUI as arbitrary Shape, so you can create computer terminals with a GUI in a game.

This won't be totally possible. FengGUI and HUD both depend on a plane, which is normal to the view direction. Well, as far as clipping of containers and picking are concerned.

I don't think the overhead would be much, since most performance critical work should be done by the GFX-Card anyway (DLs, VBOs, Shader etc.).

The JSR itself defines an abstract wrapper around the GL functionality, so you could even create a LWJGL binding with an JSR interface (croft did something similar  afaik with the jGL software renderer)

Well, accessing a field directly is faster then accessing it through a getter / setter. Doing it many times in a time critical place (like the rendering code) will certainly make the whole thing a lot slower. So this might be resonable for a GUI, where only a few Nodes are drawn. But for the whole scene, this is not resonable.

Marvin

EDIT: And the performance critical work is not only done by the GFX card, but the prerendering work is also performance critical. It prepares the Shapes and things to be in a format the GFX card can understand. And this is done frame by frame (or could possibly be).
Offline Schabby

Junior Member




The Receding Brow Worm will eat your code!


« Reply #7 - Posted 2006-10-03 19:54:24 »

First of all thanks for the answers!

Quote
Does FengGUI support both LWJGL and JOGL JSR-231 ? (IIRC you had an abstraction layer.. please detail how it works)

Yes. FengGUI runs on JOGL as well as on LWJGL. Our "abstraction layer" is quite straight forward: We got an interface IOpenGL that declares the few dozen gl calls we need to render FengGUI. For example beginQuads, end, bindTexture, etc. For each OpenGL binding we got a class that implements this interface, namely OpenGLLWJGL and OpenGLJOGL. It is up to the developer which binding he wants to use because their behaviour is identical of course.

More precisely, you can setup FengGUI by

1  
Display fengguiDisplay= new Display(new JOGLBinding());


or

1  
Display fengguiDisplay= new Display(new LWJGLBinding());


Both bindings instantiate the associated IOpenGL in question which is then used for rendering.

Quote
Could we provide you a generic GL with basic OpenGL functions which semlessly calls *real* ones (JOGLJSR-231 or LWJGL, depending on the OpenGL layer choosed by the dev)

Hmm, I believe that is not necessary although I appreciate the offer. Since FengGUI will render the widgets completely separated from Xith we do not need to bridge the OpenGL binding between Xith and FengGUI. It is probably enough for both APIs to stick to the same binding (either JOGL or LWJGL). In other words, when you setup Xith with LWJGL, you should use FengGUI with LWJGL as well and vice versa with JOGL.

GL gl = ((CanvasPeerImpl)(myCanvas3D.get3DPeer())).getGL()

I tried this, but the returned gl instance points at nullCry

Quote
The JSR itself defines an abstract wrapper around the GL functionality, so you could even create a LWJGL binding with an JSR interface (croft did something similar  afaik with the jGL software renderer)

Hmm, the thing is that FengGUI combines several gl commands in one method in a few cases. However, having FengGUI in a node in the scene graph would be pretty cool. But maybe we should first try to render FengGUI simply after Xith. (like we successfully do with jME)

Johannes

edit: whoops, Marvin was quicker than me Cheesy

Quote
FengGUI and HUD both depend on a plane, which is normal to the view direction. Well, as far as clipping of containers and picking are concerned.

Yeah, that may turn out to be a problem, but it is possible to overcome I believe. But again, we may want to go for the easy thing first.

Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #8 - Posted 2006-10-03 20:02:38 »

Try something like this:
1  
GL gl = ((CanvasPeerImpl)(myCanvas3D.get3DPeer())).getGL()


I tried this, but the returned gl instance points at null. Sad

Maybe you'll have to call this after the first frame is rendered.

And again the question: What's this HelloXith3D class you're talking about?

Marvin
Offline Schabby

Junior Member




The Receding Brow Worm will eat your code!


« Reply #9 - Posted 2006-10-03 20:07:26 »

Quote
Maybe you'll have to call this after the first frame is rendered.

ah, ok, I will check it out! Thanks

Quote
And again the question: What's this HelloXith3D class you're talking about?

Dont you guys know your own examples?  Wink Just kidding...  It's in org.xith3d.test (I guess it came with the toolkit package) and is written by Jens Lehmann (isnt he a goal keeper of some sort?) Smiley
I am happy yo post the code here... but it is pretty long

Johannes

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #10 - Posted 2006-10-03 20:13:08 »

Dont you guys know your own examples?  Wink Just kidding...  It's in org.xith3d.test (I guess it came with the toolkit package) and is written by Jens Lehmann (isnt he a goal keeper of some sort?) Smiley
I am happy yo post the code here... but it is pretty long

Well, no it isn't. Maybe you have a somewhat old CVS snapshot (or an old release). So when you're trying to port your GUI to Xith3D you should certainly use a recent version.
Offline Schabby

Junior Member




The Receding Brow Worm will eat your code!


« Reply #11 - Posted 2006-10-03 20:22:57 »

That's peculiar.. I downloaded xith3d-0.8.0.tar.gz. Is there a more recent release? After extracting the archive I found the HelloXith3D class in \xith3d\toolkit\src\org\xith3d\test

Johannes

Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #12 - Posted 2006-10-03 20:25:30 »

That's peculiar.. I downloaded xith3d-0.8.0.tar.gz. Is there a more recent release? After extracting the archive I found the HelloXith3D class in \xith3d\toolkit\src\org\xith3d\test

No. There's no more recent release. But there have been quite huge changes to the CVS tree. Please use a current CVS checkout.
Offline Schabby

Junior Member




The Receding Brow Worm will eat your code!


« Reply #13 - Posted 2006-10-03 20:28:41 »

oh, ok. I will do that

Offline cylab

JGO Ninja


Medals: 38



« Reply #14 - Posted 2006-10-03 23:44:37 »

Would it not be cleaner to create an own FengGui node type for the scenegraph and implement RenderAtomPeers for it? Ultimately it would be nice to use a FenGUI as arbitrary Shape, so you can create computer terminals with a GUI in a game.
This won't be totally possible. FengGUI and HUD both depend on a plane, which is normal to the view direction. Well, as far as clipping of containers and picking are concerned.
Hmm... it's a pity - it just sounds so cute Wink

I don't think the overhead would be much, since most performance critical work should be done by the GFX-Card anyway (DLs, VBOs, Shader etc.).
Well, accessing a field directly is faster then accessing it through a getter / setter. Doing it many times in a time critical place (like the rendering code) will certainly make the whole thing a lot slower. So this might be resonable for a GUI, where only a few Nodes are drawn. But for the whole scene, this is not resonable.
Where do you get that from? Simple getters and setters are inlined by the compiler. Even final, static and private methods can be inlined, see Optimizing Java for Speed for more info.

EDIT: And the performance critical work is not only done by the GFX card, but the prerendering work is also performance critical. It prepares the Shapes and things to be in a format the GFX card can understand. And this is done frame by frame (or could possibly be).
Don't know how much of the prerendering needs direct OpenGL calls, but as a rule of thumb OpenGL calls (especially state changes) should be reduced as much as possible (using approproate data structures, display lists etc), and since the wrapper would only affect direct opengl calls, there will be only a few places with the delegation overhead (if at all due to inlining). If you set the time needed for e.g. uploading vertices to vram in relation to the overhead of a java method call, this seems like a negligible performance hit...

Anyway, it was not my intention to promote the creation of such a wrapper.

Mathias - I Know What [you] Did Last Summer!
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #15 - Posted 2006-10-04 00:02:34 »

Well, accessing a field directly is faster then accessing it through a getter / setter. Doing it many times in a time critical place (like the rendering code) will certainly make the whole thing a lot slower. So this might be resonable for a GUI, where only a few Nodes are drawn. But for the whole scene, this is not resonable.
Where do you get that from? Simple getters and setters are inlined by the compiler. Even final, static and private methods can be inlined, see Optimizing Java for Speed for more info.

Interesting stuff. I didn't know. Thanks for the link Smiley.
Offline cylab

JGO Ninja


Medals: 38



« Reply #16 - Posted 2006-10-04 00:15:01 »

Interesting stuff. I didn't know. Thanks for the link Smiley.
You are welcome Cheesy

Mathias - I Know What [you] Did Last Summer!
Offline c_lilian

Senior Member


Projects: 1


Java games will probably rock someday...


« Reply #17 - Posted 2006-10-04 07:25:42 »

a rather old link, but some things are still valid...

about inlining : IIRC inlining methods across classes is only available to hotspot server. hotspot client just inlines methods in the same class.

but I'm not 100% sure :  may be gettters, setters and one line methods are a special case.

Lilian Smiley

Offline cylab

JGO Ninja


Medals: 38



« Reply #18 - Posted 2006-10-04 10:00:26 »

Thanks for that info. Do you have a link to a more accurate overview of such optimizations? Could be handy.

Mathias - I Know What [you] Did Last Summer!
Offline c_lilian

Senior Member


Projects: 1


Java games will probably rock someday...


« Reply #19 - Posted 2006-10-04 10:09:43 »

this one's not bad : http://java.sun.com/developer/community/chat/JavaLive/2005/jl0315.html

Lilian Smiley

Offline Amos Wenger

Senior Member




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


« Reply #20 - Posted 2006-10-04 16:55:58 »

@cylab : Running HUD or FengGUI on a plane would be possible but we would have to implement software clipping, which would be a lot slower, but it's doable IMHO.

"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 Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #21 - Posted 2006-10-04 19:56:46 »

@cylab : Running HUD or FengGUI on a plane would be possible but we would have to implement software clipping, which would be a lot slower, but it's doable IMHO.

Software clipping and regular picking. The special 2D-picking wouldn't work. But it's still possible, but laborious.
Offline Amos Wenger

Senior Member




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


« Reply #22 - Posted 2006-10-04 20:16:48 »

@cylab : Running HUD or FengGUI on a plane would be possible but we would have to implement software clipping, which would be a lot slower, but it's doable IMHO.

Software clipping and regular picking. The special 2D-picking wouldn't work. But it's still possible, but laborious.
Yeah, sure. But if cylab feels like he's gonna make it, why not ?  Grin

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

JGO Ninja


Medals: 38



« Reply #23 - Posted 2006-10-04 20:48:31 »

I rather should concentrate on the terrain thing first... I must admin that I both over- (regarding lod) and underestimated (regarding complexity) the existing terrain code, so there is enough work for me there Wink

Mathias - I Know What [you] Did Last Summer!
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #24 - Posted 2006-10-07 23:17:05 »

Try something like this:
1  
GL gl = ((CanvasPeerImpl)(myCanvas3D.get3DPeer())).getGL()


I tried this, but the returned gl instance points at null. Sad

Maybe you'll have to call this after the first frame is rendered.

I've changed that. Now the getGL() method returns the correct, non-null value right after the class creation.

Marvin
Offline Schabby

Junior Member




The Receding Brow Worm will eat your code!


« Reply #25 - Posted 2006-10-08 13:24:57 »

cool, thanks a ton!

I have not checked out the latest sources yet, but I will try to find the time to do so asap.

Johannes

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.

CogWheelz (12 views)
2014-08-01 22:53:16

CogWheelz (14 views)
2014-08-01 22:51:43

CopyableCougar4 (15 views)
2014-08-01 19:37:19

CogWheelz (19 views)
2014-07-30 21:08:39

Riven (27 views)
2014-07-29 18:09:19

Riven (16 views)
2014-07-29 18:08:52

Dwinin (14 views)
2014-07-29 10:59:34

E.R. Fleming (35 views)
2014-07-29 03:07:13

E.R. Fleming (13 views)
2014-07-29 03:06:25

pw (44 views)
2014-07-24 01:59:36
Resources for WIP games
by CogWheelz
2014-08-01 18:20:17

Resources for WIP games
by CogWheelz
2014-08-01 18:19:50

List of Learning Resources
by SilverTiger
2014-07-31 18:29:50

List of Learning Resources
by SilverTiger
2014-07-31 18:26:06

List of Learning Resources
by SilverTiger
2014-07-31 13:54:12

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
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!