# Mahjong based tile perspective

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

## Recommended Posts

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?

Edited by btatarov

##### Share on other sites

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?

Edited by OandO

##### Share on other sites

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.

##### Share on other sites

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.

Edited by sonicarrow

##### Share on other sites

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.

##### Share on other sites

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.

##### Share on other sites

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.

##### Share on other sites

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.

##### Share on other sites

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.

##### Share on other sites

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.

 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.

1. 1
2. 2
3. 3
4. 4
Rutin
17
5. 5

• 13
• 14
• 9
• 9
• 9
• ### Forum Statistics

• Total Topics
632927
• Total Posts
3009241
• ### Who's Online (See full list)

There are no registered users currently online

×