4 Replies
      Latest reply on Jan 1, 2020 7:29 PM by fsrs
      Krumelur Level 1 Level 1 (0 points)

        Im programmatically using SKTileMapNode. The code is C# (Xamarin.iOS) but should be readable by every Swift/ObjC developer.

         

        The problem is that the sorting of tiles in isometric projection seems to be incorrect and I cannot see why. To test, the map has 1 row and 5 columns. See the screenshot:

         

        https://dl.dropboxusercontent.com/u/111612273/SVhjD.png

         

        The tiles at 0|0 and 2|0 are in front of the others. The pyramid styled tile at 4|0 however, is drawn correctly in front of the one at 3|0.

         

        I'm using two simple tiles: The first one has a resolution of 133x83px and the second one is 132x131px:

        https://dl.dropboxusercontent.com/u/111612273/bcIvP.png

        and

        https://dl.dropboxusercontent.com/u/111612273/wzCZV.png

         

        This is what it looks like in Tiled and what I am trying to reproduce: https://dl.dropboxusercontent.com/u/111612273/66G6p.png

         

         

        The tile map is setup and added to the scene using the following code:

         

        var tileDef1 = new SKTileDefinition (SKTexture.FromImageNamed ("landscapeTiles_014"));
        var tileDef2 = new SKTileDefinition (SKTexture.FromImageNamed ("landscapeTiles_036"));
        var tileGroup1 = new SKTileGroup (tileDef1);
        var tileGroup2 = new SKTileGroup (tileDef2);
        var tileSet = new SKTileSet (new [] { tileGroup1, tileGroup2 }, SKTileSetType.Isometric);
        var tileMap =  SKTileMapNode.Create(tileSet, 5, 2, new CGSize (128, 64));
        tileMap.Position = new CGPoint (0, 0);
        tileMap.SetTileGroup (tileGroup1, 0, 0);
        tileMap.SetTileGroup (tileGroup2, 1, 0);
        tileMap.SetTileGroup (tileGroup1, 2, 0);
        tileMap.SetTileGroup (tileGroup2, 3, 0);
        tileMap.SetTileGroup (tileGroup2, 4, 0);
        tileMap.AnchorPoint = new CGPoint (0, 0);
        Add (tileMap);
        
        
        

         

        The tile size used to initialise the tile map (128|64) looks strange to me. It really hasn't anything to do with the texture size of the tiles and unlike everywhere else in SpriteKit it doesn't seem to be using "points". However, this is the size where Tiled is giving me nicely aligned tiles and also SpriteKit is looking good, besides the sorting issue.

         

         

        What am I doing wrong or where am I thinking wrong?

        • Re: Sorting of isometric SKTileMapNode incorrect?
          ccchamberlin Level 2 Level 2 (45 points)

          Hmm.  It appears that the tiles that are the same size are ordered correctly, but the tiles that are different have trouble.

           

          Have you tried making your tile images the same size?  Maybe it's doing some math under the hood that's getting confused when you use tiles of different sizes.

          • Re: Sorting of isometric SKTileMapNode incorrect?
            FuzzyLocks Level 1 Level 1 (0 points)

            I've come across a very similar problem, did anyone ever find a solution?

             

            What appears to be happening is that all of the first tilegroup's tiles are being drawn first, and then the second tilegroup's tiles. This works fine if there are no overlaps, and allows batch texture rendering, but won't work in similar cases. I can't see any flags to change, and that problem along with some problems with hexagons means I'll have to roll my own unless anyone knows better.

             

            I think the way I'm going to do it is to have SKNodes for the map rows with z's increasing from back to front, and for each column there will be +z as the map goes to the right. I think that means that batching will be affected, so maybe performance will be a problem but first it needs to render correctly, then I can worry about possible performance issues.

            • Re: Sorting of isometric SKTileMapNode incorrect?
              fsrs Level 1 Level 1 (0 points)

              3 years later - its still broken