Haha, nearly forgot to x-post: LWJGL now appears to work just fine and dandy on the Mac, and we’re not making any more API changes (fingers crossed). Get porting!
Cas 
Well the port is already done and in CVS.
I’m excited that LWJGL now works on a Mac, I would like to keep the port well maintained as a viable option for Xith3D.
However, it appears the port was done on an older version of LWJGL - the “Window” class appears to have since been removed from LWJGL. Can you please point me in the direction of some information regarding this change and how best to upgrade the code?
Thanks,
Will.
The old org.lwjgl.Display and org.lwjgl.opengl.Window classes are now merged into one class, org.lwjgl.opengl.Display.
Initialisation and usage is trivially simple now.
One particular point of interest: if you manufacture your own DisplayModes now using the now-public constructor, you cannot get a fullscreen display. However if you use the DisplayMode.getDisplayModes() method the modes returned are usable for both windowed and fullscreen mode.
Cas
I’ve hit one snag:
William-Denniss-Computer:~/proj/xith3d williamdenniss$ java -cp classes/:third-party/lwjgl/lwjgl.jar:third-party/vecmath/vecmath.jar com.xith3d.render.lwjgl.test.HelloXh3D
java.lang.IllegalArgumentException: Number of remaining buffer elements is 0, must be at least 16
at org.lwjgl.BufferChecks.checkBufferSize(BufferChecks.java:154)
at org.lwjgl.BufferChecks.checkBuffer(BufferChecks.java:174)
at org.lwjgl.opengl.GL11.glLoadMatrix(GL11.java:1102)
at com.xith3d.render.lwjgl.CanvasPeerImpl.setGLViewMatrix(CanvasPeerImpl.java:512)
at com.xith3d.render.lwjgl.CanvasPeerImpl.setView(CanvasPeerImpl.java:487)
at com.xith3d.render.lwjgl.CanvasPeerImpl.display(CanvasPeerImpl.java:917)
at com.xith3d.render.lwjgl.CanvasPeerImpl.render(CanvasPeerImpl.java:1055)
at com.xith3d.scenegraph.View.renderOnce(View.java:591)
at com.xith3d.scenegraph.View.renderOnce(View.java:524)
at com.xith3d.render.lwjgl.test.HelloXith3D.<init>(HelloXith3D.java:145)
at com.xith3d.render.lwjgl.test.HelloXith3D.main(HelloXith3D.java:82)
The code in question is:
// sets the OpenGL viewm atrix
floatBuffer4x4.put(viewTrans);
GL11.glLoadMatrix(floatBuffer4x4);
View trans is: float[] viewTrans = new float[16];
floatBuffer4x4 is: private FloatBuffer floatBuffer4x4 = BufferUtils.createFloatBuffer(16);
And at the time of the crash, that array holds this data:
1.0 0.0 0.0 0.0 0.0 1.0 0.0 0.0 0.0 0.0 1.0 0.0 0.0 0.0 -2.0 1.0
Everything looks normal to me and it used to work.
Any ideas?
Will.
Try rewinding the buffer.
Thanks.
I wounder why it worked previously? Perhaps it didn’t :-/
Am I correct in thinking clear() (or rewind()?) should be called before the "floatBuffer4x4.put(viewTrans); " line?
Will.
yep - either one. rewind is fine if you’re going to overwrite all values anyway, but a clear is probably safer.
.put continues from the position - there are getters and setters that take a startindex too though.
Apologies - there are a few issues like that in there. We caught a few of them when JCD used it for a while, but as no one else was interested in it at the time, much of the implementation remains untested. :-[
All I can really say is that the bits I was able to test, that were simple enough for my Savage chipset to render, work fine. Bit sad, really!
In particular, I’m concerned that many of the different code paths are untouched. If you want to promote LWJGL-Xith3D as a first-class citizen of the Xith3D project, we’ll need people with diverse chipsets trying it.
[quote]Am I correct in thinking clear() (or rewind()?) should be called before the "floatBuffer4x4.put(viewTrans); " line?
[/quote]
If viewTrans contains all the needed data, either would be fine. If some of the data should be left in the buffer, rewind is what you want.
Crash course in NIO Buffers:
If you’re filling a buffer with new data, get to the end of that data input and now wish something to use it, call flip(). That’ll go back to the beginning, and automatically set the size of the buffer to the amount of data you just added.
If you’ve got a buffer containing n elements that you’re about to fill with n new elements, call rewind. This will go back to the beginning but leave the size fixed.
If you’re just about to add or you’ve just added 3 elements of a 4-element vector (the fourth already being present), call rewind.
If you’ve got a data with old data in it that isn’t relevant any more, call clear to start afresh. Resets any start position or limit.
Call mark when you’re at a position that you wish to return to - call reset to return there.
If none of the above make sense in any particular situation, use position(int) and limit(int) instead to directly manipulate these values.
Buffers hold a lot of state, so using them in a multi-threaded context is highly inadvisable! ;D
Easy enough… get all the tests up and running on a page of JNLP links and we can all go through them one by one.
Cas
[quote]Apologies - there are a few issues like that in there. We caught a few of them when JCD used it for a while, but as no one else was interested in it at the time, much of the implementation remains untested. :-[
[/quote]
The LWJGL port has been a bit neglected. I am very thankful for your effort (your name has been added to the Credits incidently, better late than never).
I too have been adding features to the LWJGL renderer without testing them (e.g. Background/Foreground).
For me, as there was no OS X port, it wasn’t of great interest to me at first. Now with the full complement of OS’s supported by LWJGL, I am very interested.
I’m about to commit my changes which bring the port up to date with the latest LWJGL version. It is working - but visually it looks slightly strange on my Mac. Hopefully we can iron out these bugs.
Will.
I’ve commited in my changes and the lwjgl.jar version I’m using (from the OSX release).
Try running any of the demos and you should see what I mean when I say it just doesn’t look right. I’ll get some screenshots up soon.
Thanks for the NIO advise.
Will.
[quote]I’ve commited in my changes and the lwjgl.jar version I’m using (from the OSX release).
Try running any of the demos and you should see what I mean when I say it just doesn’t look right. I’ll get some screenshots up soon.
Thanks for the NIO advise.
Will.
[/quote]
I just checked out the latest CVS and I don’t see the mac version in the third-party folder ???
His site is down 
I’ll check later i guess.
probably just stale DNS: http://puppygames.net/forums/viewtopic.php?t=821
I have posted the current problem I am having here by the way: http://lwjgl.org/forum/viewtopic.php?t=817
Will.
The previous problem has been solved.
Wow - I am very impressed. I just switched renderers for my game and it worked perfectly (after I found and fixed a few more buffers which needed rewinding…). Visually, I could not tell the difference. Speed wise the JOGL renderer was faster, however my two sample scenes were slightly different (randomly generated levels), and of course the LWJGL renderer has yet to really be optimised.
One line of code changed:
import com.xith3d.render.jogl.*;
to
import com.xith3d.render.lwjgl.*;
And I’m using LWJGL! Very cool.
OK, I’m not being totally honest, I had to add a “Display.update()” after my renderOnce() - but this can be fixed. I also had to disable my input system – time to implement an input abstration layer for me.
My game is a pretty good test of the renderer, I have a lot of polygons, a Foreground HUD, a Background SkyBox and lighting. I’m going to let my users chose what renderer they use.
In the not too distant future, with an input abstraction layer, the two API’s should be fully interchangable.
Thank you David for your clever design, we now have a proof of concept that the abstraction works. Thanks Charlie for your initial port of the LWJGL renderer, bar a few tweaks and bug fixes, most of the work was already done
I’ll post a screen shot tomorrow.
Cheers,
Will.
nice ;D
great!
This should also make a great benchmark between jogl & lwjgl, so that we may locate any potential bottlenecks in both implementations.
Nice one Will!
Xith & LWJGL really do make a good match.
Kev