sdljava-users — General Discussion about sdljava and gljava

[sdljava-users] SWIG_glew_init();

[Ivan Z. G. <iva...@ya...>]

Greetings,

I've added code in SDLSurface.setVideoMode(int, int, int, long) which
calls SWIG_glew_init() if the surface has an OpenGL context.  I didn't
really like the idea of people having to calls this externally on their
own.  Please let me know if it causes any problems.

-Ivan/

Re: [sdljava-users] Usage example for glGetDoublev

[Ivan Z. G. <iva...@ya...>]

Thanks for the very detailed information :-)

The helpful class is sdljava.util.BufferUtil...which Robert kindly
coded.  Interesting to have a look at the code inside...

Please let us know if your able to make it work Gregor.

-Ivan/

Robert Schuster wrote:

>Hi,
>I just want to jump into the discussion because I was one of the persons who
>suggested Ivan to use NIO buffers instead of Java arrays (and I have some small
>background about the topic from JNI and GNU Classpath coding).
>
>  
>
>>The biggest buffer I use that way is there to store a matrix of 
>>4x4 doubles, that is, 128 bytes.
>>    
>>
>Perfect. This is really the point where you can use NIO buffers. It may be look
>odd to you but a regular Java array is more troublesome than a NIO buffer. The
>buffer is an object denoting a certain memory region. Therefore you can think of
>it as a thin wrapper around a normal C array (or memory region that allocated
>with malloc/calloc).
>
>A Java array is something that lifes inside the JVM and can be implemented very
>differently. NIO buffers and Java arrays have very similar JNI functions to
>interact with them. Both have a function which returns a pointer so that you can
>modify the data in C-style. However the array access function explicitly states
>that you *may* receive the pointer to a copy of the original data (remember that
>Java arrays life in the JVMs heap and may be moved around because of garbage
>collection and memory compaction). This won't happen with NIO buffers.
>
>If you have a feeling that frequent bytebuffer instantiations would harm the
>performance of your application then please have a look whether you may not
>solve this problem in a different way (e.g. pooling buffers or the like).
>
>  
>
>>Using byte buffers may be a valid approach when working on large, uniform 
>>amounts of data like framebuffers. But that is not the case with geometry 
>>data for OpenGL. Using vertex arrays is almost out of question for me since 
>>the geometry data I have is very dynamic in every way.
>>    
>>
>Definitely not. NIO buffers can be used wherever interaction with native
>machinery is involved. I once wrote a jinput plugin which uses the Linux
>kernel's input system to access mouse/keyboard/joypad etc (You can find the
>sources in the respective forums at javagaming.org). It makes heavy use of NIO
>buffers even for such small amounts of data (key/button/axes states) and I think
>it is a big win that the system's kernel can write into the memory which it
>shares with my Java application.
>
>  
>
>>Well, this is not trying to be a rant. I'm just not yet convinced that this is 
>>the right approach. It looks like far too much overhead to me, making all the 
>>OpenGL functions taking (small) arrays practically useless.
>>    
>>
>Well, in which way could they be implemented otherwise? At one point you will
>forced to create a buffer in memory (probably C). If you hand over the data in
>Java arrays and copy it over into a malloc'ed memory region then this would hit
>performance seriously (You need one copy operation and one time malloc/free in
>GLJava's code.) With NIO buffers the JNI implementation would simply return the
>buffer's pointer and call the OpenGL function. The handling of the buffer
>(recreate it every time or do some pooling) is up to you - the application
>programmer.
>
>  
>
>>Maybe some
>>benchmarking is in order to get some definitive answers, but I don't have 
>>enough time for that.
>>    
>>
>Well I try to prove it with a bit of pseudo code. (I use pseudo code because I
>dont know the JNI function names by heart. They are very tedious ...)
>
>
>1. With Java arrays
>GL.java
>
>public class GL {
>  public native setSomethingv(int[] foo);
>}
>
>net_sf_GL.c:
>
>setSomethingv(jvm, jobject java_array){
>
>   jint* thevalues = JVM_get_pointer_to_java_array(java_array); // may copy
>
>   int size = JVM_get_size_of_java_array(java_array);
>
>   int* buffer = malloc(sizeof(int) * size);
>
>   memcopy(thevalues -> buffer, size * sizeof(int));
>
>   GLsetSomething(buffer);
>
>   JVM_release_access_to_java_array(java_array);
>}
>
>2. With NIO buffers
>
>public class GL {
>  public native setSomethingv(IntBuffer foo);
>}
>net_sf_GL.c:
>
>setSomethingv(jvm, jobject nio_buffer){
>
>   jint* thevalues = JVM_get_pointer_of_nio_buffer(nio_buffer);
>
>   GLsetSomething(thevalues);
>
>   JVM_release_access_to_java_array(java_array);
>}
>
>(I am broadly ignoring any type conversion oddities here.)
>
>Btw: There is a utility class in GLJava that creates direct Integer, Long,
>Short, Double and Float buffers in one method call (In fact every newer OpenGL
>binding* has these methods ...)
>
>cu
>Robert
>
>* JOGL, LwJGL
>
>
>-------------------------------------------------------
>SF.Net email is Sponsored by the Better Software Conference & EXPO
>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>_______________________________________________
>sdljava-users mailing list
>sdl...@li...
>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>  
>

Re: [sdljava-users] Usage example for glGetDoublev

[Robert S. <the...@gm...>]

Hi,
I just want to jump into the discussion because I was one of the persons who
suggested Ivan to use NIO buffers instead of Java arrays (and I have some small
background about the topic from JNI and GNU Classpath coding).

> The biggest buffer I use that way is there to store a matrix of 
> 4x4 doubles, that is, 128 bytes.
Perfect. This is really the point where you can use NIO buffers. It may be look
odd to you but a regular Java array is more troublesome than a NIO buffer. The
buffer is an object denoting a certain memory region. Therefore you can think of
it as a thin wrapper around a normal C array (or memory region that allocated
with malloc/calloc).

A Java array is something that lifes inside the JVM and can be implemented very
differently. NIO buffers and Java arrays have very similar JNI functions to
interact with them. Both have a function which returns a pointer so that you can
modify the data in C-style. However the array access function explicitly states
that you *may* receive the pointer to a copy of the original data (remember that
Java arrays life in the JVMs heap and may be moved around because of garbage
collection and memory compaction). This won't happen with NIO buffers.

If you have a feeling that frequent bytebuffer instantiations would harm the
performance of your application then please have a look whether you may not
solve this problem in a different way (e.g. pooling buffers or the like).

> Using byte buffers may be a valid approach when working on large, uniform 
> amounts of data like framebuffers. But that is not the case with geometry 
> data for OpenGL. Using vertex arrays is almost out of question for me since 
> the geometry data I have is very dynamic in every way.
Definitely not. NIO buffers can be used wherever interaction with native
machinery is involved. I once wrote a jinput plugin which uses the Linux
kernel's input system to access mouse/keyboard/joypad etc (You can find the
sources in the respective forums at javagaming.org). It makes heavy use of NIO
buffers even for such small amounts of data (key/button/axes states) and I think
it is a big win that the system's kernel can write into the memory which it
shares with my Java application.

> Well, this is not trying to be a rant. I'm just not yet convinced that this is 
> the right approach. It looks like far too much overhead to me, making all the 
> OpenGL functions taking (small) arrays practically useless.
Well, in which way could they be implemented otherwise? At one point you will
forced to create a buffer in memory (probably C). If you hand over the data in
Java arrays and copy it over into a malloc'ed memory region then this would hit
performance seriously (You need one copy operation and one time malloc/free in
GLJava's code.) With NIO buffers the JNI implementation would simply return the
buffer's pointer and call the OpenGL function. The handling of the buffer
(recreate it every time or do some pooling) is up to you - the application
programmer.

> Maybe some
> benchmarking is in order to get some definitive answers, but I don't have 
> enough time for that.
Well I try to prove it with a bit of pseudo code. (I use pseudo code because I
dont know the JNI function names by heart. They are very tedious ...)


1. With Java arrays
GL.java

public class GL {
  public native setSomethingv(int[] foo);
}

net_sf_GL.c:

setSomethingv(jvm, jobject java_array){

   jint* thevalues = JVM_get_pointer_to_java_array(java_array); // may copy

   int size = JVM_get_size_of_java_array(java_array);

   int* buffer = malloc(sizeof(int) * size);

   memcopy(thevalues -> buffer, size * sizeof(int));

   GLsetSomething(buffer);

   JVM_release_access_to_java_array(java_array);
}

2. With NIO buffers

public class GL {
  public native setSomethingv(IntBuffer foo);
}
net_sf_GL.c:

setSomethingv(jvm, jobject nio_buffer){

   jint* thevalues = JVM_get_pointer_of_nio_buffer(nio_buffer);

   GLsetSomething(thevalues);

   JVM_release_access_to_java_array(java_array);
}

(I am broadly ignoring any type conversion oddities here.)

Btw: There is a utility class in GLJava that creates direct Integer, Long,
Short, Double and Float buffers in one method call (In fact every newer OpenGL
binding* has these methods ...)

cu
Robert

* JOGL, LwJGL

Re: [sdljava-users] Usage example for glGetDoublev

[Ivan Z. G. <iva...@ya...>]

Hi Gregor,

I appreciate all feedback so don't worry.  Please keep it coming.  The
API needs to be actually _usable_ by others.  You make a good point that
I did not consider.  From what your saying it sounds like there should
be methods provided that just copy the data since it is so small.  It
also seems like all OpenGL functions which are similar would want to
operate in a similar fashion.  The problem is I'm not sure what all the
functions are which would operate on a small data set.  I'm still very
new to OpenGL myself.

Would you give me a list of the funtions you need which should just copy
the data and I will add methods which do so.

Please send me back anything which can make the OpenGL layer more usable.

Thanks,
-Ivan/

Gregor M=FCckl wrote:

>Hi!
>
>My problem is that I really have to allocate these direct buffers on dem=
and=20
>for something like one or two opengl calls each. Furthermore, they reall=
y are=20
>quite small. The biggest buffer I use that way is there to store a matri=
x of=20
>4x4 doubles, that is, 128 bytes.
>
>Using byte buffers may be a valid approach when working on large, unifor=
m=20
>amounts of data like framebuffers. But that is not the case with geometr=
y=20
>data for OpenGL. Using vertex arrays is almost out of question for me si=
nce=20
>the geometry data I have is very dynamic in every way.
>
>Well, this is not trying to be a rant. I'm just not yet convinced that t=
his is=20
>the right approach. It looks like far too much overhead to me, making al=
l the=20
>OpenGL functions taking (small) arrays practically useless. Maybe some=20
>benchmarking is in order to get some definitive answers, but I don't hav=
e=20
>enough time for that.
>
>Regards,
>Gregor
>
>On Saturday 10 September 2005 23:39, Ivan Z. Ganza wrote:
> =20
>
>>Hi Gregor,
>>
>>The direct buffers introduced with NIO are better than sliced
>>bread...:-)   Without them I don't think it would be possible to achiev=
e
>>any level of meaningfully performance.
>>
>>A direct buffer is mapped directly to a region of memory inside the
>>JVM's memory space.  When you perform operations on a direct buffer the=
y
>>effect the memory directly and thus and are very fast.  The other optio=
n
>>is to copy the data each time from the JVM's memory space into the
>>native code space (or visa versa).  The copy method is an order of
>>magnitude slower.  First the new array must be allocated.  Then the dat=
a
>>must be copied into the array each time.
>>
>>For an idea of the speed difference look at the difference in execution
>>time between updating the screen using the two methods:
>>
>>     ByteBuffer getPixelData()
>>
>>and
>>
>>     public void setPixelData32(int[] pixelData)
>>
>>
>>If you are using these direct buffers you should allocate all the
>>buffers you need before doing anything.  Then utilize them later howeve=
r
>>you wish.  Otherwise the performance will be much worse if a new one is
>>constantly created.  Notice that getPixelData() only creates the buffer
>>once.  The buffer directly has access to the data of the surface!
>>
>>-Ivan/
>>
>>Gregor M=FCckl wrote:
>>   =20
>>
>>>Hi, Ivan!
>>>
>>>Thanks for your help. Indeed, ByteBuffer.allocateDirect() is the right
>>>solution and it seems to work now. I cannot tell for sure yet as the
>>>gtk-based input handling is still not working properly and I therefore
>>>can't navigate the 3D view.
>>>
>>>However, I feel that relyinig on java.nio.ByteBuffer and derivates is =
a
>>>bit strange, especially given their somewhat peculiar design. Looking =
at
>>>the code I have now which has to copy data to newly created buffers ev=
ery
>>>time I need to pass an array to OpenGL, I get the feeling that this
>>>slower than dealing directly with arrays, which are readiy available i=
n
>>>my case and probably more optimizeable by the Java compiler and JVM.
>>>
>>>What was the reason for using these buffers instead of arrays? Am I
>>>missing something here?
>>>
>>>Regards,
>>>Gregor
>>>
>>>On Saturday 10 September 2005 01:37, Ivan Z. Ganza wrote:
>>>     =20
>>>
>>>>Gregor,
>>>>
>>>>I had a look in the code and intact SDLSurface isn't a good example
>>>>because the buffer is created in the native code.  Have a look at
>>>>ByteBufferPool instead.
>>>>
>>>>-Ivan/
>>>>
>>>>Gregor M=FCckl wrote:
>>>>       =20
>>>>
>>>>>Hi!
>>>>>
>>>>>I"m trying to use glGetDoublev to read back the modelview and projec=
tion
>>>>>matrices from OpenGL. However, it looks like I'm doing something wro=
ng
>>>>>with the DoubleBuffers required for that.
>>>>>
>>>>>What I'm doing basically is in this code:
>>>>>
>>>>>  GlewImpl gl;
>>>>>  private ml.math.Matrix4 modelViewMatrix;
>>>>>  private ml.math.Matrix4 projectionMatrix;
>>>>>  private double viewFieldOfView;
>>>>>  private DoubleBuffer matrixBuffer;
>>>>>
>>>>>  public ViewWindowSpace(Widget parent)
>>>>>  {
>>>>>	super();
>>>>>
>>>>>      matrixBuffer=3DDoubleBuffer.allocate(16);
>>>>>      modelViewMatrix=3Dnew Matrix4();
>>>>>      projectionMatrix=3Dnew Matrix4();
>>>>>
>>>>>	currentRenderMode=3DRenderMode.Solid;
>>>>>
>>>>>      initGLContext();
>>>>>
>>>>>     // snip: unrelated code
>>>>>
>>>>>      addListener(new LifeCycleListener() {
>>>>>
>>>>>          public void lifeCycleEvent(LifeCycleEvent e)
>>>>>          {
>>>>>              // TODO Auto-generated method stub
>>>>>              if(e.getType()=3D=3DLifeCycleEvent.Type.REALIZE) {
>>>>>                  setupViewingAreaInitial();
>>>>>              }
>>>>>
>>>>>          }
>>>>>	}
>>>>>
>>>>>      // snip: unrelated code
>>>>>  }
>>>>>
>>>>>  protected void setupViewingAreaInitial()
>>>>>  {
>>>>>      viewFieldOfView=3D45.0;
>>>>>
>>>>>      glBegin();
>>>>>      GlewJNI.SWIG_glew_init();
>>>>>      gl=3Dnew GlewImpl();
>>>>>      int width =3D getWidth();
>>>>>      int height =3D getHeight();
>>>>>      gl.glViewport(0, 0, width, height);
>>>>>      gl.glMatrixMode(GL.GL_PROJECTION);      // select the projecti=
on
>>>>>matrix
>>>>>      gl.glLoadIdentity();                            // reset the
>>>>>projection matrix
>>>>>      float fAspect =3D (float) width / (float) height;
>>>>>      gl.gluPerspective(viewFieldOfView, fAspect, 0.5f, 400.0f);
>>>>>      gl.glMatrixMode(GL.GL_MODELVIEW);       // select the modelvie=
w
>>>>>matrix gl.glLoadIdentity();
>>>>>
>>>>>      gl.glGetDoublev(GL.GL_MODELVIEW_MATRIX,matrixBuffer);
>>>>>      modelViewMatrix.setFromOpenGLMatrix(matrixBuffer);
>>>>>      gl.glGetDoublev(GL.GL_PROJECTION_MATRIX,matrixBuffer);
>>>>>      projectionMatrix.setFromOpenGLMatrix(matrixBuffer);
>>>>>
>>>>>      glEnd();
>>>>>  }
>>>>>
>>>>>What this does:
>>>>>
>>>>>The constructor allocates the DoubleBuffer in question and registers=
 an
>>>>>event handler to do the rest of the initialilsation once the opengl
>>>>>context can actually be used. When this is the case,
>>>>>setupViewingAreaInitial is called to perform the init of the gl cont=
ext.
>>>>>This fails with a NullPointerException in the first call to
>>>>>gl.glGetDoublev(). The console output for this exception is as follo=
ws:
>>>>>
>>>>>Exception in thread "main" java.lang.NullPointerException: null addr=
ess
>>>>>returned from GetDirectBufferAddress() call.  Make sure the buffer i=
s a
>>>>>_direct_ buffer.
>>>>>	at org.gljava.opengl.x.swig.GlewJNI.glGetDoublev(Native Method)
>>>>>	at org.gljava.opengl.impl.glew.GlewImpl.glGetDoublev(GlewImpl.java:=
143)
>>>>>	at
>>>>>ml.ui.plugins.view.ViewWindowSpace.setupViewingAreaInitial(ViewWindo=
wSpa
>>>>>ce .java:322) at
>>>>>ml.ui.plugins.view.ViewWindowSpace$2.lifeCycleEvent(ViewWindowSpace.=
java
>>>>>:2 77) at org.gnu.gtk.Widget.fireLifeCycleEvent(Widget.java:735)
>>>>>	at org.gnu.gtk.Widget.handleRealize(Widget.java:764)
>>>>>	at org.gnu.gtk.Widget.gtk_widget_show(Native Method)
>>>>>	at org.gnu.gtk.Widget.show(Widget.java:119)
>>>>>	at ml.core.State.createMainWindow(State.java:158)
>>>>>	at ml.ML3D.<init>(ML3D.java:49)
>>>>>	at ml.ML3D.main(ML3D.java:66)
>>>>>
>>>>>I have no clue why this happens. Do I initialize the DoubleBuffer in
>>>>>question badly? Is there any example that shows how it should be don=
e?
>>>>>Any help would be appreciated.
>>>>>
>>>>>Regards,
>>>>>Gregor
>>>>>
>>>>>
>>>>>-------------------------------------------------------
>>>>>SF.Net email is Sponsored by the Better Software Conference & EXPO
>>>>>September 19-22, 2005 * San Francisco, CA * Development Lifecycle
>>>>>Practices Agile & Plan-Driven Development * Managing Projects & Team=
s *
>>>>>Testing & QA Security * Process Improvement & Measurement *
>>>>>http://www.sqe.com/bsce5sf
>>>>>_______________________________________________
>>>>>sdljava-users mailing list
>>>>>sdl...@li...
>>>>>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>>>>         =20
>>>>>
>>>>-------------------------------------------------------
>>>>SF.Net email is Sponsored by the Better Software Conference & EXPO
>>>>September 19-22, 2005 * San Francisco, CA * Development Lifecycle
>>>>Practices Agile & Plan-Driven Development * Managing Projects & Teams=
 *
>>>>Testing & QA Security * Process Improvement & Measurement *
>>>>http://www.sqe.com/bsce5sf
>>>>_______________________________________________
>>>>sdljava-users mailing list
>>>>sdl...@li...
>>>>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>>>       =20
>>>>
>>>-------------------------------------------------------
>>>SF.Net email is Sponsored by the Better Software Conference & EXPO
>>>September 19-22, 2005 * San Francisco, CA * Development Lifecycle
>>>Practices Agile & Plan-Driven Development * Managing Projects & Teams =
*
>>>Testing & QA Security * Process Improvement & Measurement *
>>>http://www.sqe.com/bsce5sf
>>>_______________________________________________
>>>sdljava-users mailing list
>>>sdl...@li...
>>>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>>     =20
>>>
>>-------------------------------------------------------
>>SF.Net email is Sponsored by the Better Software Conference & EXPO
>>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Pract=
ices
>>Agile & Plan-Driven Development * Managing Projects & Teams * Testing &=
 QA
>>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5=
sf
>>_______________________________________________
>>sdljava-users mailing list
>>sdl...@li...
>>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>   =20
>>
>
>
>-------------------------------------------------------
>SF.Net email is Sponsored by the Better Software Conference & EXPO
>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practi=
ces
>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & =
QA
>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5s=
f
>_______________________________________________
>sdljava-users mailing list
>sdl...@li...
>https://lists.sourceforge.net/lists/listinfo/sdljava-users
> =20
>

Re: [sdljava-users] Usage example for glGetDoublev

[Gregor <Gre...@gm...>]

Hi!

My problem is that I really have to allocate these direct buffers on demand=
=20
for something like one or two opengl calls each. Furthermore, they really a=
re=20
quite small. The biggest buffer I use that way is there to store a matrix o=
f=20
4x4 doubles, that is, 128 bytes.

Using byte buffers may be a valid approach when working on large, uniform=20
amounts of data like framebuffers. But that is not the case with geometry=20
data for OpenGL. Using vertex arrays is almost out of question for me since=
=20
the geometry data I have is very dynamic in every way.

Well, this is not trying to be a rant. I'm just not yet convinced that this=
 is=20
the right approach. It looks like far too much overhead to me, making all t=
he=20
OpenGL functions taking (small) arrays practically useless. Maybe some=20
benchmarking is in order to get some definitive answers, but I don't have=20
enough time for that.

Regards,
Gregor

On Saturday 10 September 2005 23:39, Ivan Z. Ganza wrote:
> Hi Gregor,
>
> The direct buffers introduced with NIO are better than sliced
> bread...:-)   Without them I don't think it would be possible to achieve
> any level of meaningfully performance.
>
> A direct buffer is mapped directly to a region of memory inside the
> JVM's memory space.  When you perform operations on a direct buffer they
> effect the memory directly and thus and are very fast.  The other option
> is to copy the data each time from the JVM's memory space into the
> native code space (or visa versa).  The copy method is an order of
> magnitude slower.  First the new array must be allocated.  Then the data
> must be copied into the array each time.
>
> For an idea of the speed difference look at the difference in execution
> time between updating the screen using the two methods:
>
>      ByteBuffer getPixelData()
>
> and
>
>      public void setPixelData32(int[] pixelData)
>
>
> If you are using these direct buffers you should allocate all the
> buffers you need before doing anything.  Then utilize them later however
> you wish.  Otherwise the performance will be much worse if a new one is
> constantly created.  Notice that getPixelData() only creates the buffer
> once.  The buffer directly has access to the data of the surface!
>
> -Ivan/
>
> Gregor M=FCckl wrote:
> >Hi, Ivan!
> >
> >Thanks for your help. Indeed, ByteBuffer.allocateDirect() is the right
> >solution and it seems to work now. I cannot tell for sure yet as the
> >gtk-based input handling is still not working properly and I therefore
> > can't navigate the 3D view.
> >
> >However, I feel that relyinig on java.nio.ByteBuffer and derivates is a
> > bit strange, especially given their somewhat peculiar design. Looking at
> > the code I have now which has to copy data to newly created buffers eve=
ry
> > time I need to pass an array to OpenGL, I get the feeling that this
> > slower than dealing directly with arrays, which are readiy available in
> > my case and probably more optimizeable by the Java compiler and JVM.
> >
> >What was the reason for using these buffers instead of arrays? Am I
> > missing something here?
> >
> >Regards,
> >Gregor
> >
> >On Saturday 10 September 2005 01:37, Ivan Z. Ganza wrote:
> >>Gregor,
> >>
> >>I had a look in the code and intact SDLSurface isn't a good example
> >>because the buffer is created in the native code.  Have a look at
> >>ByteBufferPool instead.
> >>
> >>-Ivan/
> >>
> >>Gregor M=FCckl wrote:
> >>>Hi!
> >>>
> >>>I"m trying to use glGetDoublev to read back the modelview and projecti=
on
> >>>matrices from OpenGL. However, it looks like I'm doing something wrong
> >>>with the DoubleBuffers required for that.
> >>>
> >>>What I'm doing basically is in this code:
> >>>
> >>>   GlewImpl gl;
> >>>   private ml.math.Matrix4 modelViewMatrix;
> >>>   private ml.math.Matrix4 projectionMatrix;
> >>>   private double viewFieldOfView;
> >>>   private DoubleBuffer matrixBuffer;
> >>>
> >>>   public ViewWindowSpace(Widget parent)
> >>>   {
> >>>	super();
> >>>
> >>>       matrixBuffer=3DDoubleBuffer.allocate(16);
> >>>       modelViewMatrix=3Dnew Matrix4();
> >>>       projectionMatrix=3Dnew Matrix4();
> >>>
> >>>	currentRenderMode=3DRenderMode.Solid;
> >>>
> >>>       initGLContext();
> >>>
> >>>      // snip: unrelated code
> >>>
> >>>       addListener(new LifeCycleListener() {
> >>>
> >>>           public void lifeCycleEvent(LifeCycleEvent e)
> >>>           {
> >>>               // TODO Auto-generated method stub
> >>>               if(e.getType()=3D=3DLifeCycleEvent.Type.REALIZE) {
> >>>                   setupViewingAreaInitial();
> >>>               }
> >>>
> >>>           }
> >>>	}
> >>>
> >>>       // snip: unrelated code
> >>>   }
> >>>
> >>>   protected void setupViewingAreaInitial()
> >>>   {
> >>>       viewFieldOfView=3D45.0;
> >>>
> >>>       glBegin();
> >>>       GlewJNI.SWIG_glew_init();
> >>>       gl=3Dnew GlewImpl();
> >>>       int width =3D getWidth();
> >>>       int height =3D getHeight();
> >>>       gl.glViewport(0, 0, width, height);
> >>>       gl.glMatrixMode(GL.GL_PROJECTION);      // select the projection
> >>>matrix
> >>>       gl.glLoadIdentity();                            // reset the
> >>>projection matrix
> >>>       float fAspect =3D (float) width / (float) height;
> >>>       gl.gluPerspective(viewFieldOfView, fAspect, 0.5f, 400.0f);
> >>>       gl.glMatrixMode(GL.GL_MODELVIEW);       // select the modelview
> >>>matrix gl.glLoadIdentity();
> >>>
> >>>       gl.glGetDoublev(GL.GL_MODELVIEW_MATRIX,matrixBuffer);
> >>>       modelViewMatrix.setFromOpenGLMatrix(matrixBuffer);
> >>>       gl.glGetDoublev(GL.GL_PROJECTION_MATRIX,matrixBuffer);
> >>>       projectionMatrix.setFromOpenGLMatrix(matrixBuffer);
> >>>
> >>>       glEnd();
> >>>   }
> >>>
> >>>What this does:
> >>>
> >>>The constructor allocates the DoubleBuffer in question and registers an
> >>>event handler to do the rest of the initialilsation once the opengl
> >>>context can actually be used. When this is the case,
> >>>setupViewingAreaInitial is called to perform the init of the gl contex=
t.
> >>>This fails with a NullPointerException in the first call to
> >>>gl.glGetDoublev(). The console output for this exception is as follows:
> >>>
> >>>Exception in thread "main" java.lang.NullPointerException: null address
> >>>returned from GetDirectBufferAddress() call.  Make sure the buffer is a
> >>>_direct_ buffer.
> >>>	at org.gljava.opengl.x.swig.GlewJNI.glGetDoublev(Native Method)
> >>>	at org.gljava.opengl.impl.glew.GlewImpl.glGetDoublev(GlewImpl.java:14=
3)
> >>>	at
> >>>ml.ui.plugins.view.ViewWindowSpace.setupViewingAreaInitial(ViewWindowS=
pa
> >>>ce .java:322) at
> >>>ml.ui.plugins.view.ViewWindowSpace$2.lifeCycleEvent(ViewWindowSpace.ja=
va
> >>>:2 77) at org.gnu.gtk.Widget.fireLifeCycleEvent(Widget.java:735)
> >>>	at org.gnu.gtk.Widget.handleRealize(Widget.java:764)
> >>>	at org.gnu.gtk.Widget.gtk_widget_show(Native Method)
> >>>	at org.gnu.gtk.Widget.show(Widget.java:119)
> >>>	at ml.core.State.createMainWindow(State.java:158)
> >>>	at ml.ML3D.<init>(ML3D.java:49)
> >>>	at ml.ML3D.main(ML3D.java:66)
> >>>
> >>>I have no clue why this happens. Do I initialize the DoubleBuffer in
> >>>question badly? Is there any example that shows how it should be done?
> >>>Any help would be appreciated.
> >>>
> >>>Regards,
> >>>Gregor
> >>>
> >>>
> >>>-------------------------------------------------------
> >>>SF.Net email is Sponsored by the Better Software Conference & EXPO
> >>>September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> >>>Practices Agile & Plan-Driven Development * Managing Projects & Teams *
> >>>Testing & QA Security * Process Improvement & Measurement *
> >>>http://www.sqe.com/bsce5sf
> >>>_______________________________________________
> >>>sdljava-users mailing list
> >>>sdl...@li...
> >>>https://lists.sourceforge.net/lists/listinfo/sdljava-users
> >>
> >>-------------------------------------------------------
> >>SF.Net email is Sponsored by the Better Software Conference & EXPO
> >>September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> >> Practices Agile & Plan-Driven Development * Managing Projects & Teams *
> >> Testing & QA Security * Process Improvement & Measurement *
> >> http://www.sqe.com/bsce5sf
> >> _______________________________________________
> >>sdljava-users mailing list
> >>sdl...@li...
> >>https://lists.sourceforge.net/lists/listinfo/sdljava-users
> >
> >-------------------------------------------------------
> >SF.Net email is Sponsored by the Better Software Conference & EXPO
> >September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> > Practices Agile & Plan-Driven Development * Managing Projects & Teams *
> > Testing & QA Security * Process Improvement & Measurement *
> > http://www.sqe.com/bsce5sf
> > _______________________________________________
> >sdljava-users mailing list
> >sdl...@li...
> >https://lists.sourceforge.net/lists/listinfo/sdljava-users
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic=
es
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> sdljava-users mailing list
> sdl...@li...
> https://lists.sourceforge.net/lists/listinfo/sdljava-users

Re: [sdljava-users] Usage example for glGetDoublev

[Ivan Z. G. <iva...@ya...>]

Hi Gregor,

The direct buffers introduced with NIO are better than sliced
bread...:-)   Without them I don't think it would be possible to achieve
any level of meaningfully performance.

A direct buffer is mapped directly to a region of memory inside the
JVM's memory space.  When you perform operations on a direct buffer they
effect the memory directly and thus and are very fast.  The other option
is to copy the data each time from the JVM's memory space into the
native code space (or visa versa).  The copy method is an order of
magnitude slower.  First the new array must be allocated.  Then the data
must be copied into the array each time.

For an idea of the speed difference look at the difference in execution
time between updating the screen using the two methods:
  =20
     ByteBuffer getPixelData()

and

     public void setPixelData32(int[] pixelData)


If you are using these direct buffers you should allocate all the
buffers you need before doing anything.  Then utilize them later however
you wish.  Otherwise the performance will be much worse if a new one is
constantly created.  Notice that getPixelData() only creates the buffer
once.  The buffer directly has access to the data of the surface!
=20
-Ivan/

Gregor M=FCckl wrote:

>Hi, Ivan!
>
>Thanks for your help. Indeed, ByteBuffer.allocateDirect() is the right=20
>solution and it seems to work now. I cannot tell for sure yet as the=20
>gtk-based input handling is still not working properly and I therefore c=
an't=20
>navigate the 3D view.
>
>However, I feel that relyinig on java.nio.ByteBuffer and derivates is a =
bit=20
>strange, especially given their somewhat peculiar design. Looking at the=
 code=20
>I have now which has to copy data to newly created buffers every time I =
need=20
>to pass an array to OpenGL, I get the feeling that this slower than deal=
ing=20
>directly with arrays, which are readiy available in my case and probably=
 more=20
>optimizeable by the Java compiler and JVM.
>
>What was the reason for using these buffers instead of arrays? Am I miss=
ing=20
>something here?
>
>Regards,
>Gregor
>
>On Saturday 10 September 2005 01:37, Ivan Z. Ganza wrote:
> =20
>
>>Gregor,
>>
>>I had a look in the code and intact SDLSurface isn't a good example
>>because the buffer is created in the native code.  Have a look at
>>ByteBufferPool instead.
>>
>>-Ivan/
>>
>>Gregor M=FCckl wrote:
>>   =20
>>
>>>Hi!
>>>
>>>I"m trying to use glGetDoublev to read back the modelview and projecti=
on
>>>matrices from OpenGL. However, it looks like I'm doing something wrong
>>>with the DoubleBuffers required for that.
>>>
>>>What I'm doing basically is in this code:
>>>
>>>   GlewImpl gl;
>>>   private ml.math.Matrix4 modelViewMatrix;
>>>   private ml.math.Matrix4 projectionMatrix;
>>>   private double viewFieldOfView;
>>>   private DoubleBuffer matrixBuffer;
>>>
>>>   public ViewWindowSpace(Widget parent)
>>>   {
>>>	super();
>>>
>>>       matrixBuffer=3DDoubleBuffer.allocate(16);
>>>       modelViewMatrix=3Dnew Matrix4();
>>>       projectionMatrix=3Dnew Matrix4();
>>>
>>>	currentRenderMode=3DRenderMode.Solid;
>>>
>>>       initGLContext();
>>>
>>>      // snip: unrelated code
>>>
>>>       addListener(new LifeCycleListener() {
>>>
>>>           public void lifeCycleEvent(LifeCycleEvent e)
>>>           {
>>>               // TODO Auto-generated method stub
>>>               if(e.getType()=3D=3DLifeCycleEvent.Type.REALIZE) {
>>>                   setupViewingAreaInitial();
>>>               }
>>>
>>>           }
>>>	}
>>>
>>>       // snip: unrelated code
>>>   }
>>>
>>>   protected void setupViewingAreaInitial()
>>>   {
>>>       viewFieldOfView=3D45.0;
>>>
>>>       glBegin();
>>>       GlewJNI.SWIG_glew_init();
>>>       gl=3Dnew GlewImpl();
>>>       int width =3D getWidth();
>>>       int height =3D getHeight();
>>>       gl.glViewport(0, 0, width, height);
>>>       gl.glMatrixMode(GL.GL_PROJECTION);      // select the projectio=
n
>>>matrix
>>>       gl.glLoadIdentity();                            // reset the
>>>projection matrix
>>>       float fAspect =3D (float) width / (float) height;
>>>       gl.gluPerspective(viewFieldOfView, fAspect, 0.5f, 400.0f);
>>>       gl.glMatrixMode(GL.GL_MODELVIEW);       // select the modelview
>>>matrix gl.glLoadIdentity();
>>>
>>>       gl.glGetDoublev(GL.GL_MODELVIEW_MATRIX,matrixBuffer);
>>>       modelViewMatrix.setFromOpenGLMatrix(matrixBuffer);
>>>       gl.glGetDoublev(GL.GL_PROJECTION_MATRIX,matrixBuffer);
>>>       projectionMatrix.setFromOpenGLMatrix(matrixBuffer);
>>>
>>>       glEnd();
>>>   }
>>>
>>>What this does:
>>>
>>>The constructor allocates the DoubleBuffer in question and registers a=
n
>>>event handler to do the rest of the initialilsation once the opengl
>>>context can actually be used. When this is the case,
>>>setupViewingAreaInitial is called to perform the init of the gl contex=
t.
>>>This fails with a NullPointerException in the first call to=20
>>>gl.glGetDoublev(). The console output for this exception is as follows=
:
>>>
>>>Exception in thread "main" java.lang.NullPointerException: null addres=
s
>>>returned from GetDirectBufferAddress() call.  Make sure the buffer is =
a
>>>_direct_ buffer.
>>>	at org.gljava.opengl.x.swig.GlewJNI.glGetDoublev(Native Method)
>>>	at org.gljava.opengl.impl.glew.GlewImpl.glGetDoublev(GlewImpl.java:14=
3)
>>>	at
>>>ml.ui.plugins.view.ViewWindowSpace.setupViewingAreaInitial(ViewWindowS=
pace
>>>.java:322) at
>>>ml.ui.plugins.view.ViewWindowSpace$2.lifeCycleEvent(ViewWindowSpace.ja=
va:2
>>>77) at org.gnu.gtk.Widget.fireLifeCycleEvent(Widget.java:735)
>>>	at org.gnu.gtk.Widget.handleRealize(Widget.java:764)
>>>	at org.gnu.gtk.Widget.gtk_widget_show(Native Method)
>>>	at org.gnu.gtk.Widget.show(Widget.java:119)
>>>	at ml.core.State.createMainWindow(State.java:158)
>>>	at ml.ML3D.<init>(ML3D.java:49)
>>>	at ml.ML3D.main(ML3D.java:66)
>>>
>>>I have no clue why this happens. Do I initialize the DoubleBuffer in
>>>question badly? Is there any example that shows how it should be done?
>>>Any help would be appreciated.
>>>
>>>Regards,
>>>Gregor
>>>
>>>
>>>-------------------------------------------------------
>>>SF.Net email is Sponsored by the Better Software Conference & EXPO
>>>September 19-22, 2005 * San Francisco, CA * Development Lifecycle
>>>Practices Agile & Plan-Driven Development * Managing Projects & Teams =
*
>>>Testing & QA Security * Process Improvement & Measurement *
>>>http://www.sqe.com/bsce5sf
>>>_______________________________________________
>>>sdljava-users mailing list
>>>sdl...@li...
>>>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>>     =20
>>>
>>-------------------------------------------------------
>>SF.Net email is Sponsored by the Better Software Conference & EXPO
>>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Pract=
ices
>>Agile & Plan-Driven Development * Managing Projects & Teams * Testing &=
 QA
>>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5=
sf
>>_______________________________________________
>>sdljava-users mailing list
>>sdl...@li...
>>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>   =20
>>
>
>
>-------------------------------------------------------
>SF.Net email is Sponsored by the Better Software Conference & EXPO
>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practi=
ces
>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & =
QA
>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5s=
f
>_______________________________________________
>sdljava-users mailing list
>sdl...@li...
>https://lists.sourceforge.net/lists/listinfo/sdljava-users
> =20
>

Re: [sdljava-users] Usage example for glGetDoublev

[Gregor <Gre...@gm...>]

Hi, Ivan!

Thanks for your help. Indeed, ByteBuffer.allocateDirect() is the right=20
solution and it seems to work now. I cannot tell for sure yet as the=20
gtk-based input handling is still not working properly and I therefore can'=
t=20
navigate the 3D view.

However, I feel that relyinig on java.nio.ByteBuffer and derivates is a bit=
=20
strange, especially given their somewhat peculiar design. Looking at the co=
de=20
I have now which has to copy data to newly created buffers every time I nee=
d=20
to pass an array to OpenGL, I get the feeling that this slower than dealing=
=20
directly with arrays, which are readiy available in my case and probably mo=
re=20
optimizeable by the Java compiler and JVM.

What was the reason for using these buffers instead of arrays? Am I missing=
=20
something here?

Regards,
Gregor

On Saturday 10 September 2005 01:37, Ivan Z. Ganza wrote:
> Gregor,
>
> I had a look in the code and intact SDLSurface isn't a good example
> because the buffer is created in the native code.  Have a look at
> ByteBufferPool instead.
>
> -Ivan/
>
> Gregor M=FCckl wrote:
> >Hi!
> >
> >I"m trying to use glGetDoublev to read back the modelview and projection
> >matrices from OpenGL. However, it looks like I'm doing something wrong
> > with the DoubleBuffers required for that.
> >
> >What I'm doing basically is in this code:
> >
> >    GlewImpl gl;
> >    private ml.math.Matrix4 modelViewMatrix;
> >    private ml.math.Matrix4 projectionMatrix;
> >    private double viewFieldOfView;
> >    private DoubleBuffer matrixBuffer;
> >
> >    public ViewWindowSpace(Widget parent)
> >    {
> >	super();
> >
> >        matrixBuffer=3DDoubleBuffer.allocate(16);
> >        modelViewMatrix=3Dnew Matrix4();
> >        projectionMatrix=3Dnew Matrix4();
> >
> >	currentRenderMode=3DRenderMode.Solid;
> >
> >        initGLContext();
> >
> >       // snip: unrelated code
> >
> >        addListener(new LifeCycleListener() {
> >
> >            public void lifeCycleEvent(LifeCycleEvent e)
> >            {
> >                // TODO Auto-generated method stub
> >                if(e.getType()=3D=3DLifeCycleEvent.Type.REALIZE) {
> >                    setupViewingAreaInitial();
> >                }
> >
> >            }
> >	}
> >
> >        // snip: unrelated code
> >    }
> >
> >    protected void setupViewingAreaInitial()
> >    {
> >        viewFieldOfView=3D45.0;
> >
> >        glBegin();
> >        GlewJNI.SWIG_glew_init();
> >        gl=3Dnew GlewImpl();
> >        int width =3D getWidth();
> >        int height =3D getHeight();
> >        gl.glViewport(0, 0, width, height);
> >        gl.glMatrixMode(GL.GL_PROJECTION);      // select the projection
> >matrix
> >        gl.glLoadIdentity();                            // reset the
> >projection matrix
> >        float fAspect =3D (float) width / (float) height;
> >        gl.gluPerspective(viewFieldOfView, fAspect, 0.5f, 400.0f);
> >        gl.glMatrixMode(GL.GL_MODELVIEW);       // select the modelview
> > matrix gl.glLoadIdentity();
> >
> >        gl.glGetDoublev(GL.GL_MODELVIEW_MATRIX,matrixBuffer);
> >        modelViewMatrix.setFromOpenGLMatrix(matrixBuffer);
> >        gl.glGetDoublev(GL.GL_PROJECTION_MATRIX,matrixBuffer);
> >        projectionMatrix.setFromOpenGLMatrix(matrixBuffer);
> >
> >        glEnd();
> >    }
> >
> >What this does:
> >
> >The constructor allocates the DoubleBuffer in question and registers an
> > event handler to do the rest of the initialilsation once the opengl
> > context can actually be used. When this is the case,
> > setupViewingAreaInitial is called to perform the init of the gl context.
> > This fails with a NullPointerException in the first call to=20
> > gl.glGetDoublev(). The console output for this exception is as follows:
> >
> >Exception in thread "main" java.lang.NullPointerException: null address
> >returned from GetDirectBufferAddress() call.  Make sure the buffer is a
> >_direct_ buffer.
> >	at org.gljava.opengl.x.swig.GlewJNI.glGetDoublev(Native Method)
> >	at org.gljava.opengl.impl.glew.GlewImpl.glGetDoublev(GlewImpl.java:143)
> >	at
> >ml.ui.plugins.view.ViewWindowSpace.setupViewingAreaInitial(ViewWindowSpa=
ce
> >.java:322) at
> >ml.ui.plugins.view.ViewWindowSpace$2.lifeCycleEvent(ViewWindowSpace.java=
:2
> >77) at org.gnu.gtk.Widget.fireLifeCycleEvent(Widget.java:735)
> >	at org.gnu.gtk.Widget.handleRealize(Widget.java:764)
> >	at org.gnu.gtk.Widget.gtk_widget_show(Native Method)
> >	at org.gnu.gtk.Widget.show(Widget.java:119)
> >	at ml.core.State.createMainWindow(State.java:158)
> >	at ml.ML3D.<init>(ML3D.java:49)
> >	at ml.ML3D.main(ML3D.java:66)
> >
> >I have no clue why this happens. Do I initialize the DoubleBuffer in
> > question badly? Is there any example that shows how it should be done?
> > Any help would be appreciated.
> >
> >Regards,
> >Gregor
> >
> >
> >-------------------------------------------------------
> >SF.Net email is Sponsored by the Better Software Conference & EXPO
> >September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> > Practices Agile & Plan-Driven Development * Managing Projects & Teams *
> > Testing & QA Security * Process Improvement & Measurement *
> > http://www.sqe.com/bsce5sf
> > _______________________________________________
> >sdljava-users mailing list
> >sdl...@li...
> >https://lists.sourceforge.net/lists/listinfo/sdljava-users
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic=
es
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> sdljava-users mailing list
> sdl...@li...
> https://lists.sourceforge.net/lists/listinfo/sdljava-users

Re: [sdljava-users] Usage example for glGetDoublev

[Ivan Z. G. <iva...@ya...>]

Gregor,

I had a look in the code and intact SDLSurface isn't a good example
because the buffer is created in the native code.  Have a look at
ByteBufferPool instead.

-Ivan/

Gregor M=FCckl wrote:

>Hi!
>
>I"m trying to use glGetDoublev to read back the modelview and projection=
=20
>matrices from OpenGL. However, it looks like I'm doing something wrong w=
ith=20
>the DoubleBuffers required for that.
>
>What I'm doing basically is in this code:
>
>    GlewImpl gl;
>    private ml.math.Matrix4 modelViewMatrix;
>    private ml.math.Matrix4 projectionMatrix;
>    private double viewFieldOfView;
>    private DoubleBuffer matrixBuffer;
>
>    public ViewWindowSpace(Widget parent)=20
>    {
>	super();
>
>        matrixBuffer=3DDoubleBuffer.allocate(16);
>        modelViewMatrix=3Dnew Matrix4();
>        projectionMatrix=3Dnew Matrix4();
>	=09
>	currentRenderMode=3DRenderMode.Solid;
>
>        initGLContext();
>
>       // snip: unrelated code
>
>        addListener(new LifeCycleListener() {
>
>            public void lifeCycleEvent(LifeCycleEvent e)
>            {
>                // TODO Auto-generated method stub
>                if(e.getType()=3D=3DLifeCycleEvent.Type.REALIZE) {
>                    setupViewingAreaInitial();
>                }
>                   =20
>            }
>	}
>
>        // snip: unrelated code
>    }
>
>    protected void setupViewingAreaInitial()=20
>    {
>        viewFieldOfView=3D45.0;
>       =20
>        glBegin();
>        GlewJNI.SWIG_glew_init();
>        gl=3Dnew GlewImpl();
>        int width =3D getWidth();
>        int height =3D getHeight();
>        gl.glViewport(0, 0, width, height);    =20
>        gl.glMatrixMode(GL.GL_PROJECTION);      // select the projection=
=20
>matrix
>        gl.glLoadIdentity();                            // reset the=20
>projection matrix
>        float fAspect =3D (float) width / (float) height;
>        gl.gluPerspective(viewFieldOfView, fAspect, 0.5f, 400.0f);
>        gl.glMatrixMode(GL.GL_MODELVIEW);       // select the modelview =
matrix
>        gl.glLoadIdentity();
>
>        gl.glGetDoublev(GL.GL_MODELVIEW_MATRIX,matrixBuffer);
>        modelViewMatrix.setFromOpenGLMatrix(matrixBuffer);
>        gl.glGetDoublev(GL.GL_PROJECTION_MATRIX,matrixBuffer);
>        projectionMatrix.setFromOpenGLMatrix(matrixBuffer);
>       =20
>        glEnd();
>    }
>
>What this does:
>
>The constructor allocates the DoubleBuffer in question and registers an =
event=20
>handler to do the rest of the initialilsation once the opengl context ca=
n=20
>actually be used. When this is the case, setupViewingAreaInitial is call=
ed to=20
>perform the init of the gl context. This fails with a NullPointerExcepti=
on in
>the first call to  gl.glGetDoublev(). The console output for this except=
ion is=20
>as follows:
>
>Exception in thread "main" java.lang.NullPointerException: null address=20
>returned from GetDirectBufferAddress() call.  Make sure the buffer is a=20
>_direct_ buffer.
>	at org.gljava.opengl.x.swig.GlewJNI.glGetDoublev(Native Method)
>	at org.gljava.opengl.impl.glew.GlewImpl.glGetDoublev(GlewImpl.java:143)
>	at=20
>ml.ui.plugins.view.ViewWindowSpace.setupViewingAreaInitial(ViewWindowSpa=
ce.java:322)
>	at=20
>ml.ui.plugins.view.ViewWindowSpace$2.lifeCycleEvent(ViewWindowSpace.java=
:277)
>	at org.gnu.gtk.Widget.fireLifeCycleEvent(Widget.java:735)
>	at org.gnu.gtk.Widget.handleRealize(Widget.java:764)
>	at org.gnu.gtk.Widget.gtk_widget_show(Native Method)
>	at org.gnu.gtk.Widget.show(Widget.java:119)
>	at ml.core.State.createMainWindow(State.java:158)
>	at ml.ML3D.<init>(ML3D.java:49)
>	at ml.ML3D.main(ML3D.java:66)
>
>I have no clue why this happens. Do I initialize the DoubleBuffer in que=
stion=20
>badly? Is there any example that shows how it should be done? Any help w=
ould=20
>be appreciated.
>
>Regards,
>Gregor
>
>
>-------------------------------------------------------
>SF.Net email is Sponsored by the Better Software Conference & EXPO
>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practi=
ces
>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & =
QA
>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5s=
f
>_______________________________________________
>sdljava-users mailing list
>sdl...@li...
>https://lists.sourceforge.net/lists/listinfo/sdljava-users
> =20
>

[sdljava-users] Usage example for glGetDoublev [call allocateDirect()]

[Ivan G. <IG...@re...>]

Greetings,

=20

...sending this email from work so I don't have the original to reply
too.

=20

I realized on the way here that actually all you have to do is call
allocateDirect() instead of just allocate().  Notice that
allocateDirect() only exists on ByteBuffer.  After you allocate a direct
byte buffer then call the appropriate asXXXXBuffer() method to get the
type of buffer you want.  You can see examples of this in
SDLSurface.java in the get/setPixelData(...) methods.  I don't remember
the precise name here but you should be able to find it.  Be careful to
allocate the correct size of ByteBuffer based on what your going to
convert it to.

=20

Please let me know if you end up getting this to work.

=20

-Ivan/

Re: [sdljava-users] Usage example for glGetDoublev

[Ivan Z. G. <iva...@ya...>]

Hi Gregor,

I'm glad to see this stuff being used!

There doesn't seem to be anything wrong with your code.  The problem is
that the VM isn't returning a direct buffer.=20
Unfortunately the VM doesn't seem to support direct buffers.  What type
of VM are you using?

    See here:=20
http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#GetDirectBuffer=
Address

-Ivan/

Gregor M=FCckl wrote:

>Hi!
>
>I"m trying to use glGetDoublev to read back the modelview and projection=
=20
>matrices from OpenGL. However, it looks like I'm doing something wrong w=
ith=20
>the DoubleBuffers required for that.
>
>What I'm doing basically is in this code:
>
>    GlewImpl gl;
>    private ml.math.Matrix4 modelViewMatrix;
>    private ml.math.Matrix4 projectionMatrix;
>    private double viewFieldOfView;
>    private DoubleBuffer matrixBuffer;
>
>    public ViewWindowSpace(Widget parent)=20
>    {
>	super();
>
>        matrixBuffer=3DDoubleBuffer.allocate(16);
>        modelViewMatrix=3Dnew Matrix4();
>        projectionMatrix=3Dnew Matrix4();
>	=09
>	currentRenderMode=3DRenderMode.Solid;
>
>        initGLContext();
>
>       // snip: unrelated code
>
>        addListener(new LifeCycleListener() {
>
>            public void lifeCycleEvent(LifeCycleEvent e)
>            {
>                // TODO Auto-generated method stub
>                if(e.getType()=3D=3DLifeCycleEvent.Type.REALIZE) {
>                    setupViewingAreaInitial();
>                }
>                   =20
>            }
>	}
>
>        // snip: unrelated code
>    }
>
>    protected void setupViewingAreaInitial()=20
>    {
>        viewFieldOfView=3D45.0;
>       =20
>        glBegin();
>        GlewJNI.SWIG_glew_init();
>        gl=3Dnew GlewImpl();
>        int width =3D getWidth();
>        int height =3D getHeight();
>        gl.glViewport(0, 0, width, height);    =20
>        gl.glMatrixMode(GL.GL_PROJECTION);      // select the projection=
=20
>matrix
>        gl.glLoadIdentity();                            // reset the=20
>projection matrix
>        float fAspect =3D (float) width / (float) height;
>        gl.gluPerspective(viewFieldOfView, fAspect, 0.5f, 400.0f);
>        gl.glMatrixMode(GL.GL_MODELVIEW);       // select the modelview =
matrix
>        gl.glLoadIdentity();
>
>        gl.glGetDoublev(GL.GL_MODELVIEW_MATRIX,matrixBuffer);
>        modelViewMatrix.setFromOpenGLMatrix(matrixBuffer);
>        gl.glGetDoublev(GL.GL_PROJECTION_MATRIX,matrixBuffer);
>        projectionMatrix.setFromOpenGLMatrix(matrixBuffer);
>       =20
>        glEnd();
>    }
>
>What this does:
>
>The constructor allocates the DoubleBuffer in question and registers an =
event=20
>handler to do the rest of the initialilsation once the opengl context ca=
n=20
>actually be used. When this is the case, setupViewingAreaInitial is call=
ed to=20
>perform the init of the gl context. This fails with a NullPointerExcepti=
on in
>the first call to  gl.glGetDoublev(). The console output for this except=
ion is=20
>as follows:
>
>Exception in thread "main" java.lang.NullPointerException: null address=20
>returned from GetDirectBufferAddress() call.  Make sure the buffer is a=20
>_direct_ buffer.
>	at org.gljava.opengl.x.swig.GlewJNI.glGetDoublev(Native Method)
>	at org.gljava.opengl.impl.glew.GlewImpl.glGetDoublev(GlewImpl.java:143)
>	at=20
>ml.ui.plugins.view.ViewWindowSpace.setupViewingAreaInitial(ViewWindowSpa=
ce.java:322)
>	at=20
>ml.ui.plugins.view.ViewWindowSpace$2.lifeCycleEvent(ViewWindowSpace.java=
:277)
>	at org.gnu.gtk.Widget.fireLifeCycleEvent(Widget.java:735)
>	at org.gnu.gtk.Widget.handleRealize(Widget.java:764)
>	at org.gnu.gtk.Widget.gtk_widget_show(Native Method)
>	at org.gnu.gtk.Widget.show(Widget.java:119)
>	at ml.core.State.createMainWindow(State.java:158)
>	at ml.ML3D.<init>(ML3D.java:49)
>	at ml.ML3D.main(ML3D.java:66)
>
>I have no clue why this happens. Do I initialize the DoubleBuffer in que=
stion=20
>badly? Is there any example that shows how it should be done? Any help w=
ould=20
>be appreciated.
>
>Regards,
>Gregor
>
>
>-------------------------------------------------------
>SF.Net email is Sponsored by the Better Software Conference & EXPO
>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practi=
ces
>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & =
QA
>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5s=
f
>_______________________________________________
>sdljava-users mailing list
>sdl...@li...
>https://lists.sourceforge.net/lists/listinfo/sdljava-users
> =20
>

[sdljava-users] Usage example for glGetDoublev

[Gregor <Gre...@gm...>]

Hi!

I"m trying to use glGetDoublev to read back the modelview and projection 
matrices from OpenGL. However, it looks like I'm doing something wrong with 
the DoubleBuffers required for that.

What I'm doing basically is in this code:

    GlewImpl gl;
    private ml.math.Matrix4 modelViewMatrix;
    private ml.math.Matrix4 projectionMatrix;
    private double viewFieldOfView;
    private DoubleBuffer matrixBuffer;

    public ViewWindowSpace(Widget parent) 
    {
	super();

        matrixBuffer=DoubleBuffer.allocate(16);
        modelViewMatrix=new Matrix4();
        projectionMatrix=new Matrix4();
		
	currentRenderMode=RenderMode.Solid;

        initGLContext();

       // snip: unrelated code

        addListener(new LifeCycleListener() {

            public void lifeCycleEvent(LifeCycleEvent e)
            {
                // TODO Auto-generated method stub
                if(e.getType()==LifeCycleEvent.Type.REALIZE) {
                    setupViewingAreaInitial();
                }
                    
            }
	}

        // snip: unrelated code
    }

    protected void setupViewingAreaInitial() 
    {
        viewFieldOfView=45.0;
        
        glBegin();
        GlewJNI.SWIG_glew_init();
        gl=new GlewImpl();
        int width = getWidth();
        int height = getHeight();
        gl.glViewport(0, 0, width, height);     
        gl.glMatrixMode(GL.GL_PROJECTION);      // select the projection 
matrix
        gl.glLoadIdentity();                            // reset the 
projection matrix
        float fAspect = (float) width / (float) height;
        gl.gluPerspective(viewFieldOfView, fAspect, 0.5f, 400.0f);
        gl.glMatrixMode(GL.GL_MODELVIEW);       // select the modelview matrix
        gl.glLoadIdentity();

        gl.glGetDoublev(GL.GL_MODELVIEW_MATRIX,matrixBuffer);
        modelViewMatrix.setFromOpenGLMatrix(matrixBuffer);
        gl.glGetDoublev(GL.GL_PROJECTION_MATRIX,matrixBuffer);
        projectionMatrix.setFromOpenGLMatrix(matrixBuffer);
        
        glEnd();
    }

What this does:

The constructor allocates the DoubleBuffer in question and registers an event 
handler to do the rest of the initialilsation once the opengl context can 
actually be used. When this is the case, setupViewingAreaInitial is called to 
perform the init of the gl context. This fails with a NullPointerException in
the first call to  gl.glGetDoublev(). The console output for this exception is 
as follows:

Exception in thread "main" java.lang.NullPointerException: null address 
returned from GetDirectBufferAddress() call.  Make sure the buffer is a 
_direct_ buffer.
	at org.gljava.opengl.x.swig.GlewJNI.glGetDoublev(Native Method)
	at org.gljava.opengl.impl.glew.GlewImpl.glGetDoublev(GlewImpl.java:143)
	at 
ml.ui.plugins.view.ViewWindowSpace.setupViewingAreaInitial(ViewWindowSpace.java:322)
	at 
ml.ui.plugins.view.ViewWindowSpace$2.lifeCycleEvent(ViewWindowSpace.java:277)
	at org.gnu.gtk.Widget.fireLifeCycleEvent(Widget.java:735)
	at org.gnu.gtk.Widget.handleRealize(Widget.java:764)
	at org.gnu.gtk.Widget.gtk_widget_show(Native Method)
	at org.gnu.gtk.Widget.show(Widget.java:119)
	at ml.core.State.createMainWindow(State.java:158)
	at ml.ML3D.<init>(ML3D.java:49)
	at ml.ML3D.main(ML3D.java:66)

I have no clue why this happens. Do I initialize the DoubleBuffer in question 
badly? Is there any example that shows how it should be done? Any help would 
be appreciated.

Regards,
Gregor

Re: [sdljava-users] glew initialisation too early in gljava

[Gregor <Gre...@gm...>]

Hello!

Now gljava works perfectly here as far as I can tell. Thanks alot!

Regards,
Gregor

On Saturday 03 September 2005 17:58, Gregor M=FCckl wrote:
> Hello!
>
> I will send you a confirmation as soon as I can. However, I'm fighting at
> another front right now which effectively prevents me from testing this
> change right now. Please be patient!
>
> Regards,
> Gregor
>
> On Saturday 03 September 2005 17:11, Ivan Z. Ganza wrote:
> > Greetings,
> >
> > I've changed the code so that it does not call SWIG_glew_init().  The
> > user of the library must now call this at the appropriate time.
> >
> > CVS has been updated.  Please let me know if this works for you.  I've
> > also updated the class comment in GlewImpl.
> >
> > Thanks,
> > -Ivan/
> >
> > Gregor M=FCckl wrote:
> > >Hi!
> > >
> > >I discovered that the initialisation of glew happens far to early in
> > > gljava, thus crashing any program that wants to use it. The reason is
> > > that newer nvidia drivers (correctly) don't return a value on
> > > glGetString(GL_VERSION) unless there is a valid glx context from which
> > > this function is called. See glxinfo as an example on how it should be
> > > done.
> > >
> > >The glew initialisation sits in a static block which is executed on
> > > program startup, far too early to give the program a chance to create=
 a
> > > context. Maybe you should move that to a user-callable init function
> > > instead of executing it automatically?
> > >
> > >Regards,
> > >Gregor
> > >
> > >
> > >-------------------------------------------------------
> > >SF.Net email is Sponsored by the Better Software Conference & EXPO
> > >September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> > > Practices Agile & Plan-Driven Development * Managing Projects & Teams=
 *
> > > Testing & QA Security * Process Improvement & Measurement *
> > > http://www.sqe.com/bsce5sf
> > > _______________________________________________
> > >sdljava-users mailing list
> > >sdl...@li...
> > >https://lists.sourceforge.net/lists/listinfo/sdljava-users
> >
> > -------------------------------------------------------
> > SF.Net email is Sponsored by the Better Software Conference & EXPO
> > September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> > Practices Agile & Plan-Driven Development * Managing Projects & Teams *
> > Testing & QA Security * Process Improvement & Measurement *
> > http://www.sqe.com/bsce5sf
> > _______________________________________________
> > sdljava-users mailing list
> > sdl...@li...
> > https://lists.sourceforge.net/lists/listinfo/sdljava-users
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic=
es
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> sdljava-users mailing list
> sdl...@li...
> https://lists.sourceforge.net/lists/listinfo/sdljava-users

Re: [sdljava-users] glew initialisation too early in gljava

[Gregor <Gre...@gm...>]

Hello!

I will send you a confirmation as soon as I can. However, I'm fighting at=20
another front right now which effectively prevents me from testing this=20
change right now. Please be patient!

Regards,
Gregor

On Saturday 03 September 2005 17:11, Ivan Z. Ganza wrote:
> Greetings,
>
> I've changed the code so that it does not call SWIG_glew_init().  The
> user of the library must now call this at the appropriate time.
>
> CVS has been updated.  Please let me know if this works for you.  I've
> also updated the class comment in GlewImpl.
>
> Thanks,
> -Ivan/
>
> Gregor M=FCckl wrote:
> >Hi!
> >
> >I discovered that the initialisation of glew happens far to early in
> > gljava, thus crashing any program that wants to use it. The reason is
> > that newer nvidia drivers (correctly) don't return a value on
> > glGetString(GL_VERSION) unless there is a valid glx context from which
> > this function is called. See glxinfo as an example on how it should be
> > done.
> >
> >The glew initialisation sits in a static block which is executed on
> > program startup, far too early to give the program a chance to create a
> > context. Maybe you should move that to a user-callable init function
> > instead of executing it automatically?
> >
> >Regards,
> >Gregor
> >
> >
> >-------------------------------------------------------
> >SF.Net email is Sponsored by the Better Software Conference & EXPO
> >September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> > Practices Agile & Plan-Driven Development * Managing Projects & Teams *
> > Testing & QA Security * Process Improvement & Measurement *
> > http://www.sqe.com/bsce5sf
> > _______________________________________________
> >sdljava-users mailing list
> >sdl...@li...
> >https://lists.sourceforge.net/lists/listinfo/sdljava-users
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic=
es
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> sdljava-users mailing list
> sdl...@li...
> https://lists.sourceforge.net/lists/listinfo/sdljava-users

Re: [sdljava-users] glew initialisation too early in gljava

[Ivan Z. G. <iva...@ya...>]

Greetings,

I've changed the code so that it does not call SWIG_glew_init().  The
user of the library must now call this at the appropriate time.

CVS has been updated.  Please let me know if this works for you.  I've
also updated the class comment in GlewImpl.

Thanks,
-Ivan/
     =20

Gregor M=FCckl wrote:

>Hi!
>
>I discovered that the initialisation of glew happens far to early in glj=
ava,=20
>thus crashing any program that wants to use it. The reason is that newer=
=20
>nvidia drivers (correctly) don't return a value on glGetString(GL_VERSIO=
N)=20
>unless there is a valid glx context from which this function is called. =
See=20
>glxinfo as an example on how it should be done.
>
>The glew initialisation sits in a static block which is executed on prog=
ram=20
>startup, far too early to give the program a chance to create a context.=
=20
>Maybe you should move that to a user-callable init function instead of=20
>executing it automatically?
>
>Regards,
>Gregor
>
>
>-------------------------------------------------------
>SF.Net email is Sponsored by the Better Software Conference & EXPO
>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practi=
ces
>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & =
QA
>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5s=
f
>_______________________________________________
>sdljava-users mailing list
>sdl...@li...
>https://lists.sourceforge.net/lists/listinfo/sdljava-users
> =20
>

Re: [sdljava-users] glew initialisation too early in gljava

[Ivan Z. G. <iva...@ya...>]

I will do this over the weekend and it will be checked into CVS.

-Ivan/

Gregor M=FCckl wrote:

>Please go ahead. When will the changes be available (in CVS or as a rele=
ase)?
>
>Regards,
>Gregor
>
>On Tuesday 30 August 2005 03:43, Ivan Z. Ganza wrote:
> =20
>
>>Sounds good.  Thanks for letting me know about this.
>>
>>I will make it so that the user of the library has to initialize it
>>themselves via a static init function.  If this sounds wrong please let
>>me know, otherwise,  I will go ahead and implement it.
>>
>>-Ivan/
>>
>>Gregor M=FCckl wrote:
>>   =20
>>
>>>Hi!
>>>
>>>I discovered that the initialisation of glew happens far to early in
>>>gljava, thus crashing any program that wants to use it. The reason is
>>>that newer nvidia drivers (correctly) don't return a value on
>>>glGetString(GL_VERSION) unless there is a valid glx context from which
>>>this function is called. See glxinfo as an example on how it should be
>>>done.
>>>
>>>The glew initialisation sits in a static block which is executed on
>>>program startup, far too early to give the program a chance to create =
a
>>>context. Maybe you should move that to a user-callable init function
>>>instead of executing it automatically?
>>>
>>>Regards,
>>>Gregor
>>>
>>>
>>>-------------------------------------------------------
>>>SF.Net email is Sponsored by the Better Software Conference & EXPO
>>>September 19-22, 2005 * San Francisco, CA * Development Lifecycle
>>>Practices Agile & Plan-Driven Development * Managing Projects & Teams =
*
>>>Testing & QA Security * Process Improvement & Measurement *
>>>http://www.sqe.com/bsce5sf
>>>_______________________________________________
>>>sdljava-users mailing list
>>>sdl...@li...
>>>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>>     =20
>>>
>>-------------------------------------------------------
>>SF.Net email is Sponsored by the Better Software Conference & EXPO
>>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Pract=
ices
>>Agile & Plan-Driven Development * Managing Projects & Teams * Testing &=
 QA
>>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5=
sf
>>_______________________________________________
>>sdljava-users mailing list
>>sdl...@li...
>>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>   =20
>>
>
>
>-------------------------------------------------------
>SF.Net email is Sponsored by the Better Software Conference & EXPO
>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practi=
ces
>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & =
QA
>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5s=
f
>_______________________________________________
>sdljava-users mailing list
>sdl...@li...
>https://lists.sourceforge.net/lists/listinfo/sdljava-users
> =20
>

Re: [sdljava-users] glew initialisation too early in gljava

[Gregor <Gre...@gm...>]

Please go ahead. When will the changes be available (in CVS or as a release=
)?

Regards,
Gregor

On Tuesday 30 August 2005 03:43, Ivan Z. Ganza wrote:
> Sounds good.  Thanks for letting me know about this.
>
> I will make it so that the user of the library has to initialize it
> themselves via a static init function.  If this sounds wrong please let
> me know, otherwise,  I will go ahead and implement it.
>
> -Ivan/
>
> Gregor M=FCckl wrote:
> >Hi!
> >
> >I discovered that the initialisation of glew happens far to early in
> > gljava, thus crashing any program that wants to use it. The reason is
> > that newer nvidia drivers (correctly) don't return a value on
> > glGetString(GL_VERSION) unless there is a valid glx context from which
> > this function is called. See glxinfo as an example on how it should be
> > done.
> >
> >The glew initialisation sits in a static block which is executed on
> > program startup, far too early to give the program a chance to create a
> > context. Maybe you should move that to a user-callable init function
> > instead of executing it automatically?
> >
> >Regards,
> >Gregor
> >
> >
> >-------------------------------------------------------
> >SF.Net email is Sponsored by the Better Software Conference & EXPO
> >September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> > Practices Agile & Plan-Driven Development * Managing Projects & Teams *
> > Testing & QA Security * Process Improvement & Measurement *
> > http://www.sqe.com/bsce5sf
> > _______________________________________________
> >sdljava-users mailing list
> >sdl...@li...
> >https://lists.sourceforge.net/lists/listinfo/sdljava-users
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic=
es
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> sdljava-users mailing list
> sdl...@li...
> https://lists.sourceforge.net/lists/listinfo/sdljava-users

Re: [sdljava-users] glew initialisation too early in gljava

[Ivan Z. G. <iva...@ya...>]

Sounds good.  Thanks for letting me know about this.

I will make it so that the user of the library has to initialize it
themselves via a static init function.  If this sounds wrong please let
me know, otherwise,  I will go ahead and implement it.

-Ivan/

Gregor M=FCckl wrote:

>Hi!
>
>I discovered that the initialisation of glew happens far to early in glj=
ava,=20
>thus crashing any program that wants to use it. The reason is that newer=
=20
>nvidia drivers (correctly) don't return a value on glGetString(GL_VERSIO=
N)=20
>unless there is a valid glx context from which this function is called. =
See=20
>glxinfo as an example on how it should be done.
>
>The glew initialisation sits in a static block which is executed on prog=
ram=20
>startup, far too early to give the program a chance to create a context.=
=20
>Maybe you should move that to a user-callable init function instead of=20
>executing it automatically?
>
>Regards,
>Gregor
>
>
>-------------------------------------------------------
>SF.Net email is Sponsored by the Better Software Conference & EXPO
>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practi=
ces
>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & =
QA
>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5s=
f
>_______________________________________________
>sdljava-users mailing list
>sdl...@li...
>https://lists.sourceforge.net/lists/listinfo/sdljava-users
> =20
>

[sdljava-users] glew initialisation too early in gljava

[Gregor <Gre...@gm...>]

Hi!

I discovered that the initialisation of glew happens far to early in gljava, 
thus crashing any program that wants to use it. The reason is that newer 
nvidia drivers (correctly) don't return a value on glGetString(GL_VERSION) 
unless there is a valid glx context from which this function is called. See 
glxinfo as an example on how it should be done.

The glew initialisation sits in a static block which is executed on program 
startup, far too early to give the program a chance to create a context. 
Maybe you should move that to a user-callable init function instead of 
executing it automatically?

Regards,
Gregor

Re: [sdljava-users] TTF_SizeText() in sdljava

[Ivan Z. G. <iva...@ya...>]

Greetings,

I've added the following method to SDLTrueTypeFont:

    public TextSize sizeText(String text)

The returned TextSize object will contain the information about width
and height.  I've updated CVS with the new code.

Let me know if it works for you.

-Ivan/



Patric Rufflar wrote:

> Hello List,
>
> I am missing TTF_SizeText() in sdljava. I tried to call
> SWIG_SDLTTF.TTF_SizeText() myself, but I got stuck on instantiating a
> SWIGTYPE_p_int object.
>
> Who can help me?
>
> Regards
> Patric Rufflar
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing
> & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> sdljava-users mailing list
> sdl...@li...
> https://lists.sourceforge.net/lists/listinfo/sdljava-users

[sdljava-users] installing from source, and MS Windows support

[John M. G. <joh...@ya...>]

Planned on installing the whole shebang from source tonight
(on Fedora GNU/Linux), and started with GLEW.

I can't build GLEW, and am also annoyed by GLEW that it's docs are
so spare.

Here:
http://www.simisen.com/jmg/pmwiki/pmwiki.php?n=Main.Sdljava
I wrote:
"I'm stopping here for the moment. The best solution may be to build everything
from source. Personally, I'm less interested in games & SDL, and more
interested in a freeglut binding for gljava. Trouble is, since

    * such a binding would depend on gljava, and
    * gljava is bound with sdljava, and
    * sdljava depends on GLEW which I can't sucessfully build, 

I'm stuck."

and also added this page to my little wiki:
http://www.simisen.com/jmg/pmwiki/pmwiki.php?n=Main.SdljavaFromSource

Although I'm still having a little trouble with JOGL,
I may just spend some time with that to see
if I can learn its seemingly overly-complex API and get
it working with GCJ for the small little projects that
I'm interested in.

Just my 2 cents: not sure how much of a MS Windows
following you have, but consider dropping GLEW. If there's
enough interest in sdljava for Windows, then someone will
write you the necessary wgl code so you wouldn't need
GLEW anyway.

If: you end up going that route, and if you can separate out
gljava from sdljava (to pave the way for a freeglut binding),
I think you'll have a winner. :)

Thanks,
---John



		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

Re: [sdljava-users] TTF_SizeText() in sdljava

[Ivan Z. G. <iva...@ya...>]

Hi Patric,

Let me have a look at this.  I think we'll need a small change and it
should be possible to expose that method.

-Ivan/

Patric Rufflar wrote:

> Hello List,
>
> I am missing TTF_SizeText() in sdljava. I tried to call
> SWIG_SDLTTF.TTF_SizeText() myself, but I got stuck on instantiating a
> SWIGTYPE_p_int object.
>
> Who can help me?
>
> Regards
> Patric Rufflar
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing
> & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> sdljava-users mailing list
> sdl...@li...
> https://lists.sourceforge.net/lists/listinfo/sdljava-users

[sdljava-users] TTF_SizeText() in sdljava

[Patric R. <pa...@ma...>]

Hello List,

I am missing TTF_SizeText() in sdljava. I tried to call 
SWIG_SDLTTF.TTF_SizeText() myself, but I got stuck on instantiating a 
SWIGTYPE_p_int object.

Who can help me?

Regards
Patric Rufflar

Re: [sdljava-users] help getting space-invaders to run (GNU/Linux, FC4, GCJ)

[<iva...@ya...>]

On Wed, Aug 17, 2005 at 04:58:12PM -0700, John M. Gabriele wrote:
> 
> 
> --- "Ivan Z. Ganza" <iva...@ya...> wrote:
> 
> > John M. Gabriele wrote:
> > 
> > >--- "Ivan Z. Ganza" <iva...@ya...> wrote:
> > >
> > >  
> > >
> > >>John M. Gabriele wrote:
> > >>
> > >>[snip]
> > >>    
> > >>
> > >>>I just took a look at the GLEW mailing list,
> > >>>https://sourceforge.net/mailarchive/forum.php?forum_id=43720
> > >>>and it looks pretty barren.
> > >>>
> > >>>
> > >>>      
> > >>>
> > >>The list isn't actually used -- I should remove it.
> > >>    
> > >>
> > >
> > >Sorry -- I don't know what you mean. Do you manage that
> > >project as well as sdljava (and gljava)?
> > >
> > >I don't see your name here:
> > >https://sourceforge.net/project/memberlist.php?group_id=67586
> > >
> > >Is GLEW a subproject of sdljava?
> > >  
> > >
> > Oh...ahhh my mistake.
> > 
> > I misunderstood.  No I'm not the manager of GLEW.  My mind had 
> > understood you meant the gljava mailing list and not the glew :-(
> > 
> 
> I wouldn't remove the gljava ML just yet. After your comment
> about creating a glut wrapper using SWIG like was done with
> SDL, that project may yet take on a life of it's own.
> 
> Did you recently separate gljava off on it's own, or was it
> that way since you took over the project?
> 
> Actually, I'm curious about the history of both projects...
> Could you tell us about it? We could take this offline if you
> think it's too far off-topic.
> 
> Thanks,
> ---John

Nah its probably good to have in the archive for informational/historic 
purposes.

First there was JSDL which was NOT my project but started by a bunch of 
people who I have never met or talked with.  The original project pages 
are still up I belive.

About one year before I took over the project I had much free time 
because I was recently laid off and not working so I started coding 
a java game using JSDL.  This resulted in me making many changes to the 
original API.  I tried to submit the changes but the project at that 
point it didn't seem active anymore so I choose to take it over.  Soon I 
realized that a complete re-write was in order and hence the project was 
born.

While working with sdljava when I started to add the OpenGL code I 
realized that it could be free of any dependency on sdljava and live on 
its own.  As long as 'something' could initialize the OpenGL context 
then everything should work.  At that point I started the gljava 
project.  For a while I worked on making a GLUT binding with SWIG 
however I had some problems that I was never able to fix (probably due 
to my misunderstanding of something) so I had to leave it to collect 
dust until the problems could be fixed.  FreeGLUT might be the answer 
and I'm wonder if the problem I had would go away.

So there is the history of the two projects ;-)

-Ivan/

> 
> 
> 
> 		
> ____________________________________________________
> Start your day with Yahoo! - make it your home page 
> http://www.yahoo.com/r/hs 
>  
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> sdljava-users mailing list
> sdl...@li...
> https://lists.sourceforge.net/lists/listinfo/sdljava-users

Re: [sdljava-users] help getting space-invaders to run (GNU/Linux, FC4, GCJ)

[John M. G. <joh...@ya...>]

--- "Ivan Z. Ganza" <iva...@ya...> wrote:

> John M. Gabriele wrote:
> 
> >--- "Ivan Z. Ganza" <iva...@ya...> wrote:
> >
> >  
> >
> >>John M. Gabriele wrote:
> >>
> >>[snip]
> >>    
> >>
> >>>I just took a look at the GLEW mailing list,
> >>>https://sourceforge.net/mailarchive/forum.php?forum_id=43720
> >>>and it looks pretty barren.
> >>>
> >>>
> >>>      
> >>>
> >>The list isn't actually used -- I should remove it.
> >>    
> >>
> >
> >Sorry -- I don't know what you mean. Do you manage that
> >project as well as sdljava (and gljava)?
> >
> >I don't see your name here:
> >https://sourceforge.net/project/memberlist.php?group_id=67586
> >
> >Is GLEW a subproject of sdljava?
> >  
> >
> Oh...ahhh my mistake.
> 
> I misunderstood.  No I'm not the manager of GLEW.  My mind had 
> understood you meant the gljava mailing list and not the glew :-(
> 

I wouldn't remove the gljava ML just yet. After your comment
about creating a glut wrapper using SWIG like was done with
SDL, that project may yet take on a life of it's own.

Did you recently separate gljava off on it's own, or was it
that way since you took over the project?

Actually, I'm curious about the history of both projects...
Could you tell us about it? We could take this offline if you
think it's too far off-topic.

Thanks,
---John



		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

Re: [sdljava-users] help getting space-invaders to run (GNU/Linux, FC4, GCJ)

[Ivan Z. G. <iva...@ya...>]

John M. Gabriele wrote:

>--- "Ivan Z. Ganza" <iva...@ya...> wrote:
>
>  
>
>>John M. Gabriele wrote:
>>
>>[snip]
>>    
>>
>>>I just took a look at the GLEW mailing list,
>>>https://sourceforge.net/mailarchive/forum.php?forum_id=43720
>>>and it looks pretty barren.
>>>
>>>
>>>      
>>>
>>The list isn't actually used -- I should remove it.
>>    
>>
>
>Sorry -- I don't know what you mean. Do you manage that
>project as well as sdljava (and gljava)?
>
>I don't see your name here:
>https://sourceforge.net/project/memberlist.php?group_id=67586
>
>Is GLEW a subproject of sdljava?
>  
>
Oh...ahhh my mistake.

I misunderstood.  No I'm not the manager of GLEW.  My mind had 
understood you meant the gljava mailing list and not the glew :-(

They seem to be pretty active and keep cranking out the releases.  I'm 
not sure why there is not much mailing list traffic.

>>>Ivan -- do you have a GNU/Linux box around for testing
>>>sdljava? I'm guessing you're on some version of MS Windows.
>>>
>>> 
>>>      
>>>
>>This is all coded from my gento box ... ;)
>>    
>>
>
>Nice. :)
>
>
>
>
>		
>____________________________________________________
>Start your day with Yahoo! - make it your home page 
>http://www.yahoo.com/r/hs 
> 
>
>
>-------------------------------------------------------
>SF.Net email is Sponsored by the Better Software Conference & EXPO
>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>_______________________________________________
>sdljava-users mailing list
>sdl...@li...
>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>  
>