I'm building a simple Mahjong based game in Lua. I'm adding a simple perspective to my tiles on the bottom-left edges. I can successfully generate the level in proper tile order if tiles don't touch half-way using the following code:

    table.sort(self.tiles,
        function(tile1, tile2)
            if tile1.level_layer == tile2.level_layer then
                if tile1.level_y == tile2.level_y then
                    return (tile1.level_x - tile2.level_x) > 0
                else
                    return (tile1.level_y - tile2.level_y) < 0
                end
            else
                return (tile1.level_layer - tile2.level_layer) < 0
            end
        end
    )

It works like a charm. However when I start implementing the half-way touching, everything fails. For example I cannot implement a solution for the following problem:

In example 1 is the way it should be rendered, but it gets rendered as example 2. Is there an easy way to implement such perspective?

Surely the simplest solution for this particular case (assuming the tiles are always seemingly extruded the same way) would just to render from right to left?

Yes, that was what I thought at first (rendering right to left, top to bottom) but in this particular case the left tile is rendered before the right because its Y is smaller (assuming I'm working with top-left orientation). Just to say that if the tile is at X = 5, Y = 6, then it's rendered at X = 5, Y = 6 and X = 5, Y = 7.

What OandO said should be just the thing you need. If you render them from right to left, then the "edge" of the tile to the right will be under the tile to the left. This holds true for all 2d graphics -- watch the order in which you render things.

You may have to make your own counting function, but just have the renderer find the tiles with the highest Y and render those first.

Ok, so you want to draw starting with the top-right, work your way down the column first, then move to next column over to the left and so on.

Render the scene in two passes, first the edges, then the faces. This will work without having to render the pieces in any specific order, and will enable you to easily switch which sides of the pieces have the edge showing.

I may be missing something really simple but given example 1 it will render A before B as its Y is lower. If I render top to bottom -> right to left everything looks okay except for situations like example 2.

Ah ok, I see the problem now. mdias's suggestion seems good. Unless there's a very good reason that they need to be perfectly ordered, I'd favour that very simple solution.

There are two problems with that solution:

1. There is an animation at the beginning that "draws" the level where tiles fly from all the corners of the screen.

2. I need to implement the same solution for the level editor. It may be a bit slow to re-render the entire scene every time new tile is moved/added but it gets the job done.

I don't know Lua, and I don't know what API you're using for rendering, so I'll ignore that part, but assuming Object Oriented programming, you would have:

class Piece
    method renderPiece()
    method renderEdges()
    method setPosition( x, y )
    method setRotation( rot )
 
    member transform

now you renderScene function:

... // update pieces transforms

// traverse scene back to front
for each( zLevel in zLevels )
    for each( piece in zLevel.pieces )
        piece->renderEdges()
 
    for each( piece in zLevel.pieces )
        piece->renderFace()

I see you are worried about re-rendering the whole scene each frame, however this is how games usually work and if done right performance isn't an issue (specially for such a simple game). You can however calculate dirty regions and render only what's changed, but that will be too much work for very little gain, unless you're rendering it all on the CPU.

[edit] just updated the draw code to take into account the depth of the pieces. Animations will work fine, however if pieces from the same depth level intersect, weird rendering will occur, but that's something even true 3D rendering wouldn't solve. Player probably won't care much about the artifacts barely visible during the animations though.