So, how interested are we in implementing Cg in LWJGL like jogl did? I might even do the work, given enough enthutiasm.
And I'd like 0.8 to be released here soon, too :P EDIT: or is it 0.7? I forget.
- elias
Well - are we going to take the plunge with these buffers then?
And are we going to do it SWT style, where we keep the ints, but make them private, and unwrap them in Java (probably much faster than doing it native - time for a benchmarking test)? Because that means we don't have to bugger around with the C code, and there's a lot of it.
Cas :)
I prefer swt style. Other than that we need to decide on a particular implementation and then comment on it for a few days.
Other than that, I can't find find my favorite solution. But I'm leaning towards using ByteBuffers directly as parameters, which will make sure we get the lowest memory overhead per buffer, but trading in for a slightly higher overhead in C code. And exactly how much is env->GetDirectBufferAddress costing?
What does jogl do?
EDIT: Yes, swt style is contradicting my favorite solution.
- elias
Alternatively, we could find the few solutions we can live with and post them as a poll.
- elias
The C overhead is fixed and unchangeable and unoptimisable whereas Java can probably do a few little tricks and magic away nearly all the overhead. There's only one small problem - we can't get the address of a bytebuffer at all in Java, so we're kinda shafted and have to do it in C.
jogl uses arrays (!)
Cas :)
And another thing while were changing everything - can't we make the context calls static? There's no reason all the gl calls can't be static for example.
- elias
Is static import going to make it into JDK 1.5? If so, definitely - if not, then almost definitely :)
Cas :)
I vote swt style. Much easier and much faster (any benchmark results?). I believe it's the best solution. Could you give me any disadvantages of such an approach? Cause I can't think of any...
What exactly has jogl done with Cg?
static import will be in 1.5 for sure...
If you want swt style, you would have to add a wrapper object to every ByteBuffer, adding memory overhead.
- elias
Quote
If you want swt style, you would have to add a wrapper object to every ByteBuffer, adding memory overhead.
- elias
Well, I already do this. When I started working with LWJGL I had all those buffers and their adresses lying around my code. It got ugly after a while. So I wrapped them in a single object and was happy ever since. And I think it's a negligible overhead, given the convenience it provides. I'm used to it, maybe that's why I find it a nice solution...
Ok, this is what I've been doing:
-------------------------------------
FloatDataBuffer buffer; // "FloatDataBuffer" is my wrapper
FloatBuffer data = buffer.data;
// Fill/Retrieve/Process the FloatBuffer...
gl.vertexPointer(3, GL.FLOAT, 0, buffer.address);
-------------------------------------
This may become:
-------------------------------------
// Same as before
gl.vertexPointer(3, GL.FLOAT, 0, buffer);
-------------------------------------
gl.vertexPointer receives the wrapper and retrieves the (private) cached pointer.
Now I'm a happy (and safe) Java programmer. And I don't have any performance impacts.
Is this what swt does?
Yes. In effect taking your model and bringing it into lwjgl.
- elias
Quote from: "spasi"
What exactly has jogl done with Cg?
JOGL has a full Cg binding (well, minus one method that we haven't gotten around to having the code generator parse yet). Unfortunately during the transfer of code from our private CVS server to the new java.net one the CG binding got ripped out (along with most of our demos) because Sun wanted to be sure about the legal restrictions surrounding those things. So you can't build the Cg binding right now with the Makefile and .cfg files that are available online (unless you create your own .cfg files), but we're working on getting that all back online ASAP.
I'm not sure what Cas meant about JOGL using arrays, if he was implying that it uses only arrays then that is incorrect. For function call arguments, JOGL can use arrays OR Buffers, or even allow both. By default it uses both (for instance, a void* param will be expanded to all possible array types plus a Buffer form on the java side), but you can add an NIOOnly directive to the configuration file to tell it to only generate the Buffer version.
I think a lot of this misconceptions will go away if we could get some JavaDocs online. :) Hopefully soon Ken and I will have owner status on the JGO site so I can actually post stuff.
BTW, has anyone notified SpaceGhost of the migration of the JGO community to this site?
-chris
I imagine JeffK's mentioned it by now... besides I've got to discuss a few things with ChrisM. about JVM licensing. I must get rid of Jet out of the equation eventually because it's a bit of a pain with it only running on Windows.
Still, it doesn't really hurt. Well, it hurts me slightly, 'cause if it gets too bandwidth-hungry I'll be the one paying for it ;)
Cas :)
The Cg runtime interface would be handy, since it would make parameter binding a easier. Currently my ant script just compiles my Cg programs to the OpenGL vertex/fragment profiles, and I load the results in. It does mean, however, that I have to manually relate the parameter indices.
Quote
I imagine JeffK's mentioned it by now... besides I've got to discuss a few things with ChrisM. about JVM licensing. I must get rid of Jet out of the equation eventually because it's a bit of a pain with it only running on Windows.
Cas, this is the second post I've seen where you hint at this. Are you looking to make special license for Alien Flux, or are you looking at doing something for LWJGL at large? I'm dead curious about how this pans out, either way. I'd like nothing more than to see a minimial JVM like you describe.
Paul
LWJGL at large I think. We all want to enable a dead easy and small java platform for our games to run on.
- elias
Sweet. It makes sense to me, as then Sun won't have a million developers like me banging on their door for similar deals. I really hope they bite.
Paul
Quote from: "ckline"For function call arguments, JOGL can use arrays OR Buffers, or even allow both.
Aah.. I first checked out some of the code when Jogl was first made avalible, and it was the presense of several methods where a regular array was used caused me to think (especially after hunting in vain for what is now known as a non-existing class, namely GL) that regular java arrays were the only way. Being able to use buffers as well is a big releif. :)
QuoteI think a lot of this misconceptions will go away if we could get some JavaDocs online.
Well call me picky, but its not really that had to generate javadocs and place them on a sever now, is it? Although I did see mention that the Mind2Machine people have now made some javadocs avalible..
I'm going to get my foot in the door with AF first - more chance of succeeding this way. Then I can develop the technology to deliver an actual product - and after an actual product is developed it's much easier to show somebody a working thing than a vacuous concept ("hey let's shrink the jvm etc etc" vs "Here is a game that has been delivered using the new Game JVM system")
Cas :)
Quote from: "Fuseboy2"The Cg runtime interface would be handy, since it would make parameter binding a easier. Currently my ant script just compiles my Cg programs to the OpenGL vertex/fragment profiles, and I load the results in. It does mean, however, that I have to manually relate the parameter indices.
Do you have an example of this you might want to post. Haven't seen doing this with ant before.
-D
There's no special ant task for this, I'm just using the Cg SDK compiler, accessed via the command-line interface. You'll need to modify the paths to suit, of course.
<target name="cg">
<mkdir dir="${distribution}/data/arb"/>
<!--
<antcall target="compileCgProgram">
<param name="cg.type" value="v"/>
<param name="cg.name" value="vertexTest"/>
</antcall>
-->
<antcall target="compileCgProgram">
<param name="cg.type" value="v"/>
<param name="cg.name" value="basicLightingVertex"/>
</antcall>
</target>
<target name="compileCgProgram">
<exec executable="cgc" dir="data/cg">
<arg line="-profile arb${cg.type}p1 -o ..\..\${distribution}\data\arb\${cg.name}.arb ${cg.name}.cg"/>
</exec>
</target>