Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (489)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (555)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1]
1  Java Game APIs & Engines / JOGL Development / Re: New JOGL binaries: September 5 on: 2003-09-09 21:38:20
This is definitely a bug in either the version-string parsing code I wrote, or ATI didn't follow the spec. It's a weird looking version string; I believe the string is supposed to be in the format XXX.YYY.ZZZ but this needs confirmation.

Either way, it's fairly easy to fix; the code is pretty simple. I'd fix it myself but I don't have the latest JOGL source installed.

-chris
2  Java Game APIs & Engines / JOGL Development / Re: JOGL swapBuffer / flush on: 2003-07-18 12:11:48
Quote
I know that in LWJGL that the flush takes a long time.  So basically you can send all the commands to the card but when you call flush there is this long pause while it actually finishes rendering.  It seems like the request to draw the Drawable and the resulting callback to the event listener does not return until the flush is complete.


As another person mentioned, there is a difference between and explicit glFlush(), an explicit glFinish(), and an implicit finish caused by a buffer swap.

In general, glFlush() is a bad thing because it forces the driver to finish executing all glCommands before returning control to the caller. When using glFinish() or doing a buffer swap (which JOGL does internally at the end of each frame), it merely tells the graphics driver to begin processing commands and then returns control back to the user. This facilitates parallelism by allowing your app to continue processing while the card is busy flushing queued events.

So, in general, if you're using JOGL you neither have to nor need to do make calls to glFlush(), glFinish(), or SwapBuffers(HDC). Calling glFlush() explicity shouldn't cause any harm, but it will certainly kill your performance.

-chris
3  Java Game APIs & Engines / JOGL Development / Re: EXCEPTION_ACCESS_VIOLATION when using JToolbar on: 2003-06-24 01:48:04
I'm not sure what the source of your problem is, but you should submit a bug report. Official bug reports can be submitted at:

http://games-core.dev.java.net/

In the section titled "Issue Tracking". The link is at the top left on the page listed above.

-chris
4  Java Game APIs & Engines / JOGL Development / Re: JOGL Exposed on: 2003-06-23 02:47:28
It would be easy to modify BuildComposablePipeline.java to emit another pipeline which contained non-prefixed calls wrapping their prefixed base methods (e.g., color3f() calling glColor3f()). This modification would probably take 10 minutes, tops.

This would, as Jason suggested, give you the best of both worlds.

-chris
5  Java Game APIs & Engines / JOGL Development / Re: Dl-ed and Build :-) on: 2003-06-22 22:25:11
We showed Jogl running on MacOS X at JavaOne; unfortunately that version of Jogl only had support for the Cocoa libraries (no AWT) and hence not ready for prime time.

I received email today from Gerard Ziemski, the engineer at Apple working on the Mac version. He has Jogl working with AWT but there's still some issues to be ironed out. Hopefully he'll have something robust available soon.

-chris
6  Java Game APIs & Engines / JOGL Development / Re: Basic Hello World app not rendering on: 2003-06-22 19:14:21
After some experimentation, I now believe that my previous bug report is in fact not a bug. If you change all the calls around glOrtho() to look like this:

gl.glMatrixMode(gl.GL_PROJECTION)
gl.glLoadIdentity()
gl.glOrtho(...)
gl.glMatrixMode(gl.GL_MODELVIEW)

the app works correctly regardless of the value of setCameraInReshape.  

Without the call to glLoadIdentity, the camera matrix is being incrementally adjusted each frame, because glOrtho() creates a projection matrix and multiplies it by the current matrix.

Also, without setting the glMatrixMode back to ModelView, your glTranslate/rotate operations were affecting the camera instead of the vertices.

Based on this discovery, I have declared that issue not-a-bug.

However, there was a bug in the DebugGL. I ran the JoglTest program you sent me and receive no errors at all from DebugGL. Then I realized that I was running in a source base that has been modified since the code was posted on java.net. There was a bugfix in DebugGL that was accidentally not merged into the java.net CVS tree; that bug would cause incorrect GLExceptions dealing with glBegin/glEnd.

I have fixed this in version 1.2 of BuildComposablePipeline.java; please update your CVS tree and rebuild. Sorry for the inconvenience!

-chris
7  Java Game APIs & Engines / JOGL Development / Re: Basic Hello World app not rendering on: 2003-06-22 17:58:16
Quote

That was my point  Its just another matrix manipulation - having glOrtho fail, yet glTranslatef and glRotatef work normally makes no sense.


Well, actually, it does make a little sense. glOrtho() is meant to be a projection matrix operation, and as such I believe it assumes that glViewport() has been called correctly already (something that is done under the hood in GLCanvas.reshape()). glTranslatef() makes no such assumptions since it operates on any matrix.

My guess is, like I said in an earlier post, is that the current implementation assumes that camera operations will be done in GLDrawable.reshape(), after the underlying canvas has called glViewport(). I believe this assumption is not realistic, and hence I filed the bug.

Regarding your stack trace, it's hard for me to diagnose since your line numbers do not match mine (and neither does the name of the class). If you posted the exact source file it would be easier to diagnose. Also, please post your modified Gears demo in entirety; I will need to see the modifications you made before coming to any conclusions.

-chris
8  Java Game APIs & Engines / JOGL Development / Re: Basic Hello World app not rendering on: 2003-06-22 17:00:37
Using an improper matrix mode will not trigger a GL error, you'll just get incorrect rendering results because you're modifying the modelview matrix (used to transform the vertices, etc) rather than the projection matrix (used to project world space vertices into camera space). I was just pointing it out because if you try to do anything more complicated with the camera in the future you would get incorrect rendering, and it would be a subtle bug to track down.

I have no idea why you're getting errors from the DebugGL when using the code I sent you. It runs fine on my machine (GeforceFX 5800, drivers 41.10) with DebugGL enabled. AFAIK DebugGL works fine. Could you paste a stack trace?

If you're getting errors with the unmodified Gears demo, something weird is definitely going on. What hardware and driver version are you using, and with what JVM version?

-chris
9  Java Game APIs & Engines / JOGL Development / Re: Basic Hello World app not rendering on: 2003-06-22 15:36:46
Just to follow up, I've posted a bug about this at

http://jogl.dev.java.net/issues/show_bug.cgi?id=14

I believe it is a threading issue that arises because the AWT canvas is reshaped in a different thread than the one that calls GLDrawable.reshape(). However, I defer to those who understand the AWT integration better than I do.

-chris
10  Java Game APIs & Engines / JOGL Development / Re: Basic Hello World app not rendering on: 2003-06-22 15:23:07
There are two problems here. First is a problem in your code, second is a problem with JOGL.

1) You are forgetting to switch the matrix mode to GL_PROJECTION before calling glOrtho(); as such you are affecting the model and not the camera. Also, though your code was correct, you comment for glOrtho() was wrong -- it's b/t not t/b

2) The reason you're not seeing your drawing is because you're not setting the camera inside resize(). Under the hood, JOGL calls glViewport() whenever the underlying canvas changes size (including when the frame is first shown), and then calls GLDrawable.reshape().  At this point in time the canvas extents have been sent to GL and your camera calls work fine.

However, I'm not sure why your app does not work when calling glOrtho() outside of reshaoe() -- AFAICT it should still work correctly modulo a one-frame error after a reshape.

This problem is reproducible. If you look at the code below, when setCameraInReshape = true the app renders fine; when set to false the app does not render.

I will file an issue on the project page.

-chris

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  
47  
48  
49  
50  
51  
52  
53  
54  
55  
56  
57  
58  
59  
60  
61  
62  
63  
64  
65  
66  
67  
68  
69  
70  
71  
72  
73  
74  
75  
76  
77  
78  
79  
80  
81  
82  
83  
84  
85  
86  
87  
88  
89  
90  
91  
92  
93  
94  
95  
96  
97  
98  
99  
100  
101  
102  
103  
104  
105  
106  
107  
108  
109  
110  
111  
112  
113  
114  
115  
116  
117  
118  
119  
120  
121  
122  
123  
124  
125  
126  
127  
128  
129  
130  
131  
132  
133  
134  
135  
136  
137  
138  
139  
140  
141  
142  
143  
144  
145  
146  
147  
148  
149  
150  
151  
152  
153  
154  
155  
156  
157  
158  
159  
160  
161  
162  
163  
164  
165  
166  
167  
168  
169  
170  
171  
172  
173  
174  
175  
176  
177  
178  
179  
180  
181  
182  
183  
184  
 
import java.awt.Frame;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;
 
import net.java.games.jogl.*;
 
/**
 *   Vectrix
 *  
 * @author John
 * @author Ckline modified to demostrate bug
 */

public class Vectrix implements GLEventListener
{
  // BUG REPRO: app does not render correctly when setCameraInReshape is false
 private boolean setCameraInReshape = true;

  public static Vectrix app = new Vectrix();
  
  private Frame frame;
  
  // private MouseHandler mouseHandler;
 private Animator animator;
  
 
  private GLCanvas canvas;
 
  /**
   *  
   */

  private Vectrix()
  {
    System.out.println("Vectrix instance created");
    
    // Canvas setup
   GLCapabilities caps = new GLCapabilities();
    caps.setDoubleBuffered(true);
    caps.setAlphaBits(8);
    caps.setStencilBits(8);
    canvas = GLDrawableFactory.getFactory().createGLCanvas(caps);
    
    //canvas = GLDrawableFactory.getFactory().createGLCanvas(new GLCapabilities());
   canvas.addGLEventListener(this);
    canvas.setGL(new DebugGL(canvas.getGL()));
    // Frame setup
   frame = new Frame("Vectrix");
    frame.add(canvas);
    frame.setSize(800, 600);
 
    frame.addWindowListener(
      new WindowAdapter()
      {
        public void windowClosing(WindowEvent e)
        {
          animator.stop();
          System.exit(0);
        }
      }
      );
  
    // Event handlers
   animator = new Animator(canvas);
  }
  
  public void initialiseDisplay()
  {
    frame.show();
  }
  
  public void run()
  {
    animator.start();
  }
 
  public static void main(String[] args)
  {
    System.out.println("Vectrix starting...");
  
    app = new Vectrix();
    app.initialiseDisplay();
  
    // Other loading/initialisation
   // ..
 
    // Start main game loop
   app.run();
  }
 
  
  // GL Event Listener methods
 
  // Called when GL has been initialised for the first time.
 public void init(GLDrawable canvas)
  {
    System.out.println("Vectrix.init(): GL init event");
  
    GL gl = canvas.getGL();
  
    gl.glMatrixMode(GL.GL_PROJECTION);
    gl.glLoadIdentity();
    gl.glMatrixMode(GL.GL_TEXTURE);
    gl.glLoadIdentity();
    gl.glMatrixMode(GL.GL_MODELVIEW);
    gl.glLoadIdentity();
    
  }
 
  public void display(GLDrawable canvas)
  {
    //System.err.println("DISPLAY THREAD: " + Thread.currentThread());
   GL gl = canvas.getGL();
    GLU glu = canvas.getGLU();
  
    gl.glClearColor(0.2f, 0.2f, 0.2f, 0.0f);
    gl.glClear(GL.GL_COLOR_BUFFER_BIT | GL.GL_DEPTH_BUFFER_BIT | GL.GL_STENCIL_BUFFER_BIT);
  
    if (!setCameraInReshape)
    {
      //   l/r  b/t  near/far
     gl.glMatrixMode(GL.GL_PROJECTION);
      gl.glOrtho(0, 4, 0, 3, -8, 8);
      gl.glMatrixMode(GL.GL_MODELVIEW);
    }
  
    gl.glPushMatrix();
    {
      // draw a polygon
     gl.glBegin(GL.GL_POLYGON);
      gl.glColor3f(1f, 0f, 0f);
      gl.glVertex3f(.25f, .25f, 0f);
      gl.glVertex3f(.75f, .25f, 0f);
      gl.glVertex3f(.75f, .75f, 0f);
      gl.glVertex3f(.25f, .75f, 0f);
      gl.glEnd();  

      // draw some lines
     gl.glBegin(GL.GL_LINES);
      {
        int xMin = 0;
        int xMax = 10;
        gl.glColor3f(1f, 0f, 0f);
    
        for (int x=xMin; x<=xMax; x++)
        {
          gl.glVertex3f(x, -1, 0f);
          gl.glVertex3f(x, +1, 0f);
  
        }
    
        gl.glVertex3f(0f, 0f, 0f);
        gl.glVertex3f(4f, 4f, 4f);
    
      }
      gl.glEnd();
      
    }
    gl.glPopMatrix();
  
  }
 
 
  public void reshape(GLDrawable arg0, int arg1, int arg2, int arg3, int arg4)
  {
    //System.err.println("RESHAPE THREAD: " + Thread.currentThread());
   GL gl = arg0.getGL();

    System.out.println("Vectrix.init(): GL reshape event " + arg1 + " " + arg2
                       + " " + arg3 + " " + arg4);

    if (setCameraInReshape)
    {
      //   l/r  b/t  near/far
     gl.glMatrixMode(GL.GL_PROJECTION);
      gl.glOrtho(0, 4, 0, 3, -8, 8);
    }

  }
 
  public void displayChanged(GLDrawable arg0, boolean arg1, boolean arg2)
  {
 
  }
}
11  Java Game APIs & Engines / JOGL Development / Re: Better tracing output - patch on: 2003-06-21 20:16:03
Yes, you're right. The composable pipeline builder works purely via reflection, and doesn't have any info about the Types of the function arguments. I did it this way initially just because it was the fastest way to get a composable pipeline built.

In light of this, perhaps I'll sink some time into building an emitter a la GLEmitter so that we can generate the pipeline classes with full knowledge of type information.

-chris
12  Java Game APIs & Engines / JOGL Development / Re: Better tracing output - patch on: 2003-06-21 19:38:43
Awesome! This is the style TraceGL that Magician used, and it's very handy. I wanted to implement it for JOGL but just didn't have time.

Some more nice things to add at some point would be support for indenting the stuff between glBegin*()/glEnd*() pairs, and outputting the actual constant name (e.g., GL_LIGHT0) instead of its integer value. That shouldn't be too hard to do with reflection.

chris
13  Java Game APIs & Engines / JOGL Development / Re: Paramater names for glext functions on: 2003-06-21 19:32:32
Oh, also, to answer your question about the typedef names-- you should be able to get the names of the arguments out of the function typedef. In each JavaEmitter (of which GLEmitter is a subclass) there is a 'typedefDictionary' variable. This variable is of type TypeDictionary, which maps a type name (String) to a Type object that corresponds to that name. In the case of function pointer typedefs, like

typedef void (APIENTRY * PFNGLSECONDARYCOLOR3BEXTPROC) (GLbyte red, GLbyte green, GLbyte blue);  

a call of typedefDictionary.get("PFNGLSECONDARYCOLOR3BEXTPROC") should return a FunctionType object, which is a subclass of Type. You can query this object with getArgumentName(int) to get the name of each argument in the function.

You could easily modify GLEmitter to, when emitting the name of a function argument, query the function pointer typedef for the arg name in the case where both 1) the function is a gl extension function (i.e., needsProcAddressWrapper() returns true) and 2) the argument in the raw function symbol is unnamed (i.e., arg0).

If it helps, theres some code in GLEmitter.java in the function needsProcAddressWrapper(FunctionSymbol) that calculates the appropriate typedef name given the symbol corresponding to a gl extension function.

-chris
14  Java Game APIs & Engines / JOGL Development / Re: Paramater names for glext functions on: 2003-06-21 19:18:18
GlueGen does its best to emit proper names for arguments. It will emit the correct name if the args are named in the function prototype. E.g., the Java/JNI equivalents for

GLAPI void APIENTRY glSecondaryColor3bEXT (GLbyte, GLbyte, GLbyte);

Will use the arg0...argN names, but the emitted equivalents for

GLAPI void APIENTRY glSecondaryColor3bEXT (GLbyte red, GLbyte green, GLbyte blue);

The easiest and most correct way to get properly named functions emitted is to add the correct names to the prototypes in gl.h/glext.h/glxext.h/etc. The reason I didn't do this the first time around was (besides the obvious gruntwork involved) because I wanted to make it easy to update JOGL when a new glext.h header was released at the extension registry page:

http://oss.sgi.com/projects/ogl-sample/registry/index.html

Unfortunately, though those are the "official" OpenGL headers, they don't have argument names in them. It would be nice if someone updated those headers with the correct names and had the ARB re-post them.

Otherwise you're welcome to insert the correct argument names into JOGL's stub versions of the GL headers, and donate them back to the JOGL source tree.

-chris
15  Java Game APIs & Engines / JOGL Development / Re: Jogl - No explicit glSwapBuffers & glEnd o on: 2003-06-18 19:24:23
Oops! That commented-out "deliberate error" glEnd oddity is some debugging code I left in when I was testing the DebugGL component of the composable pipeline. What I was doing there was doing two glEnd() calls in a row, which is illegal, and making sure that DebugGL caught that error.

That call is commented out in the demo, and can safely be ignored (it should be removed from the Gears demo).

As for glSwapBuffers(), you are correct -- this is handled automatically by the GLCanvas and GLJPanel classes. The reason is that there is no need to expose these calls, and by not exposing them we can both hide all the platform-dependent special case code for window system interactions, and and also ensure that AWT/Swing threading issues are handled correctly.

You can definitely drive your demos without using the Animator. We have several demos that do this (by doing essentially the same work that the Animator does) , but I do not think that they are available online yet. I know some people at Sun are working hard to get these available ASAP.

-chris
Pages: [1]
 

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 (12 views)
2014-08-31 22:59:12

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

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

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

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

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

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

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

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

BurntPizza (47 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!