Talk:Map Geometry

From FIFE development wiki
Jump to: navigation, search

I'm not sure we all have the same mental image of how geometries should work, so here's some pictures and commentary on how I see them working. Other points of view are welcome.

Defining a Geometry

Here is a picture of a rectangular geometry with a tilt of 0, a scaling of 1, and a rotation of 45 degrees.


I do not think this system allows for variations in the dimensions of the rectangle, so square geometries would have a different type than rectangular geometries, which would have a different type than rectangular geometries of other dimensions. I don't know if there's a better way to handle this?

Coordinate Systems

Layer Coordinates: These are the (integer) coordinates of tiles on a layer:


Elevation Coordinates: These are the (decimal) coordinates of tiles within the elevation. These coordinates are absolute in the sense that they are universally equivalent across all layers.


In this picture, the rightmost red dot is the point (1,0). The lower red dot is the point (0,1). Therefore, the elevation coordinates of the blue dot are close to (1, 1.5). The layer coordinates of the blue point (assuming this is the same geometry as the example above) are (1,0).

Screen Coordinates: These are the coordinates relative to the screen. They depend on the zoom level and location of the camera.


If the screen dimensions are 640x480, then the black point--(0,0) in elevation coordinates--is about (200, 50) in screen coordinates.

Pixel-perfect Graphics

Here's one way to get pixel perfect graphics:

Associate elevation coordinates with screen coordinates such that elevation coordinates have the same units as screen coordinates at a camera zoom of 1. Since elevation coordinates are logical, it doesn't really matter what units they're in, so they might as well match pixel coordinates at zoom 1. With this system, if the artist creates an image with (pixel) dimensions that match the geometry scaling, then those graphics will be pixel perfect at zoom 1.

Note that the scaling I gave in the example geometry definition was 2. Under this system, that is probably unrealistic (2 pixel tiles would be pretty small!). A more reasonable scaling value might be 50. Big tiles might have a scaling value of 75. Small tiles might have a scaling value of 25.

How fundamental are tiles?

For many isometric games, object movement is limited to the tile grid. So on a square grid, if an object wants to move from tile (0,0) to tile (2,2), the object must first move to (1,0), then to (1,1), then to (1,2), then to (2,2) (or take some other equivalent path). However, in other games, tiles are less "fundamental." When moving from (0,0) to (2,2), an object may cross the diagonal.

Ideally, I suppose FIFE should support both these systems (use of both is widespread). However, they are two *very* different systems, and will have to be handled in very different ways. For instance, I think the pathfinding algorithms for these two systems are entirely different. (I believe mortiz's current pathfinder is node-based, so it depends on having discrete tile-movement).

More comments on this appreciated. :)