Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (769)
Games in Android Showcase (230)
games submitted by our members
Games in WIP (855)
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]
  ignore  |  Print  
  Generic OpenGL UI Project?  (Read 17560 times)
0 Members and 1 Guest are viewing this topic.
Offline Amos Wenger

Senior Devvie




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


« Reply #30 - Posted 2006-02-07 17:16:48 »

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

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

Senior Devvie


Projects: 1


System shutting down in 5..4..3...


« Reply #31 - Posted 2006-02-07 17:33:42 »

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.

Offline princec

« JGO Spiffy Duke »


Medals: 1058
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #32 - Posted 2006-02-07 18:18:36 »

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 Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline .uj

Junior Devvie





« Reply #33 - Posted 2006-02-07 22:31:04 »

a custom solution is better, smaller, and more efficient?

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  Wink

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

Offline Catharsis

JGO Ninja


Medals: 75
Projects: 1
Exp: 21 years


TyphonRT rocks!


« Reply #34 - Posted 2006-02-08 21:54:44 »

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.

Check out the TyphonRT Video Suite:
http://www.typhonvideo.com/

Founder & Principal Architect; TyphonRT, Inc.
http://www.typhonrt.org/
http://www.egrsoftware.com/
https://plus.google.com/u/0/+MichaelLeahy/
Offline Schabby

Junior Devvie




The Receding Brow Worm will eat your code!


« Reply #35 - Posted 2006-04-03 06:14:01 »

Hi,

Sorry for my long absence. Not that anybody would miss me, but ... Smiley 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.

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  Tongue

Johannes

PS: I will post a first idea of my DTD here in a couple of days (hopefully sooner).

Offline DaveLloyd

Junior Devvie




Making things happen fast with Java!


« Reply #36 - Posted 2006-04-11 12:42:50 »

Quoth Princec:
Quote
Swing and AWT (or even SWT) doesn't mix too well with the game rendering and input model (which is continuous).

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  Wink

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.

Offline Amos Wenger

Senior Devvie




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


« Reply #37 - Posted 2006-04-18 16:59:44 »

Hey, Dave ! Since the last time I read something on Fuze3D (on ShortFuze) I thought you were almost dead.. Is Fuze3D still active ?

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

Junior Devvie




Making things happen fast with Java!


« Reply #38 - Posted 2006-04-20 16:48:51 »

Hey, Dave ! Since the last time I read something on Fuze3D (on ShortFuze) I thought you were almost dead.. Is Fuze3D still active ?

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.

Pages: 1 [2]
  ignore  |  Print  
 
 

 
EgonOlsen (1578 views)
2018-06-10 19:43:48

EgonOlsen (1663 views)
2018-06-10 19:43:44

EgonOlsen (1150 views)
2018-06-10 19:43:20

DesertCoockie (1578 views)
2018-05-13 18:23:11

nelsongames (1178 views)
2018-04-24 18:15:36

nelsongames (1669 views)
2018-04-24 18:14:32

ivj94 (2427 views)
2018-03-24 14:47:39

ivj94 (1635 views)
2018-03-24 14:46:31

ivj94 (2727 views)
2018-03-24 14:43:53

Solater (889 views)
2018-03-17 05:04:08
Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45

Deployment and Packaging
by philfrei
2018-08-20 02:33:38

Deployment and Packaging
by philfrei
2018-08-20 02:29:55

Deployment and Packaging
by philfrei
2018-08-19 23:56:20

Deployment and Packaging
by philfrei
2018-08-19 23:54:46
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!