Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (492)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (556)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  Experiences of migrating from JOGL 1.1.1 to JSR231  (Read 32324 times)
0 Members and 1 Guest are viewing this topic.
Offline DaveLloyd

Junior Member




Making things happen fast with Java!


« Posted 2006-03-13 17:32:21 »

Just thought I'd record my experiences of refactoring a fairly large OGL application from using the old 1.1.1 to the new JS231 (beta 03 to be specific). Many of these are noted elsewhere (might be worth collating into a migration doc) but repeated here for completeness.

  • Global replace net.java.games.jogl with javax.media.opengl
  • GLU is now in javax.media.opengl.glu which requires an additional step
  • GLU objects are created ab initio with new GLU () - no need to keep pulling them out of the Drawable (but note the one per thread limit)
  • Replace GLDrawable with GLAutoDrawable
  • Except: GLDrawable no longer includes getSize () (any reason not to?)
  • All GL calls where you pass in an array you need to add an extra offset parameter - 0 when refactoring (aside: this is particularly tedious and inelegant - do the extra method bindings really matter?)
  • Some calls which used to allow a direct array argument now needs IntBuffer.wrap (array)  (e.g., glDrawPixels)
  • Consequently it would be really useful if you could go straight from a java.awt.image.DataBuffer to a java.nio.Buffer
  • Some GL calls which used to be an ARB or vendor extension are gone and (generally) just knock off the ARB etc to get it to work (e.g., glActiveTexture)
  • The Animator class is now in com.sun.opengl.util for some reason (??)
  • Looks like  noAutoRedrawMode is no longer needed

The good news for anyone else who has to do this is that after going through a tedious half day of refactoring, it did just work once it successfully compiled. I'm sure I'll find an odd gotcha yet to come - the main one that worries me is the necessity to rewind buffers now (but I don't think any of mine should be anywhere other than 0).

And some other random thoughts while doing this:
  • Common calls such as glLightfv, glMaterialfv and glFogfv with a colour argument could do with a convenience method binding with 4 floats
  • Now that GLU is pure Java could we have some more friendly signatures to some methods?, e.g., gluUnproject (Vector3f, Matrix4f, Matrix4f, int [], Vector3f)
  • In fact can we go one step further and support javax.vecmath.Matrix4f/Vector3f throughout the apis?

Offline Ken Russell

JGO Coder




Java games rock!


« Reply #1 - Posted 2006-03-13 20:49:08 »

Thanks for posting this. I've made the topic sticky to make it easier for others to find this information.
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #2 - Posted 2006-03-15 03:15:02 »

I've converted all of the NeHe tutorials that had JOGL code to use the new JSR 231 APIs.  I have to fix it up a bit more, but when I have it ready I will zip up the source and the NetBeans project files (Ant stuff) and post it somewhere.
I am finally starting to learn OpenGL.

Some other points:

- BufferUtils is now BufferUtil
- GLCanvas is constructed with new GLCanvas() instead of the old factory method.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #3 - Posted 2006-03-15 07:28:50 »

Great to hear. Are you talking with pepijnve on these forums? He has ports of some of the NeHe demos on this page -- it would be great if you two could coordinate. I'm sorry I haven't been more proactive in updating the main JOGL pages to point to more of this stuff -- if you or anyone else wants to help organize some of these links please let me know. Or consider updating the wiki.
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #4 - Posted 2006-03-15 14:43:57 »

Actually I noticed pepijnve's message just after I posted.  I didn't even know he had so many more of the NeHe code ported to JOGL 1.1 than I found on the NeHe site... I suspect he is well ahead of me.  I only had lessons 1-14 and I'm mostly done the conversion, they all compile but I have a few kinks to work out with resource loading in some of the later lessons.  (I'm bundling the resources in the .jar produced by the NetBeans project)

If he wants some help I will try to be of assistance.

Offline vernier

Senior Newbie




Java rock!


« Reply #5 - Posted 2006-03-16 05:05:29 »

Other difference between 1.1 and JSR231, the Version object returning the jogl version disapeared

It took me time to understand the rewind trick. Here is a piece of code making a texture from a BufferedImage
(some of the code is maybe useless)

    GL1.glClearColor(1.0f, 1.0f, 1.0f, 0.0f);
    GL1.glColor3f(0.0f, 0.0f, 0.0f);
    GL1.glPointSize(1.0f);
    GL1.glEnable(GL1.GL_BLEND);
    GL1.glBlendFunc(GL1.GL_SRC_ALPHA, GL1.GL_ONE_MINUS_SRC_ALPHA);
    GL1.glEnable(GL.GL_TEXTURE_2D);

    BufferedImage  BufferedImage1  = new BufferedImage(512, 512, BufferedImage.TYPE_3BYTE_BGR);

    int[]          tmp             = new int[1];
    GL1.glGenTextures(1, tmp, 0);
    TextureChart         = tmp[0];
    GL1.glBindTexture(GL.GL_TEXTURE_2D, TextureChart);

    ByteBuffer     dest            = null;
    byte[]         data            = ((DataBufferByte)BufferedImage1.getRaster().getDataBuffer()).getData();
    dest = ByteBuffer.allocateDirect(data.length);
    dest.order(ByteOrder.nativeOrder());
    dest.put(data, 0, data.length);
    dest.rewind();
// <- NEW STUFF NEEDED BY JSR231
    GL1.glTexImage2D(GL.GL_TEXTURE_2D, 0, GL.GL_RGB, 512, 512, 0, GL.GL_RGB, GL.GL_UNSIGNED_BYTE, dest);
    GL1.glTexParameteri(GL.GL_TEXTURE_2D,GL.GL_TEXTURE_MIN_FILTER,GL.GL_LINEAR);
    GL1.glTexParameteri(GL.GL_TEXTURE_2D,GL.GL_TEXTURE_MAG_FILTER,GL.GL_LINEAR);


Otherwise I have an exception with the new JSR version. Can someone help ?
$ /cygdrive/c/Program\ Files/Java/jdk1.6.0/bin/java -cp jogl-demos.jar demos.gears.Gears
INIT GL IS: com.sun.opengl.impl.GLImpl
Exception in thread "Thread-2" GL_VENDOR: NVIDIA Corporation
GL_RENDERER: Quadro FX Go700/AGP/SSE2
GL_VERSION: 2.0.1
javax.media.opengl.GLException: java.lang.UnsatisfiedLinkError: glGenLists
        at javax.media.opengl.Threading.invokeOnOpenGLThread(Threading.java:205)
        at javax.media.opengl.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas.java:234)
        at javax.media.opengl.GLCanvas.display(GLCanvas.java:127)
        at com.sun.opengl.util.Animator.display(Animator.java:144)
        at com.sun.opengl.util.Animator$MainLoop.run(Animator.java:181)
        at java.lang.Thread.run(Thread.java:620)
Caused by: java.lang.UnsatisfiedLinkError: glGenLists
        at com.sun.opengl.impl.GLImpl.glGenLists(Native Method)
        at demos.gears.Gears.init(Gears.java:71)
        at com.sun.opengl.impl.GLDrawableHelper.init(GLDrawableHelper.java:71)
        at javax.media.opengl.GLCanvas$InitAction.run(GLCanvas.java:242)
        at com.sun.opengl.impl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:123)
        at javax.media.opengl.GLCanvas$DisplayOnEventDispatchThreadAction.run(GLCanvas.java:276)
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:199)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
        at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)


Offline Ken Russell

JGO Coder




Java games rock!


« Reply #6 - Posted 2006-03-16 08:11:55 »

Otherwise I have an exception with the new JSR version. Can someone help ?
javax.media.opengl.GLException: java.lang.UnsatisfiedLinkError: glGenLists

Somebody just reported this exact problem; you have a mismatched jogl.dll and jogl.jar.

FYI, you can now get the version information for JOGL using java.lang.Package. See demos.misc.VersionInfo in the jogl-demos workspace.
Offline pepijnve

Junior Member




Java games rock!


« Reply #7 - Posted 2006-03-20 20:19:50 »

In VBO related code, the pointer passed to glVertexPointer, glTexCoordPointer, ... is used as an offset in the VBO.
In JSR-231, glVertexPointer for instance maps to two distinct functions:
1  
glVertexPointer(int size, int type, int stride, Buffer ptr)

and
1  
glVertexPointer(int size, int type, int stride, long offset)


Pre JSR-231 code that looked like this:
1  
2  
gl.glBindBufferARB(GL.GL_ARRAY_BUFFER_ARB, vbo);
gl.glVertexPointer(3, GL.GL_FLOAT, 0, null);


should be updated to
1  
2  
gl.glBindBufferARB(GL.GL_ARRAY_BUFFER_ARB, vbo);
gl.glVertexPointer(3, GL.GL_FLOAT, 0, 0);
Offline Ophir

Senior Newbie





« Reply #8 - Posted 2006-03-20 23:56:22 »

Quote
All GL calls where you pass in an array you need to add an extra offset parameter - 0 when refactoring (aside: this is particularly tedious and inelegant - do the extra method bindings really matter?)

I just started the big switch to JSR 231, and I agree.  I appreciate all the work that has gone into this effort but, at the risk of seeming picky, I may as well speak up now, rather than not at all.  After reading the original slides a couple of years ago, where it seemed the best of the best would be pulled from previous bindings, I expected a more elegent solution.  When a new user decides to try OpenGL and Java together, they'll punch in a simple example from the Red Book, and they'll hit this.  After all that has been overcome to create these bindings, there isn't room for overloaded bindings that look like classic OpenGL?
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #9 - Posted 2006-03-21 00:20:04 »

Well, I think the ByteBuffer variant makes more sense anyway.. so I agree that it isn't worth the effort to add more overloaded members to the Array versions.  If you don't want that extra parameter try using NIO Buffer-based method instead.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #10 - Posted 2006-03-21 08:28:50 »

Sorry the style isn't to your taste, but all of the Java APIs which take arrays (look all throughout java.io, for example) also typically take an offset argument, specifically because Java doesn't have pointer arithmetic like C. As swpalmer points out, you can always use the NIO variants if you don't want to pass the extra parameter, because Buffers implicitly have an offset (the position of the buffer). At least for the initial release of the JSR, we will not be adding overloaded variants for arrays without the offset parameter. If there is high demand for this we can add such convenience methods in a future update without breaking backward compatibility.
Offline Ophir

Senior Newbie





« Reply #11 - Posted 2006-03-21 21:24:07 »

OK, so my opinion has been registered.  I can live with the extra comma and zero.

Quote
Some calls which used to allow a direct array argument now needs IntBuffer.wrap (array)  (e.g., glDrawPixels)

One variant of glDrawPixels takes Buffer pixels and the other takes long pixels_buffer_offset .  What is the difference, and how would you convert JOGL code to the latter?

Thanks.
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #12 - Posted 2006-03-22 02:13:37 »

glDrawPixels is one of the APIs affected by the ARB_pixel_buffer_extension. Take a look at the documentation for that extension to see how it is used. All APIs affected by the vertex_buffer_object and pixel_buffer_object extensions have additional overloadings taking the long offset into the buffer object for security reasons. There are checks in the JOGL implementation to make sure that the extension is appropriately enabled or disabled when each overloading is called.
Offline zero

Junior Member





« Reply #13 - Posted 2006-03-22 02:41:09 »

And some other random thoughts while doing this:
  • ...
  • Now that GLU is pure Java could we have some more friendly signatures to some methods?, e.g., gluUnproject (Vector3f, Matrix4f, Matrix4f, int [], Vector3f)
  • In fact can we go one step further and support javax.vecmath.Matrix4f/Vector3f throughout the apis?

Please never integrate any math package into GL/GLU directly. There are lots of diffrent math packages out there, and doing that would favor one. IMHO that's no ok, even for javax.vecmath since OpenGL is math api independent.

@DaveLloyd
If it is the easy of use, you want. Just derivate from the GLU class and extend it with the methods for the vector classes you like.
Offline DaveLloyd

Junior Member




Making things happen fast with Java!


« Reply #14 - Posted 2006-03-23 11:21:20 »

Quote
Please never  integrate any math package into GL/GLU directly. There are lots of diffrent math packages out there, and doing that would favor one. IMHO that's no ok, even for javax.vecmath since OpenGL is math api independent.
I'm sorry, but I couldn't disagree more! The greatest strength of Java is its broad and consistent set of APIs. When you have a task in front of you, unlike with C++, you don't have to choose between half a dozen different APIs (e.g, STL or MFC? Just for lists and things), there is just one that all other packages work cleanly with. The real bane for me with 3D is that when I work with some new software package the odds are that it uses a different vector package (GLEEM uses its own for example) and all of a sudden I do not have portable code. Remember: write once, run anywhere!

Vector algebra is a real basic of what we're doing here. Perhaps we need the JCP to reexamine the javax.vecmath package (which I agree is sufficient but not very useable - though Java's lack of user defined operators doesn't help there).

Offline K.I.L.E.R

Senior Member




Java games rock!


« Reply #15 - Posted 2006-03-25 23:33:38 »

I already build ontop of LWJGL's math libs.
I *WISH* JOGL had some in there.
You could even consider GLUT(Not confused with GLU) methods to be a total waste but they are in JOGL too.
So why not actually add something more helpful like a math library for vectors, quaternions and matrices?

What's worse is that no one offers any buffered operations on math libs.


And some other random thoughts while doing this:
  • ...
  • Now that GLU is pure Java could we have some more friendly signatures to some methods?, e.g., gluUnproject (Vector3f, Matrix4f, Matrix4f, int [], Vector3f)
  • In fact can we go one step further and support javax.vecmath.Matrix4f/Vector3f throughout the apis?

Please never integrate any math package into GL/GLU directly. There are lots of diffrent math packages out there, and doing that would favor one. IMHO that's no ok, even for javax.vecmath since OpenGL is math api independent.

@DaveLloyd
If it is the easy of use, you want. Just derivate from the GLU class and extend it with the methods for the vector classes you like.

Vorax:
Is there a name for a "redneck" programmer?

Jeff:
Unemployed. Wink
Offline zingbat

Senior Member




Java games rock!


« Reply #16 - Posted 2006-04-05 23:47:06 »

Vectors and matrices are fundamental data structures. I would like to see them added but as primitves with special suport by the java vm. Just adding a common non-accelerated math api would not make much sense.
Offline K.I.L.E.R

Senior Member




Java games rock!


« Reply #17 - Posted 2006-04-08 05:41:08 »

I would like 3 sets of matrices in the library:
3x3
4x4
n x m

The question is who do we make the request to?

Vorax:
Is there a name for a "redneck" programmer?

Jeff:
Unemployed. Wink
Offline zingbat

Senior Member




Java games rock!


« Reply #18 - Posted 2006-04-14 21:09:47 »

What is the problem with using javax.vecmath from the the java3d project?

It has Matrix3d, Matrix3f, Matrix4d, Matrix4f and GMatrix.
Offline Jo

Junior Newbie





« Reply #19 - Posted 2006-08-02 11:44:19 »

As I migrate my application to JSR231, I have a question about [size=10pt]nio.Buffer[/size] performance. In many cases (e.g.  [size=10pt]glLightfv()[/size]), I have a choice to use a primitive array with the extra 0 offset parameter or to supply an [size=10pt]nio.Buffer[/size]. Is there much of a performance hit in wrapping an array in an [size=10pt]nio.Buffer[/size]? While I can't imagine it would be faster to supply the [size=10pt]nio.Buffer[/size], there are some cases where the type of array is not specified (e.g. [size=10pt]glReadPixels()[/size]) and so I am forced to provide one.

Thanks,

Jo.
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #20 - Posted 2006-08-02 15:42:13 »

The overhead of wrapping an array in a Buffer is negligible. The Buffer objects are small and will be quickly reclaimed during the next young generation garbage collection. This should save you the overhead of tracking both the Buffer and the array throughout your system.
Offline Malek

Junior Member




Java games rock!


« Reply #21 - Posted 2006-09-19 15:50:58 »

Hi,

Seing the brand new release of jogl i have decided to shift my old version to the new one.
Made the changes which often made my code simpler and cleaner. So firstly thanks for that ;-)

However at run time i got a nasty crash at the moment i am trying to load one FloatBuffer into the VRAM.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
if(hasVBO)
      {
      VBOs=BufferUtil.newIntBuffer(3);
      gl.glGenBuffersARB(3, VBOs);
      gl.glBindBufferARB(GL.GL_ARRAY_BUFFER_ARB, VBOs.get(0));
gl.glBufferDataARB(GL.GL_ARRAY_BUFFER_ARB, nvertex * 3 * BufferUtil.SIZEOF_FLOAT, vertices, GL.GL_STATIC_DRAW_ARB);  <-----------------
      gl.glBindBufferARB(GL.GL_ARRAY_BUFFER_ARB, VBOs.get(1));
      gl.glBufferDataARB(GL.GL_ARRAY_BUFFER_ARB, nvertex * 2 * BufferUtil.SIZEOF_FLOAT, texCoords, GL.GL_STATIC_DRAW_ARB);

      gl.glBindBufferARB(GL.GL_ARRAY_BUFFER_ARB, VBOs.get(2));  
      gl.glBufferDataARB(GL.GL_ARRAY_BUFFER_ARB, nvertex * 3 * BufferUtil.SIZEOF_FLOAT, normals, GL.GL_STATIC_DRAW_ARB);
   
      normals=null;
      vertices=null;
      texCoords=null;
      }

The crash i got is an ACCESS_VIOLATION_EXCEPTION with the trace as follow. This was working perfectly fine before so i do not know what new thing deep inside could cause this? any one got the same problem.

If need more information please tell me and i will post everything you would need to solve the prob.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x69661988, pid=2260, tid=4000
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode)
# Problematic frame:
# C  [nvoglnt.dll+0x161988]
#

---------------  T H R E A D  ---------------

Current thread (0x0b1d4ad0):  JavaThread "AWT-EventQueue-0" [_thread_in_native, id=4000]

siginfo: ExceptionCode=0xc0000005, reading address 0x0beab004

Registers:
EAX=0x000761cc, EBX=0x0c75c800, ECX=0x00001d87, EDX=0x0bea90cc
ESP=0x0b7df520, EBP=0x0b7df53c, ESI=0x0beaafcc, EDI=0x0ebaaf00
EIP=0x69661988, EFLAGS=0x00010206

Top of Stack: (sp=0x0b7df520)
0x0b7df520:   0cd100c0 0cc6f400 0c75c800 00000000
0x0b7df530:   00000001 00000002 69638fdd 0cd18fe8
0x0b7df540:   6963830d 0eba9000 0bea90cc 000780cc
0x0b7df550:   0c75c800 00000000 00000000 00000000
0x0b7df560:   69639673 0cd100c0 0c75c800 00000000
0x0b7df570:   000780cc 0bea90cc 0c75c800 0cd100c0
0x0b7df580:   00008892 695671d7 0cd100c0 00008892
0x0b7df590:   000088e4 0c75c800 000780cc 00000000

Instructions: (pc=0x69661988)
0x69661978:   e9 06 8d 9b 00 00 00 00 0f 10 46 10 0f 10 4e 20
0x69661988:   0f 10 56 30 0f 10 1e 0f 2b 1f 0f 2b 47 10 0f 2b


Stack: [0x0b7a0000,0x0b7e0000),  sp=0x0b7df520,  free space=253k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [nvoglnt.dll+0x161988]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  com.sun.opengl.impl.GLImpl.dispatch_glBufferDataARB0(IILjava/lang/Object;IIJ)V+0
j  com.sun.opengl.impl.GLImpl.glBufferDataARB(IILjava/nio/Buffer;I)V+52   <-----------------
j  Hege3D.banqueObjets.Arbre.InitArbre(Ljavax/media/opengl/GL;Z)V+118
j  Hege3D.banqueObjets.Objets.InitObjets(ZLjavax/media/opengl/GL;Ljavax/media/opengl/glu/GLU;)V+729
j  Hege3D.interfacesGraphique.Scene3D.init(Ljavax/media/opengl/GLAutoDrawable;)V+154


Thanks
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #22 - Posted 2006-09-20 07:20:04 »

Did you call rewind() on your vertices buffer before passing it down to OpenGL? The positions of Buffers are significant in JSR-231, which is a difference from earlier JOGL versions (in the net.java.games.jogl.* namespace).
Offline Malek

Junior Member




Java games rock!


« Reply #23 - Posted 2006-09-20 08:21:25 »

rewind did the trick!

I think it is worth to say that it is general to any method from the JSR api that uses Buffers, all of them need to have a rewind() call before they are used for the first time ;-).
Offline adi

Innocent Bystander





« Reply #24 - Posted 2007-08-28 19:24:16 »

I already build ontop of LWJGL's math libs.
I *WISH* JOGL had some in there.
You could even consider GLUT(Not confused with GLU) methods to be a total waste but they are in JOGL too.
So why not actually add something more helpful like a math library for vectors, quaternions and matrices?

What's worse is that no one offers any buffered operations on math libs.


Please never integrate any math package into GL/GLU directly. There are lots of diffrent math packages out there, and doing that would favor one. IMHO that's no ok, even for javax.vecmath since OpenGL is math api independent.

@DaveLloyd
If it is the easy of use, you want. Just derivate from the GLU class and extend it with the methods for the vector classes you like.

Offline safari

Innocent Bystander





« Reply #25 - Posted 2009-10-21 21:21:31 »

I have a project I haven't worked on for sometime, and now I tried to import it to (from NetBeans) Eclipse and use JOGL 2. All seems fine, except some constants and methods aren't found.. I've searched and found really nothing on it although I'm sure the explanation is somewhere...
Well the problem is:


    gl.glMatrixMode(GL.GL_PROJECTION); GL_PROJECTION not found, also GL_MODELVIEW_MATRIX not found.. and other..
    gl.glLoadIdentity(); <- not found

      gl.glBegin(GL.GL_LINES); glBegin not found
        gl.glVertex3f(1.3f, -1.0f, 0.0f); glVertex... not found
        gl.glVertex3f(1.3f, -1.0f, 8.1f);
      gl.glEnd();

      gl.glPushMatrix(); not found.. pop not found also..

My imports..
import java.awt.event.*;
import javax.media.opengl.GL;
import javax.media.opengl.*;
import javax.media.opengl.awt.GLCanvas;
import javax.media.opengl.glu.*;
import javax.swing.*;
import java.awt.Frame;
import java.awt.Label;
import java.awt.TextArea;
import javax.media.opengl.glu.GLU;
import java.util.Timer;
import java.util.TimerTask;
import com.sun.opengl.util.*;
import com.sun.opengl.util.gl2.GLUT;

Can anyone point me in the right direction? Thanks..! Smiley
Offline rbrown

Innocent Bystander





« Reply #26 - Posted 2009-11-17 00:07:15 »

I am having the same problems.  Has anyone found out the answers?
Offline teacup775

Junior Newbie





« Reply #27 - Posted 2009-11-20 05:40:43 »

warning complete newbie advise: I've succeeded after some _considerable_ pawing around for java demo source, to get Gears.java up and running through Eclipse. You might need to change your code around a bit.

I think the issue is that the APIs have changed:

   GL2 gl = drawable.getGL().getGL2();
...
           
    gl.glMatrixMode(GL2.GL_PROJECTION);


source: http://kenai.com/projects/jogl/sources/jogl-demos-git/content/src/demos/gears/Gears.java?rev=2d5f1650af2b64f7a8d25842b2b95192b3e4a4e9

Come back here! I'll gum you to death!
Offline gouessej
« Reply #28 - Posted 2012-11-20 08:00:02 »

@teacup775, @rbrown, @safari JOGL 2.0 public APIs have changed a lot as it is explained here. The main GL interface has been divided into several smaller ones as you can see in the documentation.

Offline ra4king

JGO Kernel


Medals: 345
Projects: 3
Exp: 5 years


I'm the King!


« Reply #29 - Posted 2012-11-20 08:42:59 »

WTF this is exactly 3 years old!

Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Nickropheliac (15 views)
2014-08-31 22:59:12

TehJavaDev (23 views)
2014-08-28 18:26:30

CopyableCougar4 (33 views)
2014-08-22 19:31:30

atombrot (41 views)
2014-08-19 09:29:53

Tekkerue (40 views)
2014-08-16 06:45:27

Tekkerue (35 views)
2014-08-16 06:22:17

Tekkerue (25 views)
2014-08-16 06:20:21

Tekkerue (37 views)
2014-08-16 06:12:11

Rayexar (72 views)
2014-08-11 02:49:23

BurntPizza (49 views)
2014-08-09 21:09:32
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!