I've been (slowly) going through the rest of the tileset from

*Temple of Idosra* and configuring the tile geometries. This is an incredibly tedious process. Setting the image offsets, in particular, is frustrating.

To explain what that is, imagine a regular 2D tile or actor located at (x,y) in your scene. The image starts drawing at (x,y). This gets more complicated when your scene is 3D, since you have to project a point to 2D space and use that as the anchor point for the tile's image.

When things go wrong, well, this is the single most frequently posted image in this thread:

But it's also the most frequently recurring problem. It's made worse when structures are different sizes.

What's going wrong is this: I have a tile (stairs) located at (x, y, z). The steps themselves are defined by a sloping plane with four vertices. One of the vertices is (x0, y0, z0). To figure out where to draw the steps, I project (x0, y0, z0) to screen coordinates (Sx, Sy). I then add an x offset and y offset and draw the image at the resulting point. The offset is not easily calculated, because it depends on where that first plane vertex is--which is unique to the tile's geometry.

At least z-ordering is working. I never really talked about how that works, but I had to change strategies. My first solution assumed every actor and tile was the same size, so images could be sorted based on their

(x + y + z) coordinate sum.

The new solution sorts walls (2D planes), not tiles (3D structures). Basically, I loop through all walls and compute the intersection of their respective on-screen polygons (compute Sx,Sy for all four vertices). The intersection is computed using the same Sutherland-Hodgman implementation I used for the shadows. If there is an intersection, I just need to pick a (x,y,z) point in the intersection and compare the depths using the (x + y + z) approach. Once again it's critical that all walls be convex quadrilaterals. An easy way to guarantee that is to make all walls rectangles (in grid coordinates)--hence the necessity of the "growing squares" algorithm.

The downside is that I couldn't get the built-in Array sort to work, since I have to compare each wall to every other wall. That's a lot of comparisons (quadratic time). While I only need to sort visible walls, there's still potential trouble in a complex room.

Sorting walls only needs to happen once, but sorting moving actors would have to occur every frame. What I might end up doing is partitioning the map's graph into three sub-sectors: visible, partially visible, and hidden. The first and third sub-sectors have simple rules. If a moving actor is in the "visible" sub-sector, then draw it. If it is in the "hidden" sub-sector, then don't draw it. The "partially visible" sub-sector will be the pain to deal with. I'd prefer to find a way to use the painter's algorithm, since it's simple. The alternative would be to deal with more image clipping.

**Edit.** Here's what the scene is supposed to look like.

I used an red-orangeish light, which would be more appropriate for deeper areas away from the windows. The shadow follows the stairs rather nicely. This is a significant improvement over previous versions of the renderer, which were unable to work with any plane not parallel to a coordinate plane. This room has 77 walls, with about 30 visible. The Spring 2017 version of the engine (0.9.0, featured in March-May) would've used about 300-400 images to render this scene.