# Common Isometric Questions

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

## Recommended Posts

##### Share on other sites
Prolly the easiest way is to treat everything that the player can be infront of/behind (trees, archways, etc) as non moveing sprites. If you use the characters feet as an "handle" then do the same with all other objects. Then you can sort them baised on their screen Y axis cords then draw them in top to bottom order.

For example that tree. Make it a big sprite with the "handle" where the trunk meets the ground. Then if the players feet are above the tree trunk then the player gets drawn first, if the player is lower then the tree is drawn first.

The most basic yet robust way to develop your engine is to do a simple "tile layer then sprites" system.

This is just a single 2D array of pointers to tile graphics (or a tile structure with attributes for collision and graphics) that gets drawn. Followed by drawing the sprites associated with that particular layer (if any). This is just simple linked lists type of structures. Which allows you to stack a number of tile/sprite layers so you can create multi-floored maps and the like.

Also sprites (even tile maps) do not have to be visable...So for example you can have an invisable sprite that when the player touches it causes them to change tilemaps....As in: Player is on seond floor climbing down ladder to basement...and by switching the associated tilemap. The player can then interact with the basement, its collision map and the sprites in that area. Player is then also automaticly drawn with the basement with the upper floor being drawn on top completeing the illusion.

##### Share on other sites
Thanks for the reply. This has helped me to understand it slightly better.

Three things I'm unsure of:

1. Can movable objects move on a per pixel basis? I'd really like to have this, but I'm wondering if it will add much, much more complexity.
2. Can the user rotate in 8 directions instead of the 4 basic directions?
3. What would I use for a collision box for something that isn't square? Let's say I throw a ball of fire out (hypothetically), the hitbox underneath would be a circle. Is that right? Or would I use something else?

##### Share on other sites
Quote:
 1. Can movable objects move on a per pixel basis? I'd really like to have this, but I'm wondering if it will add much, much more complexity.2. Can the user rotate in 8 directions instead of the 4 basic directions?3. What would I use for a collision box for something that isn't square? Let's say I throw a ball of fire out (hypothetically), the hitbox underneath would be a circle. Is that right? Or would I use something else?

1. Of course. There's two ways to do it. The first is to implement a "fine" offset and a "coarse" offset. The coarse offset is where on the map the sprite is, in tile coordinates. The "fine" offset is in the range of +/- your tile size, and indicates how far off "normal" position he is relative to his "coarse" position. His graphical position is then (coarse*tilesize)+fine-camera. To move a character one step to the north, say; decrease his coarse y position by one, increase his fine y position by tilesize, and have him move towards fine y = 0.

The other way is to store all objects' positions in "world space" coordinates, and then treat tiles as rectangles dropped into world space. This way, you have as much motion precision as you like. A solid tile will take up, say, 1x1 meters, and a character takes up .5x.5. A lamppost's base takes up only .25x.25, and a car takes up 3x2. Work it however you like. The major advantage here is there is an obvious and direct mapping from any world-space position, through a function or matrix, to a camera-space position. You can implement zoom and mouse-picking trivially.

2. Of course. Why couldn't he?

3. For any set of N collidable primitives, you usually need 1+2+...+N collision routines. If you have circles, ovals, axis-aligned rectangles, and arbitrary polygons, you need 10 different test routines. It's better to pick one or two generic primitives that suit your needs than diversify too much. Circles and axis-aligned rectangles are good enough for most tile-based games, and for most others circles for efficiency, plus the occasional arbitrary polygon for accuracy, works just fine.

##### Share on other sites
Quote:
 Original post by feti1. Can movable objects move on a per pixel basis? I'd really like to have this, but I'm wondering if it will add much, much more complexity.

If you think of the tilemap as a simple form of image compression then I think you will see how easy per pixel can be.

For example lets say you have a 100 by 100 map with tiles that are 32 by 32 pixels...that in turn would produce a image 3200 (100 * 32) by 3200 pixels in size if you were to render it completely (don't).

That also means that the player in a pixel by pixel engine could be located between 0 and 3200 in the X "pixel" axis as well as between 0 and 3200 in the Y "pixel" axis....

So all you have to do is store the sprites pixel location, and move it about in pixel increments....MUCH easier than trying to mess with fine/corse offsets and such....and inorder to figure out which tilemap cell the sprite is on you just integer divide the pixel location by the tile size (tile_X = my_pixel_X / Tile_size_X). This is super easy and very flexable as only the tilemap class needs to know anything about tile sizes and such.

##### Share on other sites
Thanks guys. What you've said makes much more sense to me now.

Tell me if I'm far off from a proper setup. This would be a very distant view of the main execution loop.

1. Grid tiles are draw first layer down, up until there are no more, from left to right, top to bottom.
2. Collision between objects is checked (standard math here, since I'm looking at the grid at this point directly top to bottom.
3. Rotate camera to isometric style.
4. Render sprites.

This is how I envisioned it. It would make more sense for me to draw it stanard (determine exact tiles to draw at this point, and everything has normal X/Y coordinates. Then the rotation only occurs before I stick sprites on the screen and render the scene. Is this about right?

One thing that I'm still a bit hazy on is exactly how to draw sprites behind sprites and using depth properties. I really don't grasp that just yet. And I can't find a perfect tutorial on it. I've read the world creator isometric tutorials and about a dozen others, but I just don't get it. Maybe my understanding of depth indices is skewed. Here's an example of what confuses me:

Over at the world creator forum, there's a depth tutorial that has an isometric box, which occupies 2x2 tiles in real world space, but in isometric space I think it's 6 or 8, I forget which. So the goal is to change the depth if the player's hit box height is higher than half of the box. Now when that occurs it changes the depth property of the box so it's drawn after the player. But would that also mean it could screw up the depth for a player in front of it as well, so that player's upper half is accidentally drawn behind the box as well?

I just need a better understanding of these core concepts. I'm as confused as they come at this point.

##### Share on other sites
Quote:
Original post by MSW
Quote:
 Original post by feti1. Can movable objects move on a per pixel basis? I'd really like to have this, but I'm wondering if it will add much, much more complexity.

So all you have to do is store the sprites pixel location, and move it about in pixel increments....MUCH easier than trying to mess with fine/corse offsets and such....and inorder to figure out which tilemap cell the sprite is on you just integer divide the pixel location by the tile size (tile_X = my_pixel_X / Tile_size_X).

I suspect you didn't really understand the worldspace/cameraspace solution I offered. What you've described is, of course, the obvious way to implement a 1:1 scale mapping with no rotation, just camera translation.

I offered both explanations because in some games (consider for example old SNES/Genesis RPGs, Bomberman, etc) an object must be considered to wholly occupy a given tile, even if it's not yet fully arrived in it and is still "in transit" from an adjoining tile. This is where using fine/coarse offsets is preferable.

##### Share on other sites
Quote:
 Original post by fetiOver at the world creator forum, there's a depth tutorial that has an isometric box, which occupies 2x2 tiles in real world space, but in isometric space I think it's 6 or 8, I forget which. So the goal is to change the depth if the player's hit box height is higher than half of the box. Now when that occurs it changes the depth property of the box so it's drawn after the player. But would that also mean it could screw up the depth for a player in front of it as well, so that player's upper half is accidentally drawn behind the box as well?

Not exactly. The player moving behind the box would then be "deeper" into the scene, so he'd be obscured by the box. You'd be changing the moving sprite's depth position, but not the static, unmoving box's depth. The only time you'd change the unmoving box's depth is if depth is represented by a structure which sorts by depth, and something moves from behind it or into behind it; then they'd trade position.

There's more to it than this, of course... no object which is not infinitely thin in the direction the camera points has just one depth position. We can pretend it does only so long as no other object intersects it along its camera-space collision plane. Games fake this kind of behaviour with clever trickery, by making sure that sort of intersection never happens. If a tree sprite could be walked through, a player walking through the trunk would just suddenly "pop" to standing behind it. To answer your original question #3, games avoid this by making sure player's can't walk into the base of the trunk to a height at least as tall as the player, and then simply drawing the rest of the trunk and all the leaves in a layer "above" the character with collision disabled, so it looks like the character is "under" or "behind" them.

I can't source you some explanatory graphics right now, but e-mail me (tiogshi at google's popular web-based e-mail service) and I'll send you some over the weekend. Use this topic title for the subject, so it doesn't trip my spam filter.

1. 1
Rutin
37
2. 2
3. 3
4. 4
5. 5

• 11
• 10
• 13
• 104
• 11
• ### Forum Statistics

• Total Topics
632979
• Total Posts
3009682
• ### Who's Online (See full list)

There are no registered users currently online

×