in a MMO its a problematic topic. Botfarmer which sell lvl 80 chars etc can destroy balancing/ingame mechanics.

e.g Eve Online has a quite boring profession: mining
a few people really like it since its relaxing (nice graphics, almost no user interaction, you can do something else "half AFK", chat..). I would assume that most of the miners are bots (there are no official numbers), since its an open sandbox mining gets basically worthless. You spend n hours for almost no ingame gain since you can't compete with bot armies. (-> botting kills an ingame activity in this example)

interoperability is currently to difficult. Using language A as DSL for UI, language B for maths and java as system language all running on the same might be interesting but maintaining the interface in a polylingual project is currently a problem.

Doing this on-way is usually not that difficult, e.g generating accessors for OpenCL kernels with jocl or stuff like this. But having groovy, scala and java in the same project is horror.

AFAIR default refresh rate of compiz is 50hz. New installations are set to auto detect which should normally use the screen refresh rate.
hope that helps

i agree, just use it if you like. The only difference between 7 and any other .0 release is that a few journalists went through the bugtracker a bit to early this time.
you could also use the early access build of u2 which already contains the infamous bugfixes which where actually already available as the media picked it up.

what about realtime GPU based forum obfuscation? Was the caesar cipher proposal rejected? The idea was to request a one-time pad via paper mail for every new thread.

just a few examples of some common developer tools/methods. maven is a build system which is esp. good in dependency management of third party libs (another one would be ant), subversion, git, mercurial are versioning systems. Wikipedia will give you a better description if you want to know more.

what kind of functionality? Usually you have to install third party plugins to be able to do basic things with eclipse like maven, mercurial, subversion, profiling, bugtracking etc. What eclipse distribution do you use?

not applyable for all usecases: but what i did is to use nio bytebuffers for vector/matrix storage and do the computation on the gpu/cpu/<other hw> via JOCL. Memory is static in my case. Accessing the data from java is a bit slower however.

lol, you guys are so funny. Cas' pragmatic answer was to ask him to file a RFE for an API the thread opener is not using.


Sure you could merge both categories to 'OpenGL', compete against opengl.org and gamedev.net GL forums which would encourage members to post api specific questions to jogamp.org / lwjgl.org / whatever.org. Question is: where is the gain for JGO?

there is no standardised way to query HW info via OpenGL. You could use JOCL and device.getGlobalMemSize() (and the other getFooMemSize() methods) but those are implementation dependent and usually return less than the physical mem size.

or take a look at those extensions:
http://www.opengl.org/registry/specs/ATI/meminfo.txt
http://developer.download.nvidia.com/opengl/specs/GL_NVX_gpu_memory_info.txt

(we usually don't expose vendor dependent extensions in JOGL, but feel free to file a bug at http://jogamp.org/bugzilla/)

nothing new really. jrockit has always been proprietary, e.g required a license to enable special GC features. They just continue after a JVM merge.

didn't knew that Vampire: The Masquerade used a JVM for scripting. Was an awesome game back than.
http://www.gamecareerguide.biz/features/19990611/java_13.htm#vampire

please read the tutorial. Its everything explained in there.

JOGL2 is not backwards compatible but the changes are minor (almost only the initialization changed).

javadocs etc are linked on http://jogamp.org/jogl/www/

JOGL2 tutorials:
http://jogamp.org/wiki/index.php/Jogl_Tutorial

Are you kidding?
There was no JNI based binding out there at this time. Even drivers weren't officially available. Both, Marco and me had to wait for the driver release before publishing binaries & code. He decided to code everything by hand, I instead used gluegen to generate everything from headers. Additionally Marco initially licensed his stuff with a non commercial license (he changed the license recently to MIT/X11).
This alone was a showstopper for my needs over one year ago. (and yes we worked together to resolve technical issues)

(thats my last post on that topic)

@spasi Thanks for quoting me since i still fully agree with it, despite the fact that its a bit off topic here.
Let me try to explain why:
CL bindings are completely independent libraries. You (as a LWJGL contributer or user) could have the choice between Marco's jocl.org which looks similar to LWJGL's API, Olivie's JNA bindings or http://jocl.jogamp.org which has similar API design as JOGL/JOAL on the low level (lets ignore the high level bindings for now since differ a bit more).

CL-GL interoperability is just about sharing 2 longs at context creation - thats all.

Nonetheless (or even because of that ), i am very carious to take a look at the javadocs of the low level part (we call it LLB).

@Riven
sorry, don't get it what you want to tell me with the first sentence

happy coding!

congrats. Java has now the fourth CL binding...

sure. JOGL 2 already supports GL 4.1 since shortly after SIGGRAPH but you will have to take the automated builds if you want to use it (don't ask about a release date).
http://jogamp.org/
http://jogamp.org/wiki/index.php/Jogl_Tutorial (-> JOGL 2)

hehe, well we had some competition. There was the OpenCL BOF, techtalks and Makeing of Tron Legacy Animation Festival in the largest Hall of the conference in parallel

(it was quite hard for me to talk at the jogamp BOF instead of visiting the OpenCL BOF  )

well, we installed chuck norris on the build server... (scroll down->http://jogamp.org/chuck/job/jocl/)

Effective Java, by Joshua Bloch (second edition)

Its like Clean Code just without esoteric. Its one of those books you probably won't read from start to finish... but its a very good reference for best coding practices.

haha, never post hungry

cool, looking forward to meet you there too.

no reason to run away, you just stated the facts.

Welcome apatriarca,

you could use the library wrapper and native-lib-support module from the NB OpenGL Pack.
http://github.com/mbien/netbeans-opengl-pack
http://projectkenai.com/projects/netbeans-opengl-pack/downloads/directory/early-access
they ship with an around one year old JOGL 2 build but we will update them as soon as there is a final JOGL 2 release available.

This year we will be at SIGGRAPH 2010 with our own little BOF Session:

http://www.siggraph.org/s2010/for_attendees/birds_feather

hope to meet you there

(crosspost from http://jogamp.762907.n3.nabble.com/JogAmp-SIGGRAPH-2010-td834843.html)

answer on the other side

right, server is now on its place and should have enough bandwidth for all of us. The hudson build server is already working, build jobs for more platforms will join the next days.

JogAmp is the common namespace for JOGL and other teamplayers like JOCL and also GlueGen the JNI binding code generator.

you can find a link collection to bugtracker, wiki... on Sven's blog.
http://jausoft.com/blog/2010/05/07/jogamp-org-wip/

contributions and API feedback are as always welcome

hi yombo,

so you are on linux and haven't used our fancy über-back-to-the-future-migration-refactoring-script?
http://github.com/mbien/jogl/tree/master/tools/jackpotc/

.all is the "desktop" distribution. If you don't care about lib size just take this stuff.

-cdc is for mobile (connected device configuration)
.cg is nvidia's Cg language support, but the JOGL 2 cg version is basically untested. (but its on the TODO list)

also take a look at the slowly growing wiki:
http://jogamp.org/wiki/index.php/JOGL_Wiki

hello yombo,

its good for debugging. It basically checks after every call if an error code has been set by opengl and throws an exception. The performance penalty is usually not noticeable.

Technically it adds an additional layer between your application and the driver. You usually want to set this once e.g. in init. There is also TraceGL whch prints all calls to a stream... we will add more layers in future.


we prepared an automatic refactoring script which does around 90% of the refactoring work to port a jogl1.1.1 application to the latest JOGL 2 revision. It is a bit experimental (well even the jackpot compiler is experimental) and unfinished but might be already of use.

we have an wiki, bugzilla etc for all GlueGen based project on http://jogamp.org/ but we are currently switching servers. The website should be online by the end of this week again.

in the meantime you could take a look at my old blog entry about profiles (its a bit outdated, the GL4 profile and a few other things are missing...):
http://michael-bien.com/mbien/entry/jogl_2_opengl_profiles_explained

also newt should be more stable now but it still isn't finished yet.
regards,
michael