LWJGL renderer

[princec]

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

[William Denniss]

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.

[princec]

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

Games published by our own members! Check 'em out!

[William Denniss]

I've hit one snag:

1   2   3   4   5   6   7   8   9   10   11   12   13

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:

1   2   3

// 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	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.

[tom]

Try rewinding the buffer.

[William Denniss]

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.

[Matzon]

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.

[cfmdobbie]

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.

[cfmdobbie]

Am I correct in thinking clear() (or rewind()?) should be called before the "floatBuffer4x4.put(viewTrans); " line?

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!

[princec]

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

Games published by our own members! Check 'em out!

[William Denniss]

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.

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.

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.

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.

[William Denniss]

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.

[itistoday]

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.

I just checked out the latest CVS and I don't see the mac version in the third-party folder  

[William Denniss]

I just checked out the latest CVS and I don't see the mac version in the third-party folder  

You will need to download it yourself for now:  http://lwjgl.org/forum/viewtopic.php?t=787

Will.

[itistoday]

You will need to download it yourself for now:  http://lwjgl.org/forum/viewtopic.php?t=787

Will.

His site is down  I'll check later i guess.

[William Denniss]

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.

[William Denniss]

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:

1	import com.xith3d.render.jogl.*;

to

1	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.

[aNt]

nice  

[Matzon]

great!
This should also make a great benchmark between jogl & lwjgl, so that we may locate any potential bottlenecks in both implementations.

[kevglass]

Nice one Will!

Xith & LWJGL really do make a good match.

Kev

[cfmdobbie]

Fantastic news!

[William Denniss]

Thanks for the words of encouragement

An update:

Display.update() no longer needs to be called manually.

I have finished the keyboard part of my generic (read: not just for xith3d) input abstraction layer and I'm quite happy with it.  Next I will add Mouse support, then javadoc everything and release.  Changing between input API's is as simple as changing a single line of code (and you get your choice of LWJGL polling or buffering).  Stay tuned.

We also need to add a bunch of RenderOptions to tweak the verious LWJGL settings.  I think LWJGL specific ones should have "LWJGL_" prepended to them, likewise with JOGL ones (should we add any).

Will.

[William Denniss]

The input abstraction layer I was talking about has now been released.

I am waiting for community feedback on the proposal to convert Xith3D's demos to use it instead of being tied to AWT.  Hopefully this will go ahead which will mean we can easily test the LWJGL renderer with all the existing demos.

Once this is out of the way, we will need to do some profiling and work out where the bottlenecks are.

Mouse input with LWJGL is vastly superior for games when compared to AWT by the way, especially for exclusive mouse mode.

Will.

[cascade]

One question:

Is the lwjgl rendering independent of the jogl stuff ? Because I am still looking for getting multiple views up and running and at the moment I am suspecting jogl to be the source of an HotSpot error making this impossible.

Does using lwjgl in this case make sense ?

[tom]

Not only is it indepentant of jogl, it is independamt of awt. Lwjgl uses it's own native window, and you can only have one "view".

[William Denniss]

The LWJGL renderer is working very well for me.  Xith3D is providing graphics abstrcation, HIAL is providing the input abstraction.

In my code I have a simple statement:

1   2   3   4   5   6

Xith3DFrame xith3d = null;             if (renderer.equals("LWJGL")) {                 xith3d = new Xith3DFrameLWJGL(config);             } else if (renderer.equals("JOGL")) {                 xith3d = new Xith3DFrameJOGL(config);             }

The (abstract) Xith3DFrame is just your basic Xith3d frame which just sets up the canvas and view.  The two implementations of the frame simply add some boilerplate renderer-specific code.

My users can now chose which render to use.



Will.

[blahblahblahh]

The thing I *really* like about this is that we can start doing side-by-side comparisons between AWT, JOGL, LWJGL, and JInput without huge amounts of pain and wondering how incredibly lopsided it all is.

Sure, they won't be fair to start off with (pandering to only the things that Xith uses/does), but the ability to render the same scene identically with the different setups with just tiny changes makes tech-comparison articles suddenly a million times more feasible.

Could help a lot with checking graphics driver bugs too...