Show Posts
|
|
Pages: [1]
|
|
1
|
Java Game APIs & Engines / JOGL Development / Re: New JOGL binaries: September 5
|
on: 2003-09-09 23: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 14:11:48
|
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
|
|
|
|
|
4
|
Java Game APIs & Engines / JOGL Development / Re: JOGL Exposed
|
on: 2003-06-23 04: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-23 00: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 21: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 19:58:16
|
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 19: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
|
|
|
|
|
10
|
Java Game APIs & Engines / JOGL Development / Re: Basic Hello World app not rendering
|
on: 2003-06-22 17: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.*; public class Vectrix implements GLEventListener { private boolean setCameraInReshape = true;
public static Vectrix app = new Vectrix(); private Frame frame; private Animator animator; private GLCanvas canvas; private Vectrix() { System.out.println("Vectrix instance created"); GLCapabilities caps = new GLCapabilities(); caps.setDoubleBuffered(true); caps.setAlphaBits(8); caps.setStencilBits(8); canvas = GLDrawableFactory.getFactory().createGLCanvas(caps); canvas.addGLEventListener(this); canvas.setGL(new DebugGL(canvas.getGL())); 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); } } ); 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(); app.run(); } 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) { 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) { gl.glMatrixMode(GL.GL_PROJECTION); gl.glOrtho(0, 4, 0, 3, -8, 8); gl.glMatrixMode(GL.GL_MODELVIEW); } gl.glPushMatrix(); { 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();
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) { GL gl = arg0.getGL();
System.out.println("Vectrix.init(): GL reshape event " + arg1 + " " + arg2 + " " + arg3 + " " + arg4);
if (setCameraInReshape) { 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 22: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 21: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 21: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 21: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.htmlUnfortunately, 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 21: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
|
|
|
|
|
|
Add your game by posting it in the WIP section,
or publish it in Showcase.
The first screenshot will be displayed as a thumbnail.
|
|