Catch 22 for jogl

OpenGL Development JOGL Development
#61

It won’t stay only in the hands of volunteers but rather in a community composed of both volunteers and paid engineers because it is in the interest of some corporations that have invested some time in building some frameworks on JOGL. It is too early to make any public announcement, I need some confirmations and some authorizations but I have excellent reasons to keep confident in JOGL. This library won’t die; if the project of unification succeeds, the OpenGL-ES binding (and maybe some other features) of JOGL will be used; otherwise, a set of organizations will “take care of the baby” even though the exact kind of help is not yet clearly defined. Therefore, why going on speaking about its death? This is only a supposition. I don’t make any supposition about the future of LWJGL.

We can still unify what is unifiable and keep 2 separate OpenGL bindings, it is an option. That’s why I spoke about JOCL.

#62

[quote=“gouessej,post:61,topic:34594”]
maybe gouessej has a point here, if the jogl dev’s are willing for the merge to go ahead (just looks like LWJGL dev’s atm), we can start by sharing parts that are missing from each binding.

e.g. theres no solid solution for sound when using JOGL atm, JOAL is just buggy as hell and development is dead, LWJGL on the other hand has a solid field tested sound solution with OpenALSoft which can be separated in a way it’d be usable by ppl using JOGL. Other examples include OpenGL ES which is missing in LWJGL but JOGL already has it. LWJGL’s smooth AppletLoader or OpenCL with JOGL, NEWT is a similar concept to LWJGL’s native Display again could share code bases, Native Input systems for Keyboard and Mouse, etc.

all are parts that can be started on pretty quickly and shared.

But again the main thing here is both parties (LWJGL and JOGL) must be willing to commit to a community effort.

#63

[quote=“kapta,post:62,topic:34594”]
Paul Lamb has made a great job, “3D Sound System” works fine even with Java Sound. JOAL is no more maintained but on my view, the absence of OpenAL is not blocking for a gaming project even though the simulation of some advanced features with Java Sound is not completely satisfying.

[quote=“kapta,post:62,topic:34594”]
The community effort of JOGL does not depend on me as I have a pretty minor role, I will spare a bit of my time to fix some bugs in JOGL 2 if needed but I’m not a main contributor of JOGL, the decision concerning this library has to be made by Sven, Bienator and some legitimate people. We have to split the job into smaller tasks as you suggest. I don’t know if it leads to a single unified API but it would be so fine to avoid creating 6 Java bindings of OpenCL and a bad clone of native systems in JOGL. However, where is your bug tracker? I would like to have a clear visibility on bugs of LWJGL and I will never use and promote any API that underestimates the support of Linux.

Another problem concerns the support of controllers under Linux. This problem has been solved in SFML (I don’t know how) but not in JInput.

Finally, if we avoid duplicating efforts on some libraries, we will have more time to invest in some other projects. Spasi spoke about WebGL, I would like to have a wrapper of Android OpenGL-ES binding to use JOGL on Android, OpenGL-ES is available on PS3 too.

Edit.: OpenCL4Java and JOCL (of Apache, not JOGL of Bienator) are going to be merged.

#64

legitimate bugs are usually crushed and killed pretty quickly usually within a few days of being report on the forums. The lwjgl forums serve as the main hub for bug reports or even are sometimes dealt with in real time via the lwjgl irc channel.

I’d also like to point out that I am also a Linux users and have been for using it as my main OS for a number of years, LWJGL support and compatibility has been nothing short of fantastic for this platform. Many of the core decisions regarding LWJGL’s architecture have been taken to accommodate Linux. Also a number of core LWJGL developers develop on linux or have access to it. LWJGL was also the first binding to support 64 bit linux, so I’d rest assured that Linux is most definitely treated as a first class supported platform.

You always seem to imply that somehow LWJGL is lacking on linux which IMO is definitely not the case. As I remember the last time you had a tantrum about lwjgl not working on linux (which lasted a few months) you were using a botched example which was resulting in you getting a blank screen and had nothing to do with LWJGL and the other issues with regards to lines on your desktop has already been dealt with above by princec.

So really I wouldn’t worry about lack of linux support.

This IMO is a great idea, I’d love to see where this goes. Even if you we don’t get direct access to WebGL via java, i reckon java plugin2’s java -> javascript bridge is good enough to still create something nice and take advantage of java’s raw horsepower. Direct Acess however would be an awesome development then to use the java -> javascript -> webgl bridge.

#65

Sorry I have just tested LWJGL 2.2.1 (FullScreenWindowedTest) and I have still the straight lines on my task bar as you can see in the screen capture (the enclosed file). This is a very old bug (at least 3 years?). Unlike princec, I think this bug comes from the way LWJGL modifies the display mode when exiting, I can verify my hypothesis when I have a few hours to spare, ok?

#66

I have a suggestion concerning the project of unification. Maybe we could satisfy everyone by following these “ideas”:

  • we keep OpenALSoft for the sound, we forget JOAL that is no more maintained
  • we keep the whole native systems of LWJGL for the display (but I try to fix the bug I reported if possible), mouse, keyboard (but we improve the support of controllers under Linux by looking at SFML if possible) and we keep only the part of Newt that may be useful with OpenGL-ES, we throw the rest of Newt…
  • we keep the both OpenGL bindings by using a kind of profile (GL.setBinding(“LWJGL”) or GL.setBinding(“JOGL”)) in order to please everyone and to allow OpenGL-ES access until people of the both teams find a solution to keep only one of them but we expose a common LWJGL-like public API
  • maybe we keep the applet loader of LWJGL if it is really more reliable than its JOGL equivalent
  • we package the project so that people who only needs an OpenGL binding or an OpenAL binding can use it separately even though removing some classes from a JAR is trivial
  • we merge JOCL, OpenCL4Java and Java Bindings for OpenCL because having 3 bindings of OpenCL (instead a single reliable and cross-platform one) is a waste of energy
  • the Android OpenGL-ES API is very close to the JSR 239 (Java bindings to the OpenGL ES native 3D graphics library) that is actually in JOGL 2, it is only a small “derivation”, we should do something to allow the unified library to work with Android too
  • we provide a new name for this unified API, we don’t keep any previous names (maybe the name should not contain the word “game” in order to target not only gaming applications)

What do you think about it?

#67

This is an exciting discussion! There is a set of C# bindings called “The Open Toolkit Library”, or “openTK” (http://www.opentk.com/) which wraps openGL, openAL, and openCL. Maybe a similar name like JOTK (for Java Open Toolkit), or JOB (for Java Open Bindings)?

-sj

#68

JOTK is a good catch, why not? Lol I remind you that the OpenGL binding of OpenTK is twice slower than JOGL ;D Long life to Java :stuck_out_tongue:

#69

or JogAmp.org Java Graphics Audio Media Processing bindings

btw builds are now online (+junit and javadoc):
http://michael-bien.com/hudson/
(url will change)

I hope to join the discussion the next days… no time…

#70

No no no! Cutesy acronyms like that make a project impossible to find with a search engine. If you Google for java opengl job you will get tonnes of recruitment sites. Unique is good.

#71

Haha, something like … LWJGL :wink: Except maybe LWJML is more like it (M for Media or Multimedia).

Need to get something straight though: we can implement an instance based binding on top of a static binding, but not the other way around. Right now, today, we can probably provide a mostly compatible JOGL interface that called down to LWJGL.

Cas :slight_smile:

#72

As for acronyms, I’d like one that can be sounded out easily. JOGL sounds like ‘joggle’, LWJGL makes a sound like ‘lowjiggle’ which I’m not a fan of (maybe there’s an official pronunciation that’s different?). JOTK and JOGAMP are okay.

How about jAMP (java Audo Media Processing). This is of course assuming that LWJGL won’t just subsume the functionality of JOGL and keep its name. Although I’m not in a position to truly argue against that, I think a project for a merge of this scope should have a new name to start anew and be fair to both sides (sort of give up the “bad blood” that may have developed between the projects).

#73

[quote=“lhkbob,post:72,topic:34594”]
I agree with you, that is why I suggested a change of name.

princec, kapta, what returns the method org.lwjgl.opengl.DisplayMode.getBitsPerPixel() when the X server pretends to support multiple depths at the same time (see java.awt.DisplayMode.BIT_DEPTH_MULTI)? What returns getFrequency() when the frequency is unknown (see java.awt.REFRESH_RATE_UNKNOWN)? When a Java application sets back the correct display mode and frequency on my machine, the straight lines disappear. I will give another look at the source code Saturday.

#74

“Audio Media Processing” to me sounds like something for processing media of the audio variety, especially given the ‘AMP’ acronym.

Maybe jMP (java Media Processing) would work.

#75
  1. Direct-J
  2. J-Extreme
    :slight_smile:
#76

Java Unified Media Processing - JUMP!

Kev

#77

Yeah a new name would be better. Though both names have their long history and while I’m LWJGL user, I admire the JOGL name sounds better and more official. I’m very used to LWJGL name, but it bothers me a little that there is Game keyword in the name. LWJGL is great for non-gaming applications.

One thing is pretty limited though, the singleton behaviour of Display and other classes. This was not problem, usually you want just one screen, but with addition of setParent method it’s pretty limiting, also what about multiple screens?

#78

Maybe we should wait to see what Bienator and other JOGL devs have to say before discussing potential features and library names (this thread isn’t the best place to do it anyway). I purposely left out any suggestions from my replies on what I think should go into the merged library, I’d much rather see discussions start from a clean slate, assuming of course the JOGL party is interested (reminder: their first reply sounded negative :P). As I mentioned already the technical problems should pose no threat, but we really need this effort to be driven by what the users of both libraries want and need. The only assumption I’m making at this point is that it’s in everyone’s best interest for this merge to happen.

So, I’d like to hear more arguments in favor or against this assumption.

#79

[quote=“Spasi,post:78,topic:34594”]
I wonder how such a unified library could both give an access to OpenGL-ES through JOGL 2 and give an access to plain OpenGL through LWJGL if its users want to keep it. If we don’t want to duplicate the efforts of maintenance on the OpenGL binding, we cannot keep 2 implementations of it, we will have to choose one of them.

#80

The generator can be extended to generate both APIs. Either by creating native methods for both APIs, or to create JOGL API as wrapper of lower level LWJGL API. The inline ability of HotSpot should completely eliminate any additional overhead when using this approach.