So what kind of XML structure are you thinking of using for layout and style? glgui has shader xml attributes for most widgest but that doesn’t help at all in separating style from the layout structure. Sometimes the most simple aproach is the better one. My solution would be to map one java widget name to one xml element and xml attributes to java bean properties. The XStream idea that cylab mentioned may be worth to investigate.
I’m new to this. Could sombody please explain why a special games GUI is needed? What’s wrong with Swing, or SWT for that matter?
Generally most of the time you want to embed your UI directly in your fullscreen game and render it with OpenGL along with everything else. Swing and AWT (or even SWT) doesn’t mix too well with the game rendering and input model (which is continuous).
Cas 
But I’ve heard about about the “drawing pipeline” or something like that and that Swing in effect can be made to draw itself using OpenGL.
Except Swing is not optimized for OpenGL drawing. With an OpenGL GUI toolkit, you can take advantage of display lists, VBOs, shaders, etc…
Not only that but you can’t do simple things in a simple and economic way. Even if swing used opengl and acceleration if you wanted to have a small panel to just draw an image you would get a ton of worthless properties and god knows what more you didn’t have any use for.
I see, so basically existing general GUI’s are too much for most gaming needs, in the same way a general scenegraph may be too much for the rendering needs of a game.
Well, when I heard that Swing would be able to use OpenGL to draw itself I found this an excellent idea because it would put less demands on the general processor by offloading work to the graphics processor. In this way in principle Swing could be more efficient than GUI’s based on native widgets! A very good proposition indeed.
But now you say the above is just a good idea because Swing doesn’t have the structure or whatever to really fully utilize OpenGl? Too bad. Couldn’t Sun be persuaded to fix that?
Then the problem with Swing being too complex, too general and too bloated. Couldn’t that be fixed by layering? Wouldn’t it be possible to start out with some existing “core” Swing and then build a gaming “Swing Lite” on that? I’m sure it would be a popular development not only for game applications.
Well, that would be according to the principle of “digging where you stand”.
Swing’s architecture isn’t going to be fixed any time soon, and the thing that is the main problem with it is that the event model it uses is completely opposite from typical game main loops. Also Swing is designed around the common pattern of WIMPs GUIs whereas most games use a very tiny subset of the controls, in an odd fashion (layed out all over a full screen of graphics).
Also… Swing and AWT drag in about 8mb of crap into the VM which I like to avoid doing 
Cas
I really don’t agree with you on this point… Or maybe you aren’t talking about Xith3D, Java3D, and jME scenegraphs… these are designed for games and they do the trick ! All the people using them are happy and say they productivity has been greatly improved…
However for AWT/Swing in games I agree.
Well - all three of those scenegraphs are wayyy too complex, bloated and fiddly for my games, so the point is quite valid. Far more than is needed to do the job easily and efficiently! And Swing is just that.
Cas
Complex ? Maybe, but this is the price to pay for flexibility, isn’t it ?
Bloated ? I don’t think so… You may well write your game in assembler if you find Java too slow…
If the existing scenegraphs don’t fit the bill, well, just do another one, more suited for games ! I’m actually open to thinking about how to do that better.
Coding the game engine directly with OGL isn’t appealing for me… But maybe a new-generation scenegraph can be made… Let’s think about it.
The usefulness of scene graphs depends allot on the game. 2D won’t get many benefits, just bloat. For 3D it depends more in my opinion on how happily the SG can be bypassed and live with your custom code. I built a scene graph for the engine used in Kumari. It’s just the basics and allows me to ignore it completely if needed when I want to tune something specific or lives happily along side any other OpenGL calls. For the GUI I just wrote my own, again extremley light and independent of the SG code or the OpenGL calls being made.
My point is that one size doesn’t fit all - I use a scenegraph for my games, it’s called “the shaven puppy sprite engine”, and it’s teeeeny tiny and does one thing very well. It’s the same reason I don’t use Swing and AWT - they all do loads of very clever stuff but nothing I actually need without loads of complexity, and, tons of bloat. Xith, jME and J3D are all very very big things that can conceivably do what my sprite engine does but what’s the point in bullying them into doing it when a custom solution is better, smaller, and more efficient?
Cas
Sure, your own solution is always better, smaller, and more efficient, but that’s not what we’re discussing here. We’re discussing a common solution for a gaming GUI.
I suggested a modified Swing but that wouldn’t work for some reason. I’m stilll not totally convinced but you cannot get everything can you
I mentioned a scenegraph. It was just an example of how some games might gain from using a complex rendering structure and some wont. In the same way some games may gain from using a more complex GUI and some wont.
There’s isn’t often you ge divine intervention but I think I have a relevation now. If you want to get something done you have to impose it. ;D
I’m taking the modified Swing route more or less in the near term. Since '03 I have had a GUI API that is “modified Swing” using Java2D directly for implementing a bunch of custom GUI components geared for real time use (audio software in my case) with the ability to mix my API with embeded Swing components for non-real time GUI controls. My API includes a single threaded dispatch system to deal with the AWT event queue and provide exact timing. Gonna swap out the Java2D core and replace with JOGL and/or a mixture if pertinent. I’ll probably try to provide peers for Java2D and JOGL cores to be able to fall back on for systems that can’t handle the JOGL stuff.
Now all of this of course isn’t a generic GL system for full screen games compatible with all GL libraries (LWJGL, etc.) though there might be enough crossover to embed it in JOGL oriented fullscreen apps.
Hi,
Sorry for my long absence. Not that anybody would miss me, but … anyway
To recap… We were thinking about a XML structure to describe GUIs. We examined several “standards” as can be seen in the previous posts above. But we haven’t found any suitable structure that really meets our requirements (too sparse vs. too bloated). Thus we thought about outlining our own.
I haven’t made any progress yet on that topic. In fact the whole FengGUI was put in a coma for the last two months because I needed to deal with other matters first.
[quote]So what kind of XML structure are you thinking of using for layout and style? glgui has shader xml attributes for most widgest but that doesn’t help at all in separating style from the layout structure. Sometimes the most simple aproach is the better one. My solution would be to map one java widget name to one xml element and xml attributes to java bean properties. The XStream idea that cylab mentioned may be worth to investigate.
[/quote]
Although I was against mixing layout and style in the same schema I now agree that it would be a sensible thing to do. That means I will trash my current ANTLR solution to parse theme descriptions.
I also agree on the idea to map one Widget type to one XML element. But maybe we want to leave beans out for the moment.
I experimented a bit with XStream and I find it very handy for small data structures, but very very suited for our task. Some if it’s features are
- It serializes any object to XML
- It is not DTD bound
- It is flexible enough to plugin in your own handling methods, so that certain objects are treated differently
- handles back references and duplicates
When I serialized a simple GUI (a Menu Bar with four menus, each having a couple of Menu Items), the output file had 1177 lines (I told XStream to neglect backreferences to the binding as well as image data and font data. Otherwise it would have been even bigger) and was about 60 KB in size. I examined the stuff that XStream created and much of it was not really necessary information. E.g.
- empty entries in event listener queues and other lists
- completely unfolded Signal Hooks
- Appearance Attributes of each state in a State Widget were listed
- and some more smaller, but nasty things…
I believe that all of these problems can be solved by defining own handles to process these objects in question. However, I think that by designing a standalone DTD first and then map it on FengGUI is better in the long run. Otherwise the data structure that FengGUI builds would serve as the de facto standard which is risky because when we change something minor in FengGUI an avalanche effect could be triggered with an impact on almost the complete XML output. Furthermore, we can compress the schema a bit (e.g. putting RGB values in attribute fields, not elements, as well as coordiantes, margin and sizes) which will make it more readable and cleaner. XStream maps nicely one-to-one from a given instance of a data structure to XML, but FengGUI’s model is not clean enough be mapped just like that 
Johannes
PS: I will post a first idea of my DTD here in a couple of days (hopefully sooner).
Quoth Princec:
Well YMMV but I’m having a lot of success building a very rich game UI using Swing on JOGL. There are some differences - mostly since the UI gets repainted every frame some of the repaint logic is pretty redundant for example - and some annoyances to do with lightweight vs heavyweight - worst examples being anything modal (Swing has some really dumb legacies cos it’s all descended from AWT - they really should have been parallel hierarchies).
However that aside, being able to design complex HUDs in NetBeans with the lovely NetBeans forms editor is just brilliant. All the advantages of Swing - peering and the ability to completely customise look, feel and even deep behaviour - allows you to use desktop widgets that look and act completely gamey particularly. These are wheels I’d hate to reinvent.
Hopefully in about 6 months or so when the product launches you’ll be able to see for yourselves
What I think we should be doing is persuading the guys at Sun to give us a lightweight Swing that only needs an input event queue and an output Graphics and has other no dependencies on AWT, native windows etc etc.
Hey, Dave ! Since the last time I read something on Fuze3D (on ShortFuze) I thought you were almost dead… Is Fuze3D still active ?
[quote="<MagicSpark.org [ BlueSky ]>,post:38,topic:25990"]
Hey, Dave ! Since the last time I read something on Fuze3D (on ShortFuze) I thought you were almost dead… Is Fuze3D still active ?
[/quote]
Hiya! Yup and its the basis of our great new application (to be announced later in the year). When I get some time away from the main app I’ll be updating the Fuze3D package (which we are of course keeping open source) - but that won’t be until late summer I’m guessing now.