Instead of compiling Jogl for yourself, you can also download the binary archive for the current supported platforms from
http://jogl.dev.java.net/servlets/ProjectDocumentList1 2 3 4 5 6 7 8 9 10 11 12 13
| public void display(GLDrawable drawable) { gl.glclear( GL.GL_COLOR_BUFFER_BIT );
gl.glColor3f( 0.0f, 1.0f, 0.0f ); gl.glBegin( GL.GL_POLYGON ); gl.glVertex2f( 0.0f, 0.0f ); gl.glVertex2f( 1.0f, 0.0f ); gl.glVertex2f( 0.0f, 1.0f ); gl.glEnd(); gl.glFlush(); } |
The flush()-command isn't necessary AFAIK. According to the user's manual
http://jogl.dev.java.net/unbranded-source/browse/*checkout*/jogl/doc/userguide/index.html it's advisable to set the gl and glu variables every time in the reshape and display event-handler methods.
1 2
| GL gl = drawable.getGL(); GLU glu = drawable.getGLU(); |
But this shouldn't be the problem at your side, where the triangle is dark red. :)
Well, I've to set the camera back a bit in order to see your triangle. So between your clClear and the glColor I've to do:
1 2
| o.glLoadIdentity(); o.glTranslated(0, 0, -10); |
Then the triangle is green, as you specified it.
Still, this doesn't explain why you're triangle is dark red. :-) Do you issue some exotic commands in the initial init() method of your render class?
My game currently has a render class that all sprites register themselves with. When it comes time to draw the frame the renderer's Graphic object is passed around to everyone and they all do their thing. Is this a feasable approach with jogl? Obviously not a Graphics object, but perhaps a small inner class of my renderer that accepts an image and coordinates and draws it to the GLCanvas with I assume glDrawPixels or something like it?
I'm not sure if I understood you correctly, but in OpenGL - and also Jogl -
all drawing happens in the display-method of your render class which implements GLEventListener. There you can of course fetch all your registered sprite classes and call their render method (with parameters "GL gl" and "GLU glu") which then just issue the appropriate glCommands.
Or did you mean it that way?
I'm also curious on the whole pasting sprites onto polygons as textures vs just blitting the sprites as is. In searching (not just these forums but the internet for openGL stuff in general) I've found it split about 50/50. It seems that generally the more game oriented people seem to prefer the polygon/texture route. Should that be the way I head? I have a feeling that'd drastically change my game's structure.
Unfortunately I can't judge this from experience. However I read that today's 3d cards are really optimized for texture polygons so they're not slower than glDrawpixel, probable even faster - especially when you glBindTexture so that the texture bitmaps resides on the graphics card's fast V-RAM.
Further I'd use the textured polygon way because in case you want to change the camera during the game - and if it's just to zoom in and out, or rotate around the z axis (or any other) from time to time. So it could look as cool as the funny Spactripper game does (
http://www.pompom.org.uk/ )
:-)