Xith and JSR231

[c_lilian]

Hi, is anyone working on the port of the jogl renderer to the forthcoming JSR-231 ? or may be is it already done ?

Lilian

[Amos Wenger]

I don't know, but I would be very interested also.

[William Denniss]

Can you post some more information about JSR231 please and your thoughts on the matter?  Would it be hard to port?

Will.

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

[c_lilian]

jsr231 should be nearly comptible with jogl, except for package names and a generalized use of NIO buffers.

I will do the port, and send you the full source code.

just give me a package name ... com.xith3d.render.jsr231 ?

As there are two API for rendering (the old glEventListener way and a more direct one), I'll test both.

I'm going to need some help in running the test suite, volunteers please !

Lilian

[Amos Wenger]

I'd be pleased to test your port. Thanks for your engagement !

[William Denniss]

I am happy to test your port on OS X.

The package name sounds fine.

Please submit your code for tracking via IssueZilla.  Following the Xith3D coding standards would be appreciated too (essentially these are the standard Sun Java ones with 4 space indents).

Are you able to maintain this renderer going forward?  Not essential but always nice

Thanks!

Will.

[c_lilian]

Long term commitment : I don't know yet, it will depend on the success of the small game I'm currently working on.

I've opted for Xith3D to shorten the development times, and I haven't encountered yet a blocking problem, my productivity is an order of magnitude over my previous "raw open-gl" developments... I must admit I like it !

I try to adapt the engine to my needs when something doesn't suit me (see the "Xith contributions" topic I've started today) and I'm willing to share my updates whenever possible.

I should finish this game in the near future;  after that I'll decide whether continuing (and contributing more) with Xith3D (with a more ambitious project) or to opt for something else...

Lilian

[William Denniss]

All good.  Thanks for participating in the community.  We seem to have quite a few active members currently which is really great.  Good luck with your projects!

Will.

[c_lilian]

Porting done...now testing !

... these new nio buffers that replace int and float arrays are tricky... I seem to have forgotten a rewind() and nothing works... back to re-reading every class I've updated...

I should post the sources (once the whole set of test classes and the q3d demo are working on my computer) in the issue tracker next week.


Lilian


 

[c_lilian]

[EDITED] SOURCE CODE POSTED as Issue 103

Test is finished, everything seems to work fine here,

Some issues or things to enhance/discuss, I think it's better to expose them here instead of the issur tracker :

- The quake demo shows some hickups not present with the old jogl renderer, it's not gc related, but seems to happen when new clusters are loaded. I'll have to investigate to understand why this happens. Any help is welcome ! It might be related to texture loading (see point below) but I'm not sure of this.

- the GeomNioIntData used to send array indexes needs to be updated, the setInts(..) method don't rewind or position() the underlying nio buffer
- Same for GeomNioFloatData, buffers not rewinded.

- There are new features in jsr231, like the shared GLContext, that could be exposed in CanvasPeerImpl to allow for instance texture sharing between multiple Xith canvases. If someone is interested please start a new topic to discuss it.

- I've implemented the port with the GLAutoDrawable/ GLCanvas objects (similar to the jogl version). As it works fine, I won't develop the more direct mode (the one without listener) unless someones sees some real improvements in doing so.

- I've used the ByteBuffer.wrap(byte[])  in the TextureShaderPeer to send texture data to the GL, I'm not sure it's the best way to do it, as Ken Russel said in a jogl thread that it's better to always use direct buffers (or is this a kind of direct buffer ?). Also, It might be better to store directly the texture data (currently a byte[ ] ) into a ByteBuffer to avoid some data transfers when loading a texture.

- Many matrix methods use float arrays to store matrix values, I haven't messed up with that code : I've added some private FloatBuffers to store these values in the appropriate Peers and use them as intermediates between matrices and the GL.

- the Q3d demo starts with a messed initial screen (as rendering the first frame takes several seconds) exposing memory internals, whereas the jogl version starts with a white screen...


Any comments on theses points are welcome !


Lilian

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

[William Denniss]

Hi,

Thanks for this excellent contribution.  I have posted some comments in https://xith3d.dev.java.net/issues/show_bug.cgi?id=103 relating to the JSR231 and JOGL relationship (upon investigation I get the impression we should be replacing the jogl renderer with your port rather than adding a new renderer).

From what I could tell, JSR231 is what JOGL is now, and JOGL as it used to be is deprecated.  Is that correct?

Incidently if anyone is looking for the JSR231 packages, they are here:  https://jogl.dev.java.net/servlets/ProjectDocumentList?folderID=4650&expandFolder=4650&folderID=4649

Cheers,

Will.

[Ken Russell]

From what I could tell, JSR231 is what JOGL is now, and JOGL as it used to be is deprecated.  Is that correct?

This is correct. JOGL has evolved to track the forthcoming Java bindings for OpenGL standard. The old JOGL APIs under the net.java.games.jogl namespace are no longer being maintained. The new implementation is more robust than the JOGL 1.1.1 release and also offers new features such as lower-level control of OpenGL drawables and contexts if it is needed. I would encourage you to replace the JOGL renderer in Xith3D rather than also attempt to maintain the original one.

[William Denniss]

Thanks for the answer Ken, I think we will do exactly that.

Cheers,

Will.

[Yuri Vl. Gushchin]

Hi,

So what is the status of JSR231-based renderer?

Yuri

[c_lilian]

For my part, I've updated it locally (small patches) but I haven't got the time right now to properly prepare and file that version. I will certainly do it at the beginning of march.

Lilian

[Yuri Vl. Gushchin]

Hi again,

Would be great to have a version even unprepared, because of I am going to update my apps that use Xith3D to JSR-231.

So, if you can send me your version, I can also check it out and commit to Xith3D core CVS (I think even unprepared but most recent version would be really OK, so you can save your time also )

Yuri

[c_lilian]

I was sure you were going to ask that

Give me a day or two to diff the files (I have to check if I haven't added specific game code).

Lilian

[Yuri Vl. Gushchin]

Great thanks,

..and.. I just checked the game from JavaPause - it is amazing! Really amazing!

Yuri

[c_lilian]

wait till march... you'll see much much more ...


Lilian

[princec]

What happened to the LWJGL renderer? Is it working? Up-to-date?

Cas

[Amos Wenger]

What happened to the LWJGL renderer? Is it working? Up-to-date?

Cas

Don't know if it's working now, but I know I tested it someday and it didn't work.

[c_lilian]

Haven't tried it yet, but I'd like to give it a try some day (full screen support seems to be better in LWJGL, especially on older JREs).

I've ported Xith to JSR231 because I wanted to use JOGLAppletLauncher with Sun signing. I might try the LWJGL equivalent it in the coming months (with my own cert) to see how it performs (and if it works)

Now, let's go back to upload my Xtih updates...

Lilian

[c_lilian]

Yuri (and others), I've uploaded my JSR231 as an attachment of issue #103 on the issue tracker. feel free to use it !

Lilian

[Yuri Vl. Gushchin]

Thanks,

Checking it out.

I already played with your previous version, and it was working fine, so I will integrate new version into CVS ASAP.

Also I would like to ask other to attend some of conceptual topics I highlighted in other posts, because of they may cause some incompatible changes in future (what I really don't like).

Yuri

[Yuri Vl. Gushchin]

Lilian,

I tested your code and it works pretty well. There is one minor issue with Texture3D, so I will check this in more details. Anyway, I am up to update current CVS version with this renderer.

The question is if we should stop supporting JOGL renderer?

Yuri

[c_lilian]

Texture3D : I don't use it, so I haven't tested it...

About dropping JOGL for JSR231 : This issue has been discussed and it seems like William wanted to do that. I'm not that sure, but for my own needs it's clear that I won't use this unsupported version anymore.


Lilian

[Yuri Vl. Gushchin]

New JSR-231 renderer committed.

Yuri

[William Denniss]

What happened to the LWJGL renderer? Is it working? Up-to-date?

Cas

Yes it is working.  Yes it is relatively up to date.  My personal project supports both (user configurable), something I have found very useful when for some reason one of the API's would just not work on a particular setup.

Cheers,

Will.