For this, I had the typical X/Y values and I also had a third depth value. I didn't call it Z just because it was kind of a fudged BS this. Pressing up on the keyboard increased depth and down decreased it. When jumping, Y increased or decreased.

Might be simpler to call X and Y what they are, and have like jumpHeight or something as your third value. In terms of draw position, it should be normal Y + jumpHeight. For collision detection, you need to look for collisions both along the normal X/Y, and also along the jumpHeight. Pretty easy.

Meh. One of the problems with games like Double Dragon is that it's usually pretty difficult to tell the alignment on the y or z axis (depending on what system you use). So your kick might go right in front or behind the enemy.

It's pretty easy. Most 3D games want to render 2D sprites that always face the screen since that's how you render particles! You'll have to project your sprite positions into view space and then draw your quad there.

1. Read back (or calculate) your OpenGL modelview matrix into a Matrix4f.2. Reset the modelview matrix with glLoadIdentity() so that vertices are only transformed by the projection matrix.

For each 3D sprite:3. Load the sprite's position into a Vector4f.4. Transform the sprite's position by the modelview matrix using Matrix4f.transform(modelviewMatrix, spritePosition, spritePosition);5. Draw the sprite's quad relative to the transformed sprite position. The coordinates for the top left and bottom right corners: x1 = spritePosition.x - width/2 y1 = spritePosition.y - height/2 z1 = spritePosition.z

To understand why this works you'll need to understand how OpenGL transforms 3D coordinates into screen coordinates. The modelview matrix takes coordinates from world space to view space. In view space the "camera" is always located at (0, 0, 0) looking towards -z (I think ). By creating our quad here we can guarantee that it always faces the screen, but it will still be processed by the projection matrix so it also gets smaller the farther away it is, etc.

I'm new, but since I have also a "Z-axis", here's my solution (maybe wrong ! so people might correct me ) :

I just intend to make a Class that'll act as some sort of a pool (storing everything that need to be drawn) and add a <Comparable> option for the Z value in it.So in the end I'll just have to "sort" the object before drawing.

Edit :Huho, I didn't notice you were talking about a LIST.If that's the case I'm pretty sure that this collection is already able to sort String & Integers just fine with a build-in method, right..?

The easiest way to do fake-looking isometric 2D is to rotate everything 45º, then scale its Y. Your example isn't exactly an isometric approach, but it's the same idea. If you look at those shapes, they're basically trapezoids. So if you draw your quad and skew the rear 2 vertices / squish the Y, you'll get the same effect.

But then you're kind of writing your own 3D camera, so you might as well go all 3D if you understand that reasonably well.

O(n^2) sorting might be ok in this particular case but in general its just plain wrong. Just learn to use collections.sort to get faster, cleaner and better code. Algorithm level optimizations are something that everyone should know.

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