proposals for jogl

OpenGL Development JOGL Development
#1

  • creating a mailinglist to get rid of html/web forums :wink:

  • ant based build process

  • OpenGL 2.0

  • open a developer branch for such news …,
    to be merged back after code review etc.

  • granting more people cvs write access to force a more open
    development :wink: at least for the developer branches … trust them.
    avoid a kindof pseudo open source basis.
    (-> my id is sgoethel)

+++

if such items can be realized / accepted,
i feel ok to join in jogl … and i can see it as open source
as other open source projects - keeping it activ under the public domain.

best wishes to this new approach.

cheers, sven

#2

java.net does have mailing lists… you just have to use them.

I think someone has already done some work on building with Ant… so we will likely get that soon too.

#3

Yes, OpenGL 2.0 would be cool ;D

bienator

#4

Do graphics card drivers implement OpenGL 2.0 yet?

#5

There are a handful of OpenGL 2.0 drivers public.
But SIGGRAPH will solidify this, when the ARB announces what is “really” going to come out next :wink: (read OGL 1.5)

#6

[quote]Do graphics card drivers implement OpenGL 2.0 yet?
[/quote]
3dlab, a driving force in the OpenGL consortium, published an early version of their OpenGL 2.0 driver for their nice Wildcat graphics cards. Together with some impressive snapshots. Some days ago.

#7

[quote]- creating a mailinglist to get rid of html/web forums :wink:
[/quote]
We encourage everyone to join the dev@games.dev.java.net mailing list. We want to have all projects use it initially as a way to build the community. If the volume becomes too great we will split off as appropriate.

[quote]- ant based build process
[/quote]
We have someone working with the initial version posted to these forums. We hope to have this out soon

[quote]- OpenGL 2.0
[/quote]
We’ll wait for the ARB to officially announce the next version first…

We are working on finishing the guidelines for how we would like the games community on java.net to be run. We hope to have something out by next week. To be a Developer, you need to have a signed Contributor Agreement on file. The Contributor Agreement can be found at:

http://games-core.dev.java.net/sun_contrib_051903_javagames.pdf

Hopefully this addresses all of your concerns.
We appreciate your patience as we try to get everything organized.

d

#8

well this way to agree a license does suck for me

well the BSD license itself might be ok, as well as the XFree86 license … but this kinda extra agreement … hmm.

as well this license, or better the way to “get in”
is an obstacle to join. any other oss project does not need such a thing, 'cause you do agree automatically with the special licenses …

as well as this “print out”, “sign” and “fax” is a big media break :wink:

wtf this thing should help anything ?
just to be sure SUN is granted the right for continue proprietary developments ? i guess so.
well - even with the simple BSD thing, they are able to continue
on a proprietary basis ! e.g. M$ does :wink:

well IMHO you should not put that many obstacles in sharing knowledge , 'cause one could see this as an unfriendly treatment.

sorry of being that much enganged in this social issues,
but they are importment for myself … before i do engage myself into something …

+++

ok i will try the mailinglist from now

having a good time

#9

[quote]well IMHO you should not put that many obstacles in sharing knowledge , 'cause one could see this as an unfriendly treatment.
[/quote]
Isn’t the signed agreement only if you want to have direct commit access to the CVS repository? I’m sure committers will still accept patches and commit them for you.

How is this different from most projects on SourceForge, where you must ask the project lead to get write access??

The source is still free to everyone.

#10

[quote]any other oss project does not need such a thing, 'cause you do agree automatically with the special licenses …
[/quote]
Everyone grants Sun, and every other person or company, all rights to use their code when they stick the BSD license onto it and release it, so Sun does not need another license to get that kind of access.

The contributor agreement is probably there to ensure that the questions that SCO are currently raising about Linux won’t affect JOGL. That is, to cover their backs if you sneak code that you don’t own and aren’t legally allowed to distribute into JOGL. That contract should really be available in electronic form though…

Personally I am fine with everything being BSDed, especially considering that most other Java APIs are completely proprietary, and since you can always fork the project under GPL if you’re not happy with it. However, anyone who plans to host a GPLed or LGPLed project on java.net might want to check out the EULA for java.net to ensure that it does not contain provisions that give Sun BSD-like rights over anything that is uploaded to the site. I have a vague memory that such a clause may be in that EULA.

#11

Guys don’t have a fit over the developer agreement. Sun doesn’t want to end up in the same position IBM is in and has a legal obligation to themselves and their shareholders (like myself) to make sure that if such a thing happens in JOGL or any other project they can say “hey, we have a non ambiguous legal document that says that we are not a fault”. Sun is doing the smart thing by protecting themselves and if you read through the agreement (with a lawyer present hopefully) you will quickly realize that this is the gist of the developer agreement. Its largely a non-issue. They just don’t want someone to commit something from their parent corporation and then have that corporation chasing Sun for millions of dollars later with JOGL is on PS3 or something :slight_smile:

#12

To update everyone, we have finished the proposed Governance Guidelines. The GG are a rough set of guidelines we would like to use to manage the games.dev.java.net site. Please look them over:
http://games.dev.java.net/govern.html
and let us know what you think (like you wouldn’t if I didn’t ask :slight_smile: )

Thanks,

d

#13

My only comment is that once an api becomes stable, it is not inconcievable that it would have 30 days without CVS access, but would be “complete” rather than “dead”

:slight_smile:

#14

hmmm… some JCPish baggage seems to be creeping in here…

So if I feel that issue X should not be resolved a certain way and like 500 people say that it should only the Project Owner can overrule this? Doesn’t really sound like voting to me. So long as one person disagrees - the process becomes bottlenecked. If the number of people who disagree and agree is close - sure, go ahead and debate it some more… but having one dissenting voice slow down development is crazy IMHO. We will move VERY slowly that way and with the loss of momentum will likely come the branching of the tree by people who don’t want to be burdoned by that process.

The concept of the Project Owner executive veto is actually kinda crazy as well. If we all say ‘we want full screen mode’ and one of the project owners casts a -1 vote the only recourse left to the community is to fork off their own version and go do it anyway. Equally unhealthy community behavior.

#15

I had pretty much the same concerns…

I do think the Project Owner should have the power to resolve design decisions that do not reach a consensus. And I also agree that a single -1 in among many +1 should not stall the process.

I think there should be some threshold ratios set up where the a -1 can be overruled by the Project Owner only if it is sufficiently outnumbered by +1s.
I think giving the Project Owner absolute power to rule out things seems a bit much, yet at the same time they should have power to keep the project heading in the direction originally intended by the project proposal… sometimes you can get many people voting for something and steering it off in a different direction in a manner that ultimately has a negative effect. Yes this does indicate that the community may want something different… but care must be taken so that you don’t get a “too many cooks spoil the soup” effect.

#16

what is the latest opinion of adding convenient methods to jogl like glColor(java.awt.Color) ?

#17

The first thing I would do is ask - why are using java.awt.Color? Next I would say just extend the relevant classes and add that method yourself.

#18

using jdk classes is a built-in feature of java programmers.
e.g.: i am porting a ‘plasma-effect’ to java which uses an array of Colors. Bringing a single Color-Object into JOGL consists of the following code:


float[] rgb = color.getRGBComponents(null);
gl.glClearColor3f(rgb[0], rgb[1], rgb[2]);

IMHO unhandy enough to have it more than one time.

Well it would be easy to write a subclass with that feature or a helper method by myself. But this brings us the question is the API a provider for OpenGL or for the developer using the API?

I agree that including this into the GL class maybe a design break or so but what about something similar to SwingUtilities for JOGL?

Texture generation and similar tasks maybe added to a utilities class/package as well?

#19

Head over to Java.net and open an RFE on the subject.