It's not working yet, which means it would be another task for us.
It's a later feature for a reason: As we add big features and make any major changes, we now have two points of failure. Two areas to update.
We'd now have to start supporting issues. We already have the "Why won't this work? LWJGL demos don't work either", type of posts. We'll start getting the JOGL posts as well.
However, JOGL support would do a lot. Increase support of APIs shows how robust jME is. We're supporting the "official" OpenGL for Java. A lot of people want it (for some reason ).
What's everyones thoughts on this.
My vote personally is: Finish it first, then we'll talk.
You mean finish jogl support first, then talk? Yes, I would say that, too.
Yes, that's what I meant. We have enough on our plate to take his incomplete code and finish it for him.
is JOGL 'better' just more complete etc.?
I would say no, from my experience. The opposite may even be true.
The reasons I want to support JOGL are:
- #1, it shows that jME is designed well enough to allow pluggable renderers.
- #2, it's the "official' OpenGL binding endorsed by Sun, and that may affect many people's decisions.
- #3, some people have expressed a preference for it in the past (although why they would care, I don't know, perhaps because of #2)
I don't see any big advantages to the JOGL support from a technical point of view either. Do people really want JOGL so bad just cause it has some (somewhat reluctant!) endorsment from Sun?
It does show off the "pluggable" part of jME, but I don't think you need to support two bindings in CVS by yourself that target pretty much the same market right now. However, if you think the idea of a pluggable system is important (and I can see why it would be, I can think of cases where it'd actually be useful) then you could see this as a good chance. Answer like: How easy will it be for someone to maintain such a plug in? What parts of the system could be changed to better accomodate it? What can we do about code managment?? (maybe use branches?) etc. could be answered. Then when one day someone comes along and wants to, for example, port jME to the OpenGL ES bindings ( http://www.jcp.org/en/jsr/detail?id=239 ) so there will be a jME version for smartphones, it'll be easier for them too.
Of course if whoever wants to maintain this JOGL port keeps putting in a lot of good work, it could be included in the project itself, one way or the other. But I don't think the requirment for a new feature or a change by either the devs or users should be "must work on JOGL and LWJGL".
My two cents… I think we should hew to the plan we put in place. It's nice that people want to help, but we put Jogl support near the end of 1.0 for a reason - we don't need to be supporting two systems at this time. Not only that, but none of us are all that strong in Jogl (as compared to lwjgl) anyhow.
I'd say thanks, and put it somewhere open source to allow people to work on it and do what they'd like, but make it officially unsupported until our planned release time.
).