Migrating from Java2D to LWJGL

[TheAnalogKid]

Hi!

I'm evaluating the possibility to migrate Mighty Bubbles to LWJGL.

What are the pros and cons of LWJGL?

How easy/user freindly is it for doing 2D?

Is there stablility/compatibility issues (video cards, sound cards, ...)?

Does it have support for multiple audio formats with  OpenAL? It is probably up to OpenAL itself? I ask this question because the fmod licence is too expensive/risky for a small budget game.

Thanks

[TheAnalogKid]

Ho! And I've already read the About section on the LWJGL web site.

[kappa]

i actually started with the space invaders demo by kevin glass, where he uses java2d and opengl to run the same game, its a good place to see how it sort of works.

Games published by our own members! Check 'em out!

[princec]

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.

Cas

[TheAnalogKid]

OK thanks.

And what about OpenAL if I want to load ogg or mp3 files and mods/midi?

[tom]

There is a ogg library available wich is very easy to use. Don't know of mp3, midi or mod libs. But if there are independant libraries then it would be easy to adapt it to OpenAL.

[princec]

For OGG, use JOrbis. Don't use MP3.

For MIDI, use JavaSound! OpenAL is purely for playback of PCM data.

FMOD is still an option! Don't discount it.

Cas

[TheAnalogKid]

There is a ogg library available wich is very easy to use. Don't know of mp3, midi or mod libs. But if there are independant libraries then it would be easy to adapt it to OpenAL.

About the OGG lib, do you mean there's an integrated API with LWJGL or what? Also you seem to say that OpenAL is not as rich/integrated as FMOD in terms of features?

[TheAnalogKid]

For OGG, use JOrbis. Don't use MP3.

For MIDI, use JavaSound! OpenAL is purely for playback of PCM data.

FMOD is still an option! Don't discount it.

Cas

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?

[tom]

Have a look at my OggPlayer. It's 3 lines of code to play file. It  is played directly from a InputStream so you don't have to waste memory by decoding it first.

Games published by our own members! Check 'em out!

[princec]

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

[TheAnalogKid]

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?

[TheAnalogKid]

Have a look at my OggPlayer. It's 3 lines of code to play file. It  is played directly from a InputStream so you don't have to waste memory by decoding it first.

Thanks! I'll check that...

[ap_kelly]

I use JavaLayer for all my MP3 playing, it's only 3 lines of code to get it working and they've just released version 1.0

I have a tutorial on my site that shows you how to use it, and you can download the library from here.

http://www.javazoom.net/javalayer/javalayer.html
http://games.swizel-studios.com/tutorials.html

Andy

[oNyx]

> I use JavaLayer for all my MP3 playing,

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.

[elias4444]

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).

Hope that helps. I've been really impressed with lwjgl myself.

[TheAnalogKid]

Thanks for your feedback!

[K.I.L.E.R]

You guys are claiming that it's easy to migrate from J2D to LWJGL.

You guys are right to a certain point.

Some of the games mechanics will have to change due to the way OpenGL handles things such as coordinates and camera movement.

[Orangy Tang]

What problems are you actually having?

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.

[K.I.L.E.R]

What problems are you actually having?

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.

I've tried, I've failed.
I've looked at other people's code, it doesn't explain.

I get what the first 4 parameters do under glOrtho but no one has explained what the last 2 parameters do. Under GL docs those last 2 parameters in the glOrtho method are called "near" and "far".

Great explanation isn't it? That's all I know because that's all what the docs explain.
I've looked through the GL red book and couldn't find an explanation either.

I've come to the conclusion that either vague explanations are good because everyone except myself can understand them, or everyone in the world is conspiring against me.

Take your pick.

[kevglass]

Is everything always bad?

glOrtho - google - first hit:

http://www.mevis.de/~uwe/opengl/glOrtho.html

near, far
Specify 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..

DESCRIPTION
glOrtho 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.

Kev

[Orangy Tang]

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!).

[K.I.L.E.R]

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

I'm mixed up because I've read different things about the same topic.
It's confusing to say who's not and who's telling the full story.

[Orangy Tang]

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).

[oNyx]

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

It doesn't. But keeping a zbuffer doesn't make much sense. If disabled, it's basically as if there isn't a z-axis at all. Therefore you can savely use the methods w/o z (z=0).

edit: meh... first submit, then smoke

[K.I.L.E.R]

Thanks.

I will do some more reading about matrices and cameras. Even though they are the same thing.

[jbanes]

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.

Does that help clarify things for you?

[K.I.L.E.R]

Much so.
Thanks. All I had to do was cry about it.

[Orangy Tang]

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;

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.

[K.I.L.E.R]

YAY! I can move.

The normalised coords they are.

float x, y;
x = input.getCamX() / 256;
y = input.getCamY() / 256;
           
b.teleport(x, y);

I can move properly.
You know what else?

I'm still figuring this camera crap out.
IE: I don't know how to get camera/matrix on player.