looks like we have some competition

Engines, Libraries and Tools Xith3D Forums
#41

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:

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 :slight_smile: 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.

Cas :slight_smile:

#42

Cas,

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”… :slight_smile:
[/quote]
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.

Yuri

#43

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 or between input fields!?).

So I guess using swing or not depends on (atleast) two factors
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 dito
2, Do I care about having such a gui/Does my game involve enough input to require such features (no mouse navigation needed etc)

#44

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

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.

Anyway, it’s just a thought.

Cas :slight_smile:

#45

[quote]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.
[/quote]
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.

#46

[quote]Cool stuff. I must say that it’s telling that gregorypierce has, er, jumped ship again on OpenGL bindings…
[/quote]
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.

#47

[quote]@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.
[/quote]
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… :wink:
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.

#48

[quote]Cool stuff. I must say that it’s telling that gregorypierce has, er, jumped ship again on OpenGL bindings…
[/quote]
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 ;D

#49

/me awaits Greg’s OpenGL binding with resizable native windows.
Anyways, time to drive back to Massachusetts from Montreal :-/

#50

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.

Will.

#51

[quote]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.
[/quote]
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.