This article introduces the concepts in JOGL, the Java bindings to OpenGL, that are applicable to 2D gaming. We start with the handling of coordinate spaces and how they\'re scaled from the OpenGL world to the screen. Then we integrated JOGL\'s built-in A
Tutorial Details:
We need to begin with a recap of some of the installation and configuration issues that were at the heart of the previous java.net JOGL article, \"Jumping Into JOGL.\" Chief among these is the fact that as JOGL approaches a 1.0 release, milestone builds have fallen away in favor of nightly builds. If you follow the \"Precompiled binaries and documentation\" link on the JOGL home page, you\'ll find that the project\'s \"Documents and files\" list is empty, with just a link pointing you to \"Use nightly build.\"
JOGL\'s Builds Download Page shows no release or milestone builds, just nightly builds by platform. These will generally work for everyone except those on Mac OS X. The nightly Mac build seems to want its native libraries to be in a Java 1.4.1 folder, a folder that gets deleted by Apple\'s Java 1.4.2 installer.Back in the first article, a few calls to set up a JOGL drawing space were taken on faith. It\'s time to explain what was really going on with those calls, because this article will begin using non-trivial values for them.
Recall that a JOGL drawing surface, a GLCanvas, is retrieved via a factory method that passes in an object representing the characteristics of the display. This GLCanvas is not drawn to directly. Instead, we register for events via a GLEventListener interface. This interface requires we handle four calls:
* init()
* reshape()
* display()
* displayChanged()
Each of these passes in, as a GLDrawable, the surface we are to draw on, by way of getting the GL and GLU pseudo-objects. (\"Pseudo\" because they\'re meaningless as objects and are instead a very simple mapping to the thousands of functions in the gl.h and glu.h native header files.)
In the previous article, our very simple reshape() implementation obscured two very important facts about the OpenGL world as it relates to the screen:
1. OpenGL coordinates don\'t necessarily map one-to-one with on-screen pixel coordinates.
2. OpenGL calls are passed through a rendering pipeline that, through a series of affine transformations, allow us to rotate, scale, and translate (move) the entire co-ordinate system.
In OpenGL, the \"world\" is viewed in Cartesian coordinates, with X values increasing as we go right, and Y values increasing as we go up (there is also a Z axis in 3D, but that\'s for next time). We define a \"world window\" as the portion of this world that we want to render to the screen. This is done with the call glOrtho2D() in the GLU class. In the previous article, we forced this to be a size appropriate to counting by on-screen pixels, but this is neither required nor desirable: OpenGL will scale the contents of the world window to our on-screen display, called the viewport. The viewport is set with the glViewport() method in the GL class. Note that, curiously, glOrtho2D()\'s arguments are left, right, bottom, and top, while glViewport() takes left, right, width, and height.
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: Juggling
JOGL
View Tutorial: Juggling
JOGL
Related
Tutorials:
|
Open Source Chat