LWJGL renderer

Fantastic news! :smiley:

Thanks for the words of encouragement :smiley:

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.

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.

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 ?

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

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:


            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.

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…