Marvin Fröhlich
Xith Lord
Administrator
Guru
 Offline
Posts: 4381
May the 4th, be with you...
|
 |
« on: 09. April 2007, 01:39:39 pm » |
|
I think, it would be best to have something like a scenegraph-API-base project. It would contain these model loader bases, sound- and texture loader bases, as well as OpenGL wrapper-wrappers  , OpenMaLi things, etc... Everything, that any engine should have in common. And we should cooperate with jME guys on it (when we have a certain plan about it). This way any engine could benefit from this work, bugs are cared about by all engine-devs and we would have the highest possible compatiblity between different engines. What do you think? Marvin |
|
|
|
|
Logged
|
|
|
|
|
horati
|
|
« Reply #1 on: 09. April 2007, 02:14:27 pm » |
|
Spectacular idea
|
|
|
|
|
Logged
|
|
|
|
|
kukanani
|
|
« Reply #2 on: 09. April 2007, 03:46:15 pm » |
|
yeah
|
|
|
|
|
Logged
|
xith.setCoolnessLevel(10);
jMe.setCoolnessLevel(0);
xith.rock();
|
|
|
|
khangharoth
|
|
« Reply #3 on: 10. April 2007, 04:26:14 am » |
|
And we should cooperate with jME guys on it (when we have a certain plan about it). This way any engine could benefit from this work, bugs are cared about by all engine-devs and we would have the highest possible compatiblity between different engines.
What do you think?
I think its a very good idea. |
|
|
|
|
Logged
|
|
|
|
|
'n ddrylliog
|
|
« Reply #4 on: 14. April 2007, 05:36:01 pm » |
|
In theory it's a good idea.
Practically I'm still not sure about performance impact of an OpenGL wrapper-wrapper...
And I'm not sure either the jME guys will be willing to collaborate about that. They're half in the commercial world, you know... In the past they privilegied competition over collaboration..
This project should be launched anyway : even if it's just for Xith3D, it's a good idea. +1.
|
|
|
|
|
Logged
|
|
|
|
|
Patheros
|
|
« Reply #5 on: 15. April 2007, 02:46:30 pm » |
|
Practically I'm still not sure about performance impact of an OpenGL wrapper-wrapper...
I agree with Amos on this its going to be another performance impact and I think its going to be more haste than its worth. |
|
|
|
|
Logged
|
"I like my method, what was my method again?" - Jon
|
|
|
Marvin Fröhlich
Xith Lord
Administrator
Guru
Offline
Posts: 4381
May the 4th, be with you...
|
|
« Reply #6 on: 15. April 2007, 03:31:27 pm » |
|
I agree with Amos on this its going to be another performance impact and I think its going to be more haste than its worth.
I know, that it might be a performance impact. It is subject to be tested. But it's definitely worth a whole lot. At the moment, we have very much code duplication to implement JOGL as well as LWJGL. This is very annoying and would be solved through this wrapper-wrapper. So you might see its worth. Marvin |
|
|
|
|
Logged
|
|
|
|
|
Mathias 'cylab' Henze
|
|
« Reply #7 on: 15. April 2007, 08:34:38 pm » |
|
I read in the JOGL forum, that it is technically possible to implement the JSR interface with a LWJGL backend and JOGL itself is just an implementation of the JSR SPI... So the desired wrapper may be already there, it just needs a different backend. Regarding the perfomance overhead: I doubt it will make much of a difference, since the wrapper-methods may most probably be inlined by the jit compiler. Also time critical code is often optimized by displaylists or vbos, which mostly require very little (wrapped) api calls in rendering.
|
|
|
|
|
Logged
|
|
|
|
Marvin Fröhlich
Xith Lord
Administrator
Guru
Offline
Posts: 4381
May the 4th, be with you...
|
|
« Reply #8 on: 15. April 2007, 09:00:19 pm » |
|
I read in the JOGL forum, that it is technically possible to implement the JSR interface with a LWJGL backend and JOGL itself is just an implementation of the JSR SPI... So the desired wrapper may be already there, it just needs a different backend. Regarding the perfomance overhead: I doubt it will make much of a difference, since the wrapper-methods may most probably be inlined by the jit compiler. Also time critical code is often optimized by displaylists or vbos, which mostly require very little (wrapped) api calls in rendering.
Well, as far as I would guess, the jit compile just cannot inline the methods, since they would have to be done through an interface. Or do I understand it wrong? Is there a way to get the compiler to inline interface methods? Is there any documentation about it? Marvin |
|
|
|
|
Logged
|
|
|
|
|
|
|
Mathias 'cylab' Henze
|
|
« Reply #10 on: 16. April 2007, 08:45:28 am » |
|
I can't really say, if the linked article apply for interfaces, but that's something we could test.
Another possibility would be to generate the rendering-package from a sourcebase with preprocessor-macros (e.g. velocity). But there is catch, as always: using a preprocessor breaks the background compilation in eclipse, so you can only generate the two renderers with ant.
|
|
|
|
|
Logged
|
|
|
|
Marvin Fröhlich
Xith Lord
Administrator
Guru
Offline
Posts: 4381
May the 4th, be with you...
|
|
« Reply #11 on: 16. April 2007, 09:10:56 am » |
|
I can't really say, if the linked article apply for interfaces, but that's something we could test.
Another possibility would be to generate the rendering-package from a sourcebase with preprocessor-macros (e.g. velocity). But there is catch, as always: using a preprocessor breaks the background compilation in eclipse, so you can only generate the two renderers with ant.
It's anyway interesting. I started an appropriate thread in the coding forum on java.sun.com. We will see, what they say... Marvin |
|
|
|
|
Logged
|
|
|
|
|
Mathias 'cylab' Henze
|
|
« Reply #12 on: 16. April 2007, 09:46:59 am » |
|
I started an appropriate thread in the coding forum on java.sun.com. We will see, what they say...
Could you provide a link to this thread? Thanks. |
|
|
|
|
Logged
|
|
|
|
|
|
|
'n ddrylliog
|
|
« Reply #14 on: 26. April 2007, 01:19:51 pm » |
|
Should I request the Sourceforge project ?
EDIT : And what should it be named ? (please a funny name, I'm bored with project names like "MDKLFJI"...)
|
|
|
|
« Last Edit: 26. April 2007, 01:21:49 pm by Amos Wenger »
|
Logged
|
|
|
|
|
Xith3D Internals
