LWJGL discussion forum officially migrates here today!

[princec]

In the abscence of the only other worthwhile forum about LWJGL, it seems fitting that today be the Grand Opening of the LWJGL forums here!

First up:

think long and hard about the fact that I want to remove int pointers from the entire API.

Implications:
1) All code is broken. Hurrah! Including my own. So I must have a good reason.
2) Performance. Having to unwrap a native buffer will take about 300 nanoseconds on a 1.2GHz machine. Woo, big deal. I've pretty much proved it to myself that this is totally irrelevant even in the most complex of games. Brian seems to think we should do it from Java. I'm still pondering. Your thoughts are welcome.
3) Credibility, security, and stability. Yes, int pointers bit my arse a few times by pointing at the wrong places. Well whaddya know ? And we'll never be officially endorsed by anyone in the Java community so long as we've got pointers. And indeed, we'll never have a secure API.

Your time starts... NOW!

Cas

[elias]

I'm all for it. However I'm very strong in favour of the java unpacking. I simply hate the way JNIEnv works so I like to pass *only* native types to native code, not objects.

Other implications:
1. We need to ba able to incorporate offsets in a buffer as a start address without slicing. Interleaved vertex formats are an example of this.
2. The gain in stability and security is not that big after all. You can still easily wander off the end of a buffer.
3. Packing buffers in yet another MemoryBuffer (or something) with a cached address will only make the overhead of a buffer even higher. I might want to sacrifice a little performance for the ability to use java buffers directly and not through a proxy.

- elias

[elias]

... And because this is a fairly important and large part of the LWJGL api, please post your best decision here before implementing it.

- elias

[bedelf]

Short and sweet as follows:

1. small price to pay if you improve LWJGL

2. I really don't know enough to say either way. My project hasn't gotten large enough to run into any problems. All and all I trust you guys will make the right decision in the end.

3. all agreed here, wouldn't suck

[Mojomonkey]

I'm all for the change if you feel strongly enough that it will improve the library. All I ask is for a easing period perhaps just deprecate the affected classes for a release or so?

[cfmdobbie]

Agreed, good idea.

All code broken?  Meh.  In my opinion it's fair game for the entire API to be changed up to the point it goes to 1.0.

Performance - the eternal question of trade-off.  The Slashdot-heads are currently slagging off the Quake tech demo that was posted yesterday - "Runs a non-interactive demo slower than the seven year old full game" etc.  How much will that extra 300ns actually affect the application, in real terms?  Probably not a lot.

[princec]

The 300ns won't affect performance *at* *all*.

Cas

[Mojomonkey]

No, it will effect perfomance by 300ns per call... *wink* *wink*

[princec]

:roll:

Cas

[rgrzywinski]

Kudos to you guys on your release!

As for the whole pointer thing .... I was going to tell you guys that I had *ZERO* performance increase between GL4Java and LWJGL (the former does not use pointers) but you seemed so hell bent on them.  

As you said, after you factor in all of the application code, the pointers are in the noise.  That's the problem with granular testing.  Sure, it make take 300ns to make one call and you extrapolate that to 3000 calls and you think "Uugh!  There goes performance!" but how does that factor into the entire equation?  The bottom line is that you can gain more by coarse tuning than you can by fine tuning.  What if a code change dropped that 3000 calls down to 300 and removed 30ms of latency in the total app?

Thanks for activating this forum here guys!!!  I miss JavaGaming.org.

[PlanetMongo]

Well, whatever you do, hurry up and do it before I commit to learning this stuff.  

[Fuseboy2]

I'll throw in my support too.  What I like about LWJGL is that it's so close to OpenGL that other OpenGL resources (books, tutorials, etc.) are easily adapted to it, which is an enormous advantage.

That being said, there are some elements that aren't very idiomatic to Java.  Removing buffer addresses from the API is a good step.

Two things that I've found myself wanting while learning the API (I'm as new to OpenGL as I am to LWJGL) are type safety for the truly mind-bending number of constants that are passed as 'int', and a light-weight OO wrapper around OpenGL.  Textures, shaders, and other aspects of OpenGL seem obvious candidates for representation as objects (that's how they're referred to in the docs, for instance).

That's a lot to ask for, given the size of the API; I think this would make it so much more explorable, however, if you take my meaning.

Michael

[princec]

That's the kind of thing we want people to write that lives on top of the LWJGL The SPGL (which will be explained a bit more soon) does a lot of this kind of tedious stuff. It's just one solution of many of course.

Cas

[spasi]

1. We need to ba able to incorporate offsets in a buffer as a start address without slicing. Interleaved vertex formats are an example of this.

Agreed. That's a problem and we need a clean solution, that doesn't create any new objects (slicing)...

2. The gain in stability and security is not that big after all. You can still easily wander off the end of a buffer.
3. Packing buffers in yet another MemoryBuffer (or something) with a cached address will only make the overhead of a buffer even higher. I might want to sacrifice a little performance for the ability to use java buffers directly and not through a proxy.

We sure need some kind of wrapping. Bounds checking can be easily added this way, for even higher security. Besides, I believe most of us use some kind of custom object that holds a ByteBuffer and its address. I use such an object all the time and found it really easy to use.

... And because this is a fairly important and large part of the LWJGL api, please post your best decision here before implementing it.

Totally agreed. We should get a preview of the new API, before releasing anything, so that we can comment on it. We should make the desicion together.

About performance: Even if the overhead was higher (which isn't), GL methods that take a pointer as an argument are called only a few times per frame (usually). So I also believe that performance won't be a problem.

A couple of questions:

- How is ByteBuffer createDirectBuffer(int address, int length) going to be used? This takes a pointer (address) no matter what. I believe it should be left as is.

- From native code: (jint) env->GetDirectBufferAddress(buf);
This is what adds the 300ns overhead? This would be called everytime we pass a ByteBuffer to a GL method?

OK, my suggestion is to go for a proxy/wrapper, an object from inside the LWJGL API that wraps a ByteBuffer and caches it's address. Make anything that has to do with pointers "LWJGL private", add some bounds check and then some people may stop whining about pointers. And we need a solution about the offsets (as elias pointed out). Anyway, whatever you decide to do, post it here first!

[spasi]

1) All code is broken. Hurrah! Including my own. So I must have a good reason.

Not a problem. We are used to refactoring our entire project...  :lol: