Should we stop supporting JOGL in favor of JOGL-JSR231?

Engines, Libraries and Tools Xith3D Forums
#1

Finally, thanks to c_lilian, we have now JOGL-JSR231 renderer. Even very first tests show that it is much more stable than really outdated version of JOGL that was in use by current Xith3D JOGL renderer, and I believe that its stability will improve.

For me, it is not a question if I will continue to support JOGL version or not - I already switched all my codebase to JOGL-JSR-231 and I will not make any changes or fixes in JOGL renderer since now.

For me the major question is if we should keep JOGL sources in CVS [having in mind that very very soon they will become outdated and most probably even would not compile in few weeks], or we should simply remove them.

Option 3 (“No”) provided for those who would like to pick up JOGL renderer (if any) and continue supporting it. I would ask you that if you answer “No”, please comment on this thread.

Yuri

#2

If the changes planned to Xith would break compilation of JOGL 1.1, then I’d drop this renderer to avoid confusion for newcomers.

Lilian

#3

I agree, stop supporting it and drop it. JOGL isn’t being maintained itself so I can’t see why we should either.

Will.

#4

So, decided to be dropped.

Yuri

#5

And we keep the com.xith3d.render.jsr231 package name?

#6

we could simply rename it to

com.xith3d.render.jogl

::slight_smile:
I think, this could increase porting speed very much (even if this is actually only one import statement)

mmh - just one thought, that came across my mind - what about this multi-pass rendering thingi - I believe it worked with setting stuff in the jogl renderer directly … this could lead to incompabilities - or is this already implemented in a clear way?

#7

I think we should keep jsr231 package.

Yuri

#8

Hi, here’s a repost of my question on the performance tuning thread :

I’m investigating this issue right now, but if the origin really comes from NIO buffers fragmentation, we’ll have to sort this out in a better way than my first "naive’ port to jsr231.

Another origin would be a kind of buffer retention I’m unaware of (like : is there something special to do to release render Bins once there corresponding Nodes have been removed from the scene graph, or is it taken care of automatically ?)

Lilian :slight_smile:

#9

I would at least rename th package to something meaningful. There plenty of JSRs out there and to use the JSR naming in sourcecode is kind of calling your variables x1 to x65536. :wink: Since the JSR implementation is somewhat official, why not calling it “com.xith3d.render.opengl”?

Slightly offtopic: How difficult would it be to abstract the renderer in a way to be exchangable at runtime, so a user can restart a game with a system property (e.g. -Dxith.renderer=lwjgl), if he rans into problems using the default renderer? I think the easiest (maybe ugliest, too ;)) way would be to refactor both renderers to the same package (different source-folders of course), so one can exchange the “xith-renderer-jogl.jar” with the “xith-renderer-lwjgl.jar”.

#10

there’s hial - I believe it allows you to switch between the different renderers. (never used it though)

#11

Hmm, no because people won’t understand that their code which was using com.xith3d.render.jogl package don’t work with the recent releases of Xith.

I agree.

#12

That’s not it role.
HIAL is used only for input, IIRC. It permits you to use either AWT or LWJGL input system.

#13

[quote]Slightly offtopic: How difficult would it be to abstract the renderer in a way to be exchangable at runtime, so a user can restart a game with a system property (e.g. -Dxith.renderer=lwjgl), if he rans into problems using the default renderer?
[/quote]
as there is no default renderer ( you have to specify it with you import statement ) you can use something like this:


// determinate which renderer to use
String renderer = System.getProperty( "xith.renderer", "lwjgl" );

// create the render peer
Class renderPeerClass = this.getClass().getClassLoader().loadClass( "com.xith3d.render." + renderer );
RenderPeer rp = (RenderPeer)renderPeerClass.newInstance();

// than go on and create your canvas and stuff

using something like this enables the user to define the renderer like this:

$java -Dxith.renderer=jsr231 YourProgram

i guess it would be good to add a check if the user definied renderername is a valid xith renderer … else this would create ugly exceptions …

( no guarantee that this works as i haven’t tried it … but basically this is one way to do it )

#14

Yeah I’m sure this works.