Hey Guys,
I understand there’s a specific “why didnt you just adopt LWJGL you bums” thread out there but I can’t find it so let me address a few things here.
(1) On Directions and Roadmaps
The good news is that the Game Technology Group is here, its funded and we can finally start doing thing for you guys with the support of Sun management. Thats a HUGE step forward. This company which still fundementally thinks of itself as a server hardware company has finally recognized some of the importance of you guys to its future.
The bad news. As you know, times are tight everywhere and even this showing of support isn’t the easiest thing to get in a world of competing resource requests. We aren’t a big group. Furthermore for exactly the reasons you guys laid out, that Sun’s primary vision and only revenue source in all this is on the server side, means ever justifying a big client-tech group is going to be
very difficult.
Thats why we did it this way and why we need you. If we all pull together this train is going uphill. If not, it won’t.
Finally we purposefully have NOT laid out a very detailed roadmap yet because we need to be smart and address the needs of our developers not some roadmap made in a vaccuum. There were a handful of technologies we knew were basic and needed. We did our best to deliver those in JOAL/JOGL/JInput. Beyond that we need the help of the game industry, which includes all of you, to understand where we can best focus next.
Again as one of you pointed out we are small and have to make up in nimbleness what we don’t have in brute force.
Given that, as we make plans, we’ll do our best to keep you as informed and invovled as we can.
(2) On JOGL and LWJGL
First off, let me tell you that LWJGL has been extremely important. The fact that you guys went out and did something yourselves was proof of a need that management couldn’t dismiss or ignore. You did some far ranging and critical stuff in LWJGL that served as proof of concepts and helps us illustrated why some heretical ideas are nontheless vitally good ones. (ex. breaking the hard tie btw AWT and the 3D render library.)
Secondly, I’d like you to know that the decision to use JOGL wasn’t taken lightly nor did we set out to develop in direct competition to LWJGL at Sun. Like LWJGL, JOGL began as someoens pet off-time project. When we realized we woudl have the resources to back a solution for OGL bindings, we considered all our available options carefully. In the end JOGL won because of two primary reasons:
(1) JOGL is actually auto-generated for the msot part from the C bindings for OGL using a tool that JOGL’s original authors wrote.
As such it was the most up to date and complete binding we could find today and is likely to b e the easiest for us to keep up to date as OGL continues to evolve. This was a critical issue for a small group with limited engineering resources and a lot to do.
(2) LWJGL chose simplicity over security in a few key areas. A piece of unknown code calling LWJGL can get access to memory pointers and thus malicously attack or infect the host machine. This isn’t an issue for closed games, particularly if they use sealed packages, but it was an issue for the larger set of applications we hope to enable, some of whom might dynamically load code from updates or even users.
These are the same reasons (along with general naming similarity with JOGL) why, in the end, we chose to use the same tools to generate JOAL.
Trust me when I say none of us in the Game Technology Group want to do any more work then we have to on this stuff, but we ALSO wanted to deliver the best technologies we could without prejudice or emtional attachment. Thats been our goal, I hope we attain it. In the end, while we appreciate your input tremendously it leads directly to decisions we have to make and live with.
LWJGL stil leads the way in some important places, such as the aforementioned non-AWT dependance. If you guys continue to build on it and illustrate other great ideas like that, you can only help us. Similarly if you want to build ontop of JOGL we can use that help too.
<< soap box on >>
But this isn’t “Sun v. LWJGL” and I refuse to see it that way. Its us in the GTG just trying to do our best to support the whole game industry as best we can. We spent all E3 talking to commercial developers and getting their input, too. We will continue to plumb them and you for your advice and help. You may not like all of our decisions, it woudl be unreasonable to expect that you would, but in the end I hope we will be a real community that can succeed together in changing the game industry. Neither of us can do it alone.
<>
P.S. FWIW it probably helps us if you keep up the noise about Java3D support, too. I personally agree with those who say the industry wants higher level solutions. I remember when I strated this every developer I talked to said “screw that scene graph stuff, just give us OGL bindings.” Its ironic that support for J3D has come into question just when its approach is finally becoming an accepted way of doing things in the industry. But if you can communciate that fact to Sun management as effectively as you have the need for OGL bindings then there is a lot that could be done to address it.
P.P.S. BTW We would be honored to host LWJGL at games.dev.java.net too. It won’t be in “core” because “core” is a special distinction for stuff the GTG is supporting directly but it certainly could be hosted in one of the other areas assuming the community wants it there.
What we are left with, when static import makes it into the language, is code that more or less cuts and pastes from C apart from pointers. This is great for getting tutorials together from the huge library of existing GL code.
