# Scew the map on the fly or at load time?

This topic is 4627 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

At the moment my map is stored in a 2D array and I do all the "scewing" to the isometric angle in the drawing loop... though this has struck me as a bit long winded as the game is having to do its calculations about which tile to draw on each drawing cycle... which does not seem efficeint. But if i scew the map at load time ill need a bigger array to store it and some of the drawing cycles will be wasted as they read blank arrray elements. So the way im doing it now stores the level like this: 0000 0110 0110 0000 and then each drawing cycle it uses an IF statment to work out which direction to shunt the row so that it draws a dimond shape map. The way i was considering would load the map into a pre-scewed formation within a larger 2D array like so:
----0---
--0--0--
-0--1-0-
0-1--1-0
-0-1--0-
--0--0--
---0----

[-] = empty element

(or somthing simular) Which would use up more memory and make 3/4 of the drawing cycles do nothing as they read null elements. which way should i store my level? is there another way to do this?

##### Share on other sites
Well, I typically don't physically skew the map like that. If you take a standard rectangular tile map and spin it 45 degrees around the vertical axis, then bingo: an isometric map. Doing some sort of weird offset trickery doesn't seem to me like a very intuitive or easy-to-implement scheme. [grin] Your initial method of doing the 'skewing' such as it is is more accurate. And don't worry too much about the calculations being done each drawing cycle; trust me, they are completely and totally insignificant on modern machines. Performance in that regard is a bad reason to turn your rendering system weird.

##### Share on other sites
I agree. Here's what I do in my current isometric project :

Map format is a standard array of grids. When rendering, all tiles are designed to be isometric in view. That is, the engine has a base floor dimension, and all tiles are based off of those values. The actual rendering does the following :

Starting at the origin of the view area (the engine displays only so much of the map at a time, and it manages lists of separate map areas, depending on relevancy of that area to the player or important NPCs, such that irrelevant maps are unloaded from memory while relevant maps stay in memory for quick access by the important game entities), the overall render loop moves across the array such that the origin is at the top of the render area, and every loop increments the starting row index and traverses a linear line, incrementing the column index and decrementing the row index. If the current grid in the loop is under a multi-grid object, the object is flagged for deferred rendering, so that in case the object itself overlaps nearby (or post-rendered) grids, the object, and the grids it sits on, are rendered such that the overlap integrity is maintained.

The end effect is a nicely overlayed isometric view. The real trick to such a method is the tile design. You can find some old screenshots at my project's site. I really ought to do an update to the site information, as I've gone into full work on not only a map editor for the project, but another project entirely at the same time.

##### Share on other sites
Thanks guys.
I'll stick with the current system of just reading from a very simple 2D array.

Is the lighting in your game (as seen in the screenshots) using any 3D api's or is it just 2D trickery?
If its the second are they "dynamic" (i.e can they change during run time if the player destroys a light source or creates one or moves an existing one? or is it all done in the level editor?

Cheers.

##### Share on other sites
Adeo uses D3D, with textured quads and an ortho projection. That being said, however, there is no 3d lighting going on; it's all based off of grid-based LOS and a linear light fall-off model. Every frame, every light updates the light values of the tiles that it affects. Lights can be tied to objects or a part of the grids. The algorithm that governs what the player can see also handles light (it's all based on LOS).

1. 1
Rutin
19
2. 2
JoeJ
15
3. 3
4. 4
5. 5

• 24
• 20
• 13
• 13
• 17
• ### Forum Statistics

• Total Topics
631700
• Total Posts
3001778
×