I'm sure that a SUN official OpenGL binding like Jogl will find its way into a future J2SE.

While it does seem certain, 1.5 is only just about to get a release, 1.6 is ages away. Its not really relevant to those who want something working *now*.

Quote

When it's inside J2SE or at least has the button "SUN tech" on it (see other threads) it's good and one problem less for Xith.

But it is a problem because it doesn't work, or is fatally buggy on many platforms. I for one am getting fed up of people not being able to run S-Type (or indeed the basic Jogl gears demo) which run LWJGL apps fine. Until Jogl is robust and actually works its not a solution, its just a toy.

If its not too much of a problem to use either Jogl or LWJGL then its all good. But nailing it down to just Jogl seems like an incredibly bad move.

There is no actual requirement to use LWJGL as a shared library you know. Just fork it, lift it out and plonk it into Xith3d. Occasionally you might want to merge it but the idea is that you have a separate, independent living platform with a life of its own that depends on no-one else to make it work.

O'course it's totally moot until we get Mac support and seeing as we're all too skint / inexperienced / busy to sort that out Xith is definitely better off with JOGL

Xith3D/JOGL for people wanting to incorporate 3D stuff with AWT/Swing apps and great with JWS.

Xith3D/LWJGL for people who want to distribute Jet EXE's with the smallest possible size (infact as I have discovered - Xith3D wouldn't add much to the clout of a LWJGL project). Maybe - just maybe, sometime in the future, deploying on an OpenGL console!

I feel that both are useful. Now what we really want is that abstract OpenGL layer Cas was proposing on the forums so even if people start accessing OpenGL directly - it'll still work on LWJGL and JOGL.

And I'm sure Xith3D/SWT fits in somewhere too, perhaps as an alternative to AWT when you want a rich UI that LWJGL doesn't provide.

Let me add one more combination: swt is for those needing a Gui and wanting to use JET for providing a JRE free installation. If using Swing and compiling with JET this one does not complain but it requires an installed JRE for runtime purposes also.

There's quite a lot of obsession with AWT and SWT for "rich guis" but to my mind these things can, for games at least, be coded excellently in purest OpenGL and simply rendered every frame.

Now, we're in a games forum talking about gaming technology... so is Xith going to be a games API or is it going to compete head on with J3D in the medical visualisation space, CAD/CAM, etc.?

If Xith is going to differentiate itself properly I think it might want to relax its requirement that it interoperates fully with Swing and allow developers to create native GL GUIs. Such as the ones you might use in games...

I disagree that there is no use for Swing, Awt or Swt. You could do any ui in opengl yes that is right but why to invent the wheel for another time again? The Uis have proven to be useful, are stable and I won't miss translucient guis that do not force me to split textures into pieces (256x256 and up).

Integraton of Swing requires some rework for the input handling (key, mouse, focus) but after that there should not be any more problem. And having used Swing since 1998 (with all its errors, flaws and so on) I have to mention that it is not easy to do everything it offers by hand again - I even do not have the time for writing that from scratch. And as I demonstrated with http://team.micram.de/dingfelder/projects/xith3d/jnlp/levelbox/LevelBox.jnlp it is possible to get nice effects (even watermarks) with a minimum of code ...

There's quite a lot of obsession with AWT and SWT for "rich guis" but to my mind these things can, for games at least, be coded excellently in purest OpenGL and simply rendered every frame.

(I'm ignoring AWT which is not really a high-level GUI API, and is not really maintained any more either)

Quote

I think it might want to relax its requirement that it interoperates fully with Swing and allow developers to create native GL GUIs. Such as the ones you might use in games...

You say this often, and I often respond by asking about the high-level parts of the Swing API, and still neither you nor anyone else has come forth and provided high-level GUI API features on top of OGL.

It's well known that I detest JTree and friends, but I don't throw the baby out with the bathwater; much of swing has great value.

Heh. It strikes me as ironic that in a forum about a high-level rendering API you advocate dumping a high-level GUI API in favour of having everyone roll their own from a very low-level API ...

There's quite a lot of obsession with AWT and SWT for "rich guis" but to my mind these things can, for games at least, be coded excellently in purest OpenGL and simply rendered every frame.(..)If Xith is going to differentiate itself properly I think it might want to relax its requirement that it interoperates fully with Swing and allow developers to create native GL GUIs. Such as the ones you might use in games...

There's many occassions you can use Swing with your game. Remember, there are many different types of game. Imagine there's even games which need high level GUI stuff like Swing - not neccessary rendered to the main screen, but tied next to it, or beside the main windows, etc etc. Yes, there are games other then Quake3 engined ego shooters and similar ones. :-)

Einstein said: make it as simple as possible, but not simpler. Listen to him, Cas. :-)

I strongly advocate ditching Swing because it's absolutely massively overpowered and complex to do a game GUI. Not only that but it's closed source and difficult to bully into doing what you want. It's like using an atom bomb to crack a nut.

I say this:<soapbox>You don't need MVC. You don't even want it most of the time in a game. You just want widgets that do stuff and draw themselves. When was the last time you saw a game with a complex user interface? When was the last time you needed BIDI HTML rendering in an editing control for a game?

You are all very guilty of trying to be too clever by half here Create what you need to make it work, and no more; or you'll not create anything, or just as bad, you'll create something that's so complex and fiddly that no-one likes it (hah! rather like Swing). And while we're at it let's not forget the huge memory requirements and dependent APIs requirements of using Swing. Not to mention the vast catalogue of bugs you can't fix because it's not open source and you have no control of the deployment.</soapbox>

I personally really think that implementing LWJGL renderer for Xith3D is really worth addition to Xith3D. For a moment, I have absolutely no experience with LWJGL, but this is a minor point.

I 100% agree with your comments regarding minimalistic implementations. As of Swing, AWT, etc. I prefer to have them, but have them optional. There is absolutely no reason to throw away experience that some devs have with Swing apps, because of the major goal I see as shortening the development time and reducing project costs.

As of Xith3D vs. Java3D, I don't see any problems with this. If Sun's policy will be open enough to co-operate, I personally will co-operate, while I definitely want to see 3rd-party alternative. The same I will see about low-level bindings, such as JOGL and LWJGL.

My current position is: if I will not see any activity on JOGL project within a month after GDC, I will take the implementation fo LWJGL-based renderer for Xith3D. I already waiting for some features for more than 6 months (at least "Developer controlled swap buffers"), and I almost ready to start thinking about alternative.

@Bombadil:

Quote

Funny you say this in the Xith3d thread, with Xith3d being in a kind of alpha phase, so much about "far away"... :-)

Depending on what do you mean by alpha phase. For me this is just the name. The API either ready or not ready for YOUR APPLICATION. After reasonable testing, I am ready to deploy current version of Xith3D with my production apps, and I really don't care about the features not implemented and which I don't use.

Cas: one thing I believe is a strength of using swing is that "mouse-less" navigation is provided "out of the box" - if the game uses swing based controls I can be sure (?) that I'm not required to use the mouse to navigate between every different control (which "a lot", not all..., of games require today - stupid and irritating, why the **** doesn't it work to <tab> or <shift-tab> between input fields!?).

So I guess using swing or not depends on (atleast) two factors1, How much (extra) work do I need to do to be able to have a gui that is as accessible (or better) than a swing dito2, Do I care about having such a gui/Does my game involve enough input to require such features (no mouse navigation needed etc)

Cool stuff. I must say that it's telling that gregorypierce has, er, jumped ship again on OpenGL bindings...

Quote

1, How much (extra) work do I need to do to be able to have a gui that is as accessible (or better) than a swing dito2, Do I care about having such a gui/Does my game involve enough input to require such features (no mouse navigation needed etc)

Well, the answer to 1. is bugger all, took me a few lines of code, and 2. no, probably not. No mouse navigation? Why do you want to write a GUI that doesn't use mouse navigation for a PC game? But let's face it, how hard is it to do? It's trivial. It's all just trivial. It amazes me just how complex some problems can be made by API designers.

Well, the answer to 1. is bugger all, took me a few lines of code, and 2. no, probably not. No mouse navigation? Why do you want to write a GUI that doesn't use mouse navigation for a PC game? But let's face it, how hard is it to do? It's trivial. It's all just trivial. It amazes me just how complex some problems can be made by API designers.

You are right complaining that swing is somewhat overpowered for all kinds of usages. On the other hand it allows you to choose HOW to implement a certain input (the kind of how to present a dialog, multiple layouts&widgets + different views, user defined mappings etc). Things I personally do not want to miss.

To 1: I disagree with having only a few lines of code for replacing it all. That may fit for egoshooters but a game like civlization, sim city etc. without an easy to do gui having only a few lines of code that have been testet, are free of errors etc.? Nope. I did a simple graphical hires gui for dos some years ago and it turned out to require more and more time to add features, fix errors and so on. Currently I do not have the time for doing so any longer.

Of course if you do have the required code using opengl only and that is all what you need - use that because it will be faster for YOU when it comes to maintaing your code. Doing good and fast guis with Swing certainly requires some skills plus time and cannot be done from scratch easily. But there are others that started their Java times with 2D and that often leads us to Swing or Swt. And for them having such capaibilites will shorten development times. And that is what counts in our business world- at least for those paying our salaries...

The second point is interesting also. GUIs where it is possible to navigate without using a mouse. Again shooters will not need this in general but there are games where you have to enter several values, maybe you want to chat etc. Doing so by keyboard can be significantly faster for experienced users. Also you can use the mouse for some other action allowing you to have dual action.

Cool stuff. I must say that it's telling that gregorypierce has, er, jumped ship again on OpenGL bindings...

Last I heard he isn't using JOGL or LWJGL, but had to write his own to get what he wanted..

Anyway, I just want to chime in and say I would want something that supported Swing, though it could be an option. AWT and SWT I don't care about at all, as AWT does seem to be no longer supported, and I've never thought there was much point to SWT.Like Cas says, it is easy to roll you own UI for most game purposes, and if you need something feature rich - that's why I want Swing support.

@Bombadil:Depending on what do you mean by alpha phase. For me this is just the name. The API either ready or not ready for YOUR APPLICATION. After reasonable testing, I am ready to deploy current version of Xith3D with my production apps, and I really don't care about the features not implemented and which I don't use.

My comment has been meant constructive, but realistic. You know I really like Xith. In my experience with beta phase you usually mean an application fully working including all features, documentation, etc, but still with (many) bugs which need to be fully tested. Alpha phase means anything before that point.

Of course you can deploy Xith with your production app, because you're one of the main developers of Xith... ;-)It's different for pure users however. Since currently I use Xith for a hobby project, I'm confident that all the missing features, the docus, the stability, the loaders, etc. which I need will be ready in time when my project is about to be finished.Clearly for a larger team on a commercial project, confidence alone won't do. In case I (as a user) needed Xith for a commercial project now with 1+ artists etc, we couldn't use it yet because we couldn't base our business decision on a yet vague base.

Again, please see my comment as constructive. I know you and the other Xith developers do a good job and that Xith is very young - so no problem!Basically we discussed similar things in another thread here around (namend "So what's missing before announcing 1.0?").

Back to topic: I'm happy you don't intend to kick Swing like Cas suggested. Your intention to keep such well known packages to be used on demand within Xith is a good one.

Cool stuff. I must say that it's telling that gregorypierce has, er, jumped ship again on OpenGL bindings...

I had very specific needs that neither API served and since binding to OpenGL isn't rocket science - it made a lot of sense for me to just roll my own and solve my problems instead of trying to convince people why my needs were valid and needed to be addressed.

Outside of a funky native window resize bug in windows and a kernel panic on window resize on OSX (which is strangely similar to one that JOGL experiences) - I'll be releasing my stuff in a couple of weeks once a user guide is written. The connection to Xith required more than a little magic but works and PBuffers have caused a fair amount of trouble to gain the desired level of API abstraction. But otherwise - it works and I'm happy with it. Other people may not like it or want to use it - but really, don't care

I definitaly agree that Swing support is good to have - indeed David's userinterface package is great! I urge you to look at some of Magicosm's screen shots if you havn't already - a very good showcase for swing in games, and one I am sure it would have taken him much longer to do in pure OpenGL.

The fact of the matter is that if you don't want it - you don't have to have it! And if you do, you can - so everybody wins.

Personally I am using Swing for a more rapid development. If the need arises in the future, the UI can be changed to suit.

I had very specific needs that neither API served and since binding to OpenGL isn't rocket science - it made a lot of sense for me to just roll my own and solve my problems instead of trying to convince people why my needs were valid and needed to be addressed.

The community really needs to discuss these various needs at length and make sure that JOGL and LWJGL are heading in the right direction. Ideally they should be sharing OGL bindings at some level. With the right level of abstraction sharing OGL contexts between LWJGL, Xith3D, JOGL, etc. shouldn't be an issue.It's great already that Xith3D can be used with different bindings. But OpenGL is OpenGL... JOGL and LWJGL don't *need* different bindings to the OpenGL APIs, so long as they can call OpenGL the way they want.

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