Well, I have given up on 3D for now. I told myself I should master 2D before I get into 3D.

So, I want to try to make a (somewhat) clone of Diablo. It is an isometric view game.

Right now, I have my player sprite moving around, and I have a way of placing tiles on the ground via a grid like this:
{0,0,0,1,0},
{0,0,1,1,0},
{0,0,1,0,0},
{0,0,1,1,0},
{0,0,0,1,0},
};

I also have a basic 2D camera that scrolls left,right,up,down.


The images themself are in isometric appearance, however they are not drawn at a rotated angle. (Think sqares instead of diamonds)

The only way I can think of to get a true isometric view would be to rotate every image in my game by x degrees. In order for THAT to work correctly I would need some way to rotate everything from 1 fixed point.


Before I try to find a way to do that, I was wondering if there are any advantages/disadvantages to simply faking the isometric view by leaving the tiles as is.

I do know that I would have at least 3 layers to draw.
-Ground
-Objects/Buildings
-Players/Enemies

I just want a really good stable and flexible start to this project so that I don't get halfway through and realize I cannot impliment 'x' feature because I messed up somewhere in the beginning.

honestly rotating it wouldn't be that hard, but off the top of my head I can give you a quick pro/con situation for faking it.

pro- you could draw horizontal walls by faking it.  Otherwise in a 2D it would be hard to make them work

con- it would make terrain collisons more difficult.  your rotation wouldn't take effect untill draw, so in reality everything would be straight, and would only appear rotated onscreen.  Otherwise you'll have to do some more costly collison checks if you fake it.

Again off the top of my head, but that's two things I thought of right now.  If you're going for simplicty and flexibility, honestly rotating it would be easier, though at first glance it might not appear so.

Ok, so I am able to rotate the background sprites to a 45 degree angle. This however is where it starts to get confusing. Since my squares are now shaped like diamonds, the coordinate system is all crazy like. Instead of (0,0) being the top left, it is now moved up and to the right. And to make things more confusing, if something moves + (10,0) this means it is actually moving SouthEast on my screen.


Right now my character is not moving as he is supposed to when I have the background rotated to isometric view. I would like him to move to the right of my screen when I press right (which he does), however his X and Y coodinates do not match up with the rotated background coordinates.
His +(10,0) moves him to the East. So when I go to check collisions things are going to get very ugly.

So if He starts at world spot (0,0) moves +(10,0) he will not be in space (10,0) according to my world. He will be at something like  (5-,5).


If anyone wants to view my horrible horrible code they can..and feel free to give me some tips!

Please note that when I am trying to figure something out I often throw many ideas around...so it gets quite messy until I figure out a good way to do it. Please keep that in mind.

It should be pretty basic and self explanitory for you gurus however.

http://rapidshare.com/files/94699988/Nax.rar

WASD moves the 2D camera
arrows moves the character.

Pardon the placeholder graphics.

There are a lot of isometric tutorials on the web, try this one as a starting point.

http://www.gamedev.net/reference/articles/article747.asp

One of the issues of isometric systems is depth sorting, because of the staggered layout of tiles it is very easy to screw up and end up with your MOB's (movable object blocks, your characters and objects) getting drawn at the wrong time. They then appear over the top of the objects in front of them, or part of them gets deleted by the next tile drawn.

Think of what will happen when you have a MOB near the bottom right of a tile, slightly overlapping the next tile to the right and the next tile down the screen.

If you draw all the tiles, then draw the MOB, the MOB will not be "in" the scene.

If you draw the MOB at the same time as the tile it is in, then parts of it will be overwritten by the next tile to the right and the next tile below.

If you draw a row of tiles then draw all the MOB's on that row, parts will be overwritten by the next row.

It's a complex issue, and one of the reasons the early isometric games had the game characters only moving one tile at a time.

One solution is to model all your tiles as 3D objects, and then place them into the grid and let the zbuffer take care of depth issues.

Another is to use the equivalent of Porter - Duff rules.

These are a set of drawing rules with names like SRC_OUT, SRC_IN, DEST_IN, you can write code that only draws to the screen IF the destination pixel is empty, slow as hell though.

Don't think 2D is easier than 3D, in todays environment where polygons are king it is often harder to do some things that seem simple than to throw thousands of polygons at the graphic card and let it sort it out.