Pros:- Fast- Simple- Easy- No tricks or crazy workarounds, just OpenGL- Loads of OpenGL literature available- All-in-one library is very convenient to use and deploy- Fullscreen works! Properly!

Cons:- Will fail on machines with crap drivers- At least 35% of Windows machines don't have drivers at all, and 50% of Linux machines.- You'll have to sign your code to run it- Pain-in-the-arse packing your sprites into legal OpenGL textures- Some learning curve. But probably easier than any Java libraries. - Requires Java 1.4 or above.

I've already checked JOrbis but it seems to be a rather low level API isn't? I don't want to do buffer management because it's too tricky considering the time I have to develop and I prefer to concentrate on the game content/gameplay. I'd like something high level like the fmod3 package in LWJGL.

The problem with FMOD is the licence price. I can afford it. It's too risky. Do you use it in Alien Flux or in Super Dudester?

AF & Dudester both use JOrbis and OpenAL. I just load all my oggs on demand, decode them into large bytebuffers, and chuck them straight at openAL and forget about them. When I want to play one, it's just a case of calling alSource() and playing the buffer. I wrapped it up in a few utility classes and haven't thought much about it for a couple of years.

AF & Dudester both use JOrbis and OpenAL. I just load all my oggs on demand, decode them into large bytebuffers, and chuck them straight at openAL and forget about them. When I want to play one, it's just a case of calling alSource() and playing the buffer. I wrapped it up in a few utility classes and haven't thought much about it for a couple of years.

Cas

Cool! Could you put it publically in LWJGL please if it's not already done?

The mp3 license is quite expensive and there is no reaon to use mp3 when you can have ogg. Ogg is just better - especially with low bitrates (after all it needs to be downloaded at the end and smaller with equal quaility is really a good thing).

You can go pretty low for most sound effects. Like mono, 22khz and 64kbits (or even less).

Both formats have their own kind of artifacts, which get pretty obvious with really low bitrates. Mp3's artifacts are very unpleasing to the human ear (hihats=pain) whereas ogg's is more a damped down thing. It's just not as crisp as the original anymore, but at least it doesn't hurt.

I'm probably getting into the conversation too late here (I've been hanging out on the lwjgl forums too much I guess). I recently "ported" a couple of my java2D games over to lwjgl. It was pretty painless. In order to help the transition, I wrote a couple of methods that "paint" to the screen (basically, I create a quad of the same size as the graphic asset and paste the graphic onto it as a texture - this works, although I've started redoing some of my graphics for openGL since texture memory is always at a premium).

If you're so inclined you can set up the coord system identical to Java2D (just shove the right params to glOrtho). Equally you can always ignore the matrices and camera stuff and just do things manually like you would for Java2D.

If you're so inclined you can set up the coord system identical to Java2D (just shove the right params to glOrtho). Equally you can always ignore the matrices and camera stuff and just do things manually like you would for Java2D.

I do use a matrix under Java2D, the default matrix which I use as a camera and it centers on my player which moves through the world.

People that keep saying that you can setup a system like J2D with glOrtho have never actually said anythig more than that.

near, farSpecify the distances to the nearer and farther depth clipping planes. These distances are negative if the plane is to be behind the viewer.

So near and far are the z bounds in which thing will be drawn.

It goes on..

Quote

DESCRIPTIONglOrtho describes a matrix that produces a parallel projection. (left, bottom, -near) and (right, top, -near) specify the points on the near clipping plane that are mapped to the lower left and upper right corners of the window, respectively, assuming that the eye is located at (0, 0, 0). -far specifies the location of the far clipping plane. Both near and far can be either positive or negative.

And it goes on..

OpenGL has always struck me as having pretty good documentation, especially for the things that have been around along time. Maybe that's why your fave Carmack likes it so much.

I've looked through the GL red book and couldn't find an explanation either.

I can't belive that.

If you can't find info in the red book, theres always the blue book. I dunno whether thats avalible online, but the actual print book should be avalible that covers up to 1.4.

If you're only after 1.1 docs (which covers 90% really) then MSDN has a complete reference online (or in Visual Studio's help files if you've got that). If you're after docs on anything later then either the blue book or the OpenGL extension repository (google it!).

It doesn't 'dissapear', it just becomes (largely) irrelevant, since objects are always the same size regardless of the position on the z axis - although the z position does become important if you want to use the depth buffer, but for 2d sprite style stuff you don't really want to use that (and it default to off).

So then why do people tell me that the Z axis all of a sudden dissapears when you use glOrtho?

Because it does. In projection mode, screen coords are calculated as:

1 2

scrx = x/z + screenWidth/2;scry = y/z + screenHeight/2;

In Ortho mode, screen coordinates are calculated as the following instead:

1 2

scrx = x + screenWidth/2;scry = y + screenHeight/2;

What doesn't change is the clipping bounds. i.e. If you give an Ortho projection a negative Z value, it will be clipped as if it were behind you. If you give it a positive Z value beyong the clip plane, it will again be clipped and not rendered.

The reason for this is that Ortho (or parallel projection) is a classic method for 3D rendering, that sometimes looks better than perspective renderings. For example, in Ortho mode, a cube would be rendered square (very similar to how you might draw it on paper). In perspective mode, it is renderered as more of a trapezoid with coordinates farther from the viewing plane getting closer together.

In Ortho mode, screen coordinates are calculated as the following instead:

1 2

scrx = x + screenWidth/2;scry = y + screenHeight/2;

If it only was that easy Remember OpenGL does a full conversion from world coords into eye space, then into screen space (probably with a normalised view volume in there somewhere internally). World->eye is performed differently based on the projection matrix, but still uses (and retains) all axies. Only eye->screen drops the z axis, but will do so regardless of the projection mode.

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