Migrating from Java2D to LWJGL

OpenGL Development
#21

Is everything always bad?

glOrtho - google - first hit:

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

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

It goes on…

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

#22

:o I can’t belive that. :o

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

#23

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.

#24

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

#25

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 :stuck_out_tongue:

#26

Thanks.

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

#27

[quote]So then why do people tell me that the Z axis all of a sudden dissapears when you use glOrtho?
[/quote]
Because it does. In projection mode, screen coords are calculated as:

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

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

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?

#28

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

#29

If it only was that easy :stuck_out_tongue: 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.

#30

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.

#31

I’m an idiot.

“To give the appearance of moving the camera, your OpenGL application must move the scene with the inverse of the camera transformation”

You guys are right. Reading a few lines of text instead of pages of text can help me learn.

http://www.opengl.org/resources/faq/technical/viewing.htm


GL11.glPushMatrix();
            GL11.glBindTexture(GL11.GL_TEXTURE_2D, SpriteLoader.getInstance().getSprite(0));
            GL11.glMatrixMode(GL11.GL_MODELVIEW);
            GL11.glTranslatef(-x, -y, 0);
            
            GL11.glBlendFunc(GL11.GL_DST_COLOR, GL11.GL_ZERO);
            
            GL11.glBegin(GL11.GL_QUADS);
            {
                  GL11.glTexCoord2f(0, 0);
                  GL11.glVertex2f(x, y);
                  
                  GL11.glTexCoord2f(1, 0);
                  GL11.glVertex2f(x - width, y);
                  
                  GL11.glTexCoord2f(1, 1);
                  GL11.glVertex2f(x - width, y - height);
                  
                  GL11.glTexCoord2f(0, 1);
                  GL11.glVertex2f(x, y - height);
            }
            GL11.glEnd();
            
            GL11.glPopMatrix();

This moves my player and moves the camera.

#32

I’ve started porting Rimscape to LWJGL and I have to say that it can difficult. First you have to make the game single threaded. Or atleast making sure you only call GL from one thread. Fonts are a pain in the ass. Not only do you need to generate a bitmap font, you need to emulate the FontMetrics stuff. Then there might be Java2D functions like rounded rectangles and stuff. It all adds up.

Although I’ve taken some shortcuts with Rimscape. Alot of stuff are still rendered using Java2D and uploaded to OpenGL using textures.

#33

[quote]If it only was that easy :stuck_out_tongue: 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.
[/quote]
This is true enough, but I was trying not to confuse her with 3D rotations and camera movement. Especially since the question was more or less focused on the projection itself. Unfortunately, it seems she ended up getting confused about it anyway. :slight_smile:

K.I.L.E.R.: The way I like to think about 3D space is that you don’t so much as move the camera, as you move the world around you. Remember, every vertex in the universe is rotated and transformed until point 0,0,0 with +z look at, is the location of the player. It kind of boggled my mind the first time I figured that out. I just sat there and thought: “But that’s a LOT of vertexes to transform!” Guess that’s why they invented 3D cards. :wink:

#34

Maybe, thats only really because you’re trying to directly port it rather than migrate it to GL tho?

Kev

#35

[quote]Maybe, thats only really because you’re trying to directly port it rather than migrate it to GL tho?

Kev
[/quote]
True. If you start off with LWJGL from the starts, you don’t have to jump threw Java2D hoops.

Btw, how do you interprite the differance between migrate versus porting a game?

#36

Do you need significant OpenGL training to use LWJGL when your game processes 2D only?

#37

Now thats a question worth of a post (finally!) :slight_smile:

Kev

#38

I think porting means that you want to adapt the code of your game to the new APIs/platform with minimal efforts. This solution might be worth for money for the short term but not very good for code maintenance.

#39

Even though you don’t answer it. :lol:

Migrate: Change your work to fit LWJGL (IE: modify your one and only rendering path to use LWJGL).

Port: Add LWJGL as a code path into your work without actually changing your current code. You’re just adding to it.

#40

er, K.I.L.E.R., when did you suddenly morph into a “woman”?

Cas :slight_smile: