LWJGL 2.0 ALPHA

[oNyx]

I would prefer lwjgl_glu.jar over lwjgl_util.jar, except some are also worried by the number of jars

- elias

agreed the number of jars was the reason i was unhappy with this change, as before you only had to worry about one external jar. Besides if you are worried about size you can always use something like proguard to remove the unnecessary stuff from a jar.

If you're worried about the number of jars you can always repack 'em.

Another vote for lwjgl_glu.jar

[bobjob]

personally im not fussed on the number of jar's.

For the sake of new LWJGL users I think less is better because a few people use lwjgl to learn about opengl. I think alot of people had trouble getting the stuff in the util packages to work because they didnt know about extra jar files. Once people are confident with lwjgl they can chop and change it around the way they like.


like i said, Im happy with any setup you guys decide. Keep up the great work!

[princec]

However, I am concerned about the number of itty bitty downloads I'm doing to get a release - I'd rather all the stuff was put into a single released zip file instead of the 5 or 6 separate downloads we have at the moment.

Cas

[oak]

I would say chop things up as much as possible, using proguard or having to manually repackage things is annoying. Modern IDEs like Eclipse make it a breeze to add JAR-files to the classpath. Please, please do chop everything up as much as possible to allow easy picking and choosing.

N00bs (gotta love that word  ) can just select the whole bunch, right-click and choose "Build Path"->"Add to Buildpath" and voila they are up and running with no missing classes.

[princec]

Would be nice to actually port OpenAL-Soft into pure Java and have a number of small native backends to actually output the sound...

Cas

[kappa]

Would be nice to actually port OpenAL-Soft into pure Java and have a number of small native backends to actually output the sound...

Cas

hehe, wouldn't it be quicker to just start from scratch ? 

[mot]

Would be nice to actually port OpenAL-Soft into pure Java and have a number of small native backends to actually output the sound...

Cas

Agreed. Seems like a good way to get stable sound support.