More devs needed for core?

General Discussions
#1

It seems clear that we could use some more developers involved in the core products. The bulk of the work has been done by like 3 people and they have done a bang-up job. But now with more and more people using the core, we may need to solicite some additional developers to help bring the core to production readiness.

  • JOAL has got some problems currently in the non-windows world.
  • There are ongoing capabilities setting issues with JOGL, and some fuzziness on the status of Mac version.
  • There are some issues with JOGL on linux as relates to offscreen drawing.
  • The GLPanel/canvas continues to be problematic for some people.

Any chance we can put a message up on the main javagaming site and other places to actively persue adding a programmer or three?

#2

sigh this is so frustrating. Ken Russell had asked me to join the development team some time ago, but my employer won’t let me work on jogl in my spare time. I’m not sure where I stand legally on this issue and I don’t want to risk my job just yet, so for now I’m stuck porting tutorials :frowning:

#3

Remember some very high-potential people here already HAVE worked on OpenGL, OpenAL and input bindings. Maybe they just don’t want to do that again for a big companies sake…

#4

I am not sure what that means…

What “big company” are we talking about? These core game technologies are all ours, they will live and die based on our work, not Sun. Are you saying that we should not work on them because Sun might benefit?

#5

Just to give an idea of where the Mac stuff is headed. I have spoken with Ken about it and it looks like the OSX stuff is likely to become my baby for better or worse :slight_smile: It needs a lot of work. JInput is mostly complete 80% or so. JOAL doesn’t even build because the build scripts make a LOT of assumptions that just aren’t true on OSX. JOGL is simply incomplete. There are many things that have ‘fix me’ associted with them and I needo get those pieces working first. My priorities are get JOGL complete, get JInput more complete with respect to input devices that make JInput on OSX blow up or not report/use functionality properly, and finally - get JOAL running properly on OSX (which looks to require extensive work and reengineering based on some of the OpenAL/OSX stuff I’ve seen). Really wish this whole thing was done as an SPI so that it didn’t depend so heavily on how OpenAL works (or doesn’t) on various platforms.

In terms of reworking, the Sun API set is the most complete. Especially on non-windows platforms. In addition, if Sun wins - we win. Noone is going to adopt something that doesn’t have the support of a major player.

That’s life for those of us who want to make money or products using this technology.

#6

[quote]These core game technologies are all ours, they will live and die based on our work, not Sun. Are you saying that we should not work on them because Sun might benefit?
[/quote]
No no, of course not. Just the most suitable people here might be tired of doing it again. And this time not for their own project, for their own glory.

E.g. JOGL here, JOGL there, JOGL on big Sun presentations, well pushed be the big company. “See how cool 3D can be done with Java!”
The LWJGL forum is drying out … I think that is not a good motivation for the LWJGL guys now to jump onto that train.

See what I mean? My english …

#7

I think Herk is getting at the issue that was raised when SUN first announced the “new” open source APIs.

The functionality supplied by JOGL, JOAL and JInput was already available in Java (via LWJGL and/or JXInput). However the new projects were opened clearly duplicating some effort without (as far as reported) the creators of the APIs even being consulted. It may be true to say that the libraries supply things in a different way but it is surprising that this judgement could have been made without first talking to the other projects.

It would appear to the casual observer that SUN has trampled on the homesteading ideal of opensource and I can imagine the people that wrote these original APIs while being super qualified to help develop the new libraries may also not want to get involved.

Anyhow, just a thought…

Kev ‘please don’t ban me’ Glass

#8

Damn straight I’m not helping! But not for any reasons of disgruntlement:

  1. Our API’s better! Simple as that. No point in dividing my efforts when I can be making the existing better one more better.
  2. We’re focused on games programming, and JOGL really… isn’t. It’s a proper full-featured OpenGL implementation and I see it being far more useful to people developing industrial and desktop applications like CAD/CAM or game development tools.

(Bootnote: It’s not like suddenly everyone’s deserted LWJGL in favour of JOGL, is it? Those who need LWJGL understand why they need LWJGL, with all that it implies.)

Cas :slight_smile:

#9

[quote] (Bootnote: It’s not like suddenly everyone’s deserted LWJGL in favour of JOGL, is it? Those who need LWJGL understand why they need LWJGL, with all that it implies.)
[/quote]
Not to mention that I’ve been trolling the puppy games forums for LWJGL discussion. That has been much more active re: LWJGL than the LWJGL folder here at JGO.

#10

[quote]1. Our API’s better! Simple as that.
[/quote]
I’m going to have to call bullsquid on that.
“For what reason?”, I hear you ask. Well:

[quote]2. We’re focused on games programming, and JOGL really… isn’t.
[/quote]
Your focus on games programming includes some strange assumptions, and it feels like instead of working WITH java, LWJGL is working AGAINST java.

Like, say, the documents that suggests using only static methods and so. :wink:

#11

I’m not arguing about it in here.

Cas :slight_smile:

#12

Well now that I’ve had a chance to talk to some of the people associated with the development of these APIs, let me just say that its not necessarily a true or at least not complete statement. JInput in particular came from an open source submission that was turned over to become JInput. JOGL wanted to do some things differently - in some cases, very differntly. So in a sense it makes it perfectly okay that both exist and both communities exist as each project is looking at the other (or at least the users are) and knowledge is being shared back and forth. In truth there is simply not enough bandwidth to go between both projects so both projects suffer as a result - but that’s another story.

I wouldn’t think that and many of the people I’ve talked to in the general gaming industry are more of the impression that Sun has gotten ‘serious’ about gaming as they are spending their own money on it as opposed to relying on open source to make it happen. To a certain segment of the world - that’s very important and having a name behind things - someone that is spending money to support it - means more than the maturity of the implementation of some particular features.

There isn’t anything wrong with not wanting to help one API or the other. I personally don’t have the time to do a Mac implementation of both and its in my best interest to improve the Sun effort so I work on that as opposed to LWJGL. Developers will work on what makes the most sense for them. Hopefully noone feels so slighted or is so blinded by gathering ‘honor’ that they are not participating in either project for those reasons. That would just be stupid.

#13

To be honest, I quite happily use the right tool for the job, but that really wasn’t the point. I hope the point was that it was understandable that the developers of the older APIs whose effort has been duplicated (at least in some part) may not want to get involved with the newer projects which is a waste since these are the very people that would be useful to these newer libraries.

You could argue that its “stupid” of these developers to take this attitude, but then people are people after all (and calling them stupid rarely helps). You could also argue that if before SUN had developed JOGL, JOAL and JInput they could have talked to the existing developers and got some useful input and potentially have gained some highly qualified community developers on the way.

If you take a really cynical view the the new APIs could be seen as SUN using their obvious influence to push other projects aside side stepping one of the major corner stones of OS, but then thats probably just too conspiracy theory. ::slight_smile:

I guess I was just trying to clarify what Herk was saying above.

Kev

#14

I’m glad to say that we’ve differentiated our product to such a radical extent it really is a totally different proposition to JOGL, JOAL, and JInput now, and really no skin off our noses at all. Sometimes it takes competition to help improve things and in this case the existence of JOGL has turned our API into the best API for Java games there is :smiley: So thanks for everything really :stuck_out_tongue:

Cas :slight_smile:

#15

Thx kevglass, when I read your posts I think it is about what I wanted to express.

#16

I can’t help thinking back to just after the launch of JoGL when Sven Goethel (author of GL4Java) turned up here in a whirlwind, trying to work out what just happened. I still find it incredible that as the author for many years of the only viable OpenGL binding for Java, he wasn’t even given a heads-up on what was going on. But anyway, all that is past.

And on the LWJGL front, I use it because it makes sense for me at the moment. I still follow the JoGL forum and await the API’s maturity with interest, but currently I can’t be bothered with the extra complexity it adds. LWJGL does all I need it to.

But back on topic - how many people interested in being a core developer are put off by the fax-back system? And how much information is there out there to get people started in the core? And how much pimping of the position is being done?

My guesses: quite a lot, not really enough and - apart from this thread - none. :-/

#17

[quote]You could argue that its “stupid” of these developers to take this attitude, but then people are people after all (and calling them stupid rarely helps). You could also argue that if before SUN had developed JOGL, JOAL and JInput they could have talked to the existing developers and got some useful input and potentially have gained some highly qualified community developers on the way.
[/quote]
I’ve been away for a while (just moved to SF from NYC) so I haven’t been following the forums as closely as I should. As one of the original developers of the “Sun” APIs (namely JOAL) I’d like to clear some things up. As far as JOAL is concerned, my first inclination was to simply use the LWJGL OpenAL bindings, and, in fact, I ended up using LWJGL as a model for JOAL. The only reason why we didn’t simply republish the LWJGL APIs was that they expose references to pointers, a capital offense punishable by summary beheading here at Sun. IIRC, Cas mentioned moving to ByteBuffers in a future version of LWJGL. If that had been the case a few months ago, it would have saved me quite a bit of work :slight_smile:

OpenGL was a bigger issue, as there are a number of other, non-game, graphics applications looking at using OpenGL, so the pointer issue along with the lack of an integration path with AWT/Swing led us to lean in favor of Jungle (the API that became JOGL) which had also been in development for the last couple of years. While there are a number of issues with JOGL that are the source of both external and internal debate, we are working to resolve these in a way that will satisfy everyone’s needs.

I am personally less familiar with the JXInput/JInput story, but I do know that the technology behind JInput had been around for a while (it was part of JSR-134)

Having said all that, I would personally like to see the net.java.games APIs and the LWJGL APIs ultimately converge, where the lowest level bindings are as thin as humanly (and “Java-legally”) possible (a’ la LWJGL without the pointer refs) with AWT/Swing integration and multithreading support layered on top of it. While I think competition is a good thing, it’s much more effective (and less frustrating) when it happens at the implementation level and not the interface level.

#18

There’s no merit in convergance of LWJGL and JOGL. They’ve actually gone off in different directions and work in very different ways for very different reasons.
It’s like trying to converge J2ME and J2SE - there’s a reason they branched in the first place…

Cas :slight_smile:

#19

[quote]There’s no merit in convergance of LWJGL and JOGL. They’ve actually gone off in different directions and work in very different ways for very different reasons.
It’s like trying to converge J2ME and J2SE - there’s a reason they branched in the first place…
Cas :slight_smile:
[/quote]
I’m not sure I buy the, “different implementations for different applications” line here. J2SE and J2ME are different because they target different platforms with significantly different capabilities. JOGL and LWJGL were both designed (or at least intended) to enable high-performance 3D desktop games in Java. If anything, one could say they’re like Swing and SWT, but even in this case, JOGL and LWJGL, as bindings for OpenGL have much more in common then Swing & SWT. AFAIC, if JOGL were more cleanly layered in it’s architecture. (which, I believe is both technically feasible, as well as inevitable) there would be very little functional difference between the “core” JOGL APIs and the OpenGL bindings in LWJGL…

…with the exception of the exposed pointer references, of course :slight_smile:

#20
JoGL has exposed pointer references now? :o

EDIT: /me hides from the impending ban