I'm just starting out creating an isometric tile based engine and wanted to get some questions out there before going much further. All the tutorials and guides I've read regarding the coordinate system for diamond tiles have every other row occur 1/2 a tile height down, and 1/2 a tile width offset. But when I tried that, i quickly realised that square buildings would look horrible, and diagonal buildings seemed needlessly complex. So I scrapped the whole thing and adopted a system in which the X axis runs from top-left to bottom-right and the Y axis from top-right to bottom left, with 0,0 being the top centre of the screen. Example Picture I guess I'm wondering if anyone sees a horrible flaw with this system that may come and bite me later. Thanks

I've been working on something very close to what you're doing for the past month:



This is just a test map from my map creation tool that I'm finishing up today, but so far I've not run into any major problems using the diamond shape that you wouldn't run into with an other type of game. In fact, I think it lends itself well to being easily manipulated with very basic math.

The diamond shaped map is also quite a bit more attractive than your original plan, and the extreme 90 degree blocky-ness can be fixed up with wall sections that cut across the center of a tile:


What is the maximum amount of tiles that you plan on drawing per frame? How large will your maps be, and is there a Z-level that allows for height, such as multiple-story buildings? These are the biggest issues I've had as far as processor use--basically just effecient drawing and manipulation of the world.

I use a 3:1 aspect ratio, which is a little odd, and I won't be able to use many pre-made resources available on the net. It appears as if you use a 2:1, which will be nice when it comes time to put objects in the world.

I used for the first time your engine type on example 1 and when my engine was finished about 90% I swap it to the second example. Not to say that I lost 1 week on reprogramming of engine :(
Well why? Because of few things that made my programmer life very bad :) Yeah I solved most of problems, but then it was too complicated.
Example 1 use not diagonaly map so every tile on y coordinate is 1/2 tile's height down drawed :) this means that you'll need every coordiante based operation adjust to this aproach: tile selection, sprite movement, map scrolling, etc
I gave up when I've tried to implement missiles, and then reprogrammed a whole thing.
it is much simplier to do x--; than whole bunch of program code to do simple movement by x axis.
And also my pathfinding routine was not perfect on Engine1. Enemys moved on some crazy paths [smile], while second approach was piece of cake to do.
Lightning was made with enourmos coordinate tables, while second approach was made by few for loops.
Stick yourself to second aproach of your engine. It will made your life easy.

Thanks for the info, guys.

Quote:Original post by cyric74

What is the maximum amount of tiles that you plan on drawing per frame? How large will your maps be, and is there a Z-level that allows for height, such as multiple-story buildings? These are the biggest issues I've had as far as processor use--basically just effecient drawing and manipulation of the world.

I was thinking of having the standard map size be 100x100 tiles, but it won't be fixed. Multiple story buildings are in as well.

How many tiles to draw per frame is tricky, as the game runs pretty slowly with the number i draw in the screenshots above. The engine supports zooming, so I can see that it makes quite a large difference if I zoom in or out on the fps. I guess i've been hoping that i was doing something wrong and I would find a way to make it draw faster, but i don't think I will.

You'd be surprised at how much speed you can gain with just a few modifications. Sorry if I get too basic here, but I made these mistakes when I first started on my engine:

* Make sure that you're only drawing what is on the screen. Take this a step further and only process tiles on the screen. I created an arraylist that stores 3 integer values (x,y,z) for tiles that appear on the screen, and my draw function only looks at that array for which tiles to draw and do picking/selection tests on. This cut my per frame processing time in half.

Update the "visible tiles" list only when the user adjusts the view.

* What language are you making the engine in? Are you using the optimal (or at least a decent) method for drawing sprites? One of my first major problems was that I was incorrectly using DX9's Sprite interface. With good optimization, I've been told that I should be able to render upwards of 3000+ sprites per frame without any real drop in FPS (I can currently push it up to about 2,100 without drop).

* Someone suggested to me the other day that tiles should be drawn by texture groups--basically find all base tiles that use one type of texture and draw them first, then go on to the next texture and draw all of those. This is a little more difficult in an isometric game because you need draw order based on an object's Y position, but you can draw all of the "floor" tiles first before drawing walls and objects.

The bonus from this is that you don't make as many internal state changes, thus doing less math per frame.

* Avoid as much math per-frame as you can. My original ground tiles were full 128x128 textures, and my code would rotate and scale them. This was a huge and costly mistake!--I've now made all my tile images exactly how they will be rendered so that there is no rotation or scale math done on the fly.

Hope this helps some.

Cyric

Thanks for the tips.

To render the tiles I'm using textured quads as opposed to D3D9 Sprites. The main reason was for per-vertex lighting, and easy zooming doesn't hurt. (I'm not sure if you can do the zooming with sprites).

I am only processing the frames on screen, because of that the frame rate tanks when zooming out, and increases a lot when zoomed in. I am aware of batching identically textured tiles together.

I am using C# and managed directx. Using my default zoom I figure about 720 tiles are drawn per level every frame. If I can't get it to run faster I'll probably zoom in closer and draw fewer tiles.

The screenshots from your project look great, I can't wait for the day my engine is that far along. (Literally... i'll probably be dead by then)

The Sprite interface uses its own textured quad, though I haven't fiddled with the lighting yet. Zooming is as simple as setting Sprite.Transform to a larger scale matrix before the draw call, and doing some light math to keep the view centered on the same spot.

I'm also using C# with Managed Dx, so you may want to consider at least a little test with the Sprite class if you can't get your current method to draw as fast as you'd like. No reason to limit your design when the technology is there to support what you want.

Thanks for the compliment on my screenshot. I've basically dedicated the last month of my life to getting the engine running--now I'm spending most of my time creating a few hundred tile and wall textures. Very tedious.