Suggestions and questions

[Light232]

Why cant we program a browser plugin for LWJGL to act as an applet(so its not dependent on java.applet)?
(Ive done this on an OpenGL binding Im working on)
Also..is there a reason to use java.nio.ByteBuffer?
Why is the newer LWJGL release bound to direct bytebuffers?
The OpenGL binding im currently programming has its own ByteBuffer(direct and on the gc managed heap), and i have not had a drastic performance hit.(though mine copies from the java managed array to the native array differently)

Also the design of LWJGL is not one for an OO language that Java is(even though the underlying API(OpenGL) is a statemachine type API) is there a reason for this?

Could LWJGL provide an internal fallback for GL features such as VBOs(on platforms such as windows this would help game developers heavily).
Im currently working on something of the sort.

[Matzon]

First of all, you need to understand that LWJGL is an enabling technology. We set out to create a lightweight game library centered around opengl and openal.

Why cant we program a browser plugin for LWJGL to act as an applet(so its not dependent on java.applet)?
(Ive done this on an OpenGL binding Im working on)

I am not sure why depending on java.applet is an issue? - but generally the AppletLoader has been good enough for most people. http://lwjgl.org/applet

Also..is there a reason to use java.nio.ByteBuffer?

We need this to transfer data to and from the JNI and Java VM layer. It is the fastest way.

Why is the newer LWJGL release bound to direct bytebuffers?

We always used direct buffers - we just removed the wrapping layer to force people to not use non-direct buffers, due to performance reasons.

The OpenGL binding im currently programming has its own ByteBuffer(direct and on the gc managed heap), and i have not had a drastic performance hit.(though mine copies from the java managed array to the native array differently)

Are you implying that we should manage all data for an application?

Also the design of LWJGL is not one for an OO language that Java is(even though the underlying API(OpenGL) is a statemachine type API) is there a reason for this?

OpenGL and OpenAL is C - we carry this through so that a great deal of existing code will work with few changes.
We have no plans to create an OO api since it would only make things slower.
You might want to look into a Scenegraph like ardor, jme or xith.

Could LWJGL provide an internal fallback for GL features such as VBOs(on platforms such as windows this would help game developers heavily).
Im currently working on something of the sort.

ehm, if you require VBOs, then you use them ... there is nothing to fallback on ...

[Light232]

I am not sure why depending on java.applet is an issue? - but generally the AppletLoader has been good enough for most people. http://lwjgl.org/applet

Because as I assume your aware of, the native toolkit creates multiple threads/statically links native/java methods for the awt component peers which manage messaging/creation..and if i was a game developer i could have those resources available to me.

We need this to transfer data to and from the JNI and Java VM layer. It is the fastest way.

Your incorrect.

We always used direct buffers - we just removed the wrapping layer to force people to not use non-direct buffers, due to performance reasons.

There is not that big a performance penalty since JNI1.6ish?(remember you have to use the new functions!)

Are you implying that we should manage all data for an application?

No..? I was simply stating what I had done which was not dependent on the nio's bytebuffer

OpenGL and OpenAL is C - we carry this through so that a great deal of existing code will work with few changes.
We have no plans to create an OO api since it would only make things slower.
You might want to look into a Scenegraph like ardor, jme or xith.

OO is not necessarily always slow.

ehm, if you require VBOs, then you use them ... there is nothing to fallback on ...

VBOs appeared in OpenGL 1.5
If one has windows installed and is relying on software implementation of Microsoft(who stopped their affiliation with SGI since..90ish?) then the opengl implementation is 1.1.

[kappa]

I am not sure why depending on java.applet is an issue? - but generally the AppletLoader has been good enough for most people. http://lwjgl.org/applet

Because as I assume your aware of, the native toolkit creates multiple threads/statically links native/java methods for the awt component peers which manage messaging/creation..and if i was a game developer i could have those resources available to me.

hmm, signed applets can pretty much do anything a normal standalone java application can do.

[Matzon]

cutting quote hell...

1: You cannot integrate into a browser without a plugin mechanism - we rely on the existing java plugin.
2: I am not aware of a faster way of copying data, than using direct ByteBuffers. If there is such a way, please point to it. (keep in mind that any sun mechanism isn't usable, and may already be used by the ByteBuffers themselves
3: We support 1.4 - 1.6 only is not an option.
4: no comment
5: OO on top of an existing function oriented API *is* slower.
6: We do not control VBOs in any way - so there is nothing we can do to fallback. We more or less try to be transparent to OpenGL - so this sounds like a job for whoever is using LWJGL.

[Light232]

cutting quote hell...

1: You cannot integrate into a browser without a plugin mechanism - we rely on the existing java plugin.
2: I am not aware of a faster way of copying data, than using direct ByteBuffers. If there is such a way, please point to it. (keep in mind that any sun mechanism isn't usable, and may already be used by the ByteBuffers themselves
3: We support 1.4 - 1.6 only is not an option.
4: no comment
5: OO on top of an existing function oriented API *is* slower.
6: We do not control VBOs in any way - so there is nothing we can do to fallback. We more or less try to be transparent to OpenGL - so this sounds like a job for whoever is using LWJGL.

1: And what was my original suggestion?
2: There is not a faster method, however there is one that comes close.
3: My fault, it was added to JNI 1.2
4: Alright
5: OO is not necessarily always slow.
6: It was merely a suggestion, but if you would like to maintain the transparency then its understandable. If I were to develop a game and I was given a choice between JOGL or LWJGL(with the fallback mechanism i suggested) i would be in favor of LWJGL

[princec]

WRT a browser plugin with LWJGL and a JVM - go for it but the existing integration as of JDK6_u10 is probably as good as it's going to get. If it's about a deployment size issue then unfortunately the license of the JDK means you'd have to ship the whole AWT anyway. If it's about reliability then... 6u10 is as reliable as need be and even then, previous versions are reasonably if not absolutely reliable. If it's about simplicity then... Display.setParent() is already very simple. All in all, feel free to develop such a plugin, but it is IMHO not really required any more. On the other hand, making a tiny JVM+LWJGL+some custom plugin against OpenJDK would be of interest to some.

Direct ByteBuffers are indeed the absolute fastest way to get data to OpenGL and in fact this is precisely why DBBs were invented. LWJGL is all about direct performance rather than convenience. Make your own wrapping/unwrapping if necessary; but more sensibly, just use DBBs - they are no more nor less convenient to use in general than array-backed buffers. And besides - you can only use DBBs with mapped VBOs and certain older proprietry extensions.

If you want an OO API on top of OpenGL, you need to write one. OpenGL is simple imperative state machine API, and our remit was simply to expose that - we did at one point have a GL interface class so that LWJGL looked a bit like JOGL (indeed, you can implement JOGL in terms of LWJGL, but not the other way around). It is kind of pointless though. The static API as it is looks very nice indeed when combined with static imports from Java 5 onwards. But if you want to make an OOP wrapper on top - feel free but bear in mind it's a poor mapping from OOP to OpenGL's thread-local state machine. But our take on it is: we simply expose the bindings, it's up to you how you then put them into a framework or application.

The same reasoning is behind whether you support VBOs or not - it is the application developer's job to query capabilities of the driver and use features that they wish to use. We simply provide a safe failure mechanism (NPE calling non-existent methods) whereas in C land you'd get a native crash.

Cas

[Light232]

WRT a browser plugin with LWJGL and a JVM - go for it but the existing integration as of JDK6_u10 is probably as good as it's going to get. If it's about a deployment size issue then unfortunately the license of the JDK means you'd have to ship the whole AWT anyway. If it's about reliability then... 6u10 is as reliable as need be and even then, previous versions are reasonably if not absolutely reliable. If it's about simplicity then... Display.setParent() is already very simple. All in all, feel free to develop such a plugin, but it is IMHO not really required any more. On the other hand, making a tiny JVM+LWJGL+some custom plugin against OpenJDK would be of interest to some.

Direct ByteBuffers are indeed the absolute fastest way to get data to OpenGL and in fact this is precisely why DBBs were invented. LWJGL is all about direct performance rather than convenience. Make your own wrapping/unwrapping if necessary; but more sensibly, just use DBBs - they are no more nor less convenient to use in general than array-backed buffers. And besides - you can only use DBBs with mapped VBOs and certain older proprietry extensions.

If you want an OO API on top of OpenGL, you need to write one. OpenGL is simple imperative state machine API, and our remit was simply to expose that - we did at one point have a GL interface class so that LWJGL looked a bit like JOGL (indeed, you can implement JOGL in terms of LWJGL, but not the other way around). It is kind of pointless though. The static API as it is looks very nice indeed when combined with static imports from Java 5 onwards. But if you want to make an OOP wrapper on top - feel free but bear in mind it's a poor mapping from OOP to OpenGL's thread-local state machine. But our take on it is: we simply expose the bindings, it's up to you how you then put them into a framework or application.

The same reasoning is behind whether you support VBOs or not - it is the application developer's job to query capabilities of the driver and use features that they wish to use. We simply provide a safe failure mechanism (NPE calling non-existent methods) whereas in C land you'd get a native crash.

Cas

Some benchmarks:
Using the PJSDK(the sdk im currently working on for Java):
Creating a direct copy of a GC managed array(19583443 bytes) took: 8ms

NativeMemory.allocCopy(buff, 0, buff.length);

Allocating a direct array(19583443 bytes) and copying from a gc managed array took: 7ms

int nm = NativeMemory.allocate(buff.length, 0);
        NativeMemory.setBytes(nm, buff, 0, buff.length);

1ms difference? not much

With the first solution i could easily modify the gc managed array, and just create a copy of it
With the second solution(what your saying is alot faster), if i wanted to modify it there would be that overhead for linking the native mutators/accessors, then there would be the actual performance of JNI etc.

So what would I go with if i was given a choice? the first solution of course.

Why would you need to program up a VM for java if you wanted to program an applet plugin..?

It was merely a suggestion, but if you would like to maintain the transparency then its understandable. If I were to develop a game and I was given a choice between JOGL or LWJGL(with the fallback mechanism i suggested) i would be in favor of LWJGL