Hi Dyson,
Our current project involves quite a large map (think Zelda).
We initially started out with 64x64 tiles but in order to have smaller physics bodies on the map switched to 8x8 tiles.
We want to ask which would be better performance wise to keep using? Is 8x8 too taxing for MTE when a number of onscreen sprites are present?
Furthermore, is there a difference between using a very large tmx file for the map opposed to smaller tmx files “patchworked” to create a large map?
Thanks.
Hello Aejfootball,
The largest performance impact by far is the total number of displayObjects at any given time; the sprites you create and the tiles and objects spawned by MTE. You can see the total number of active tiles in MTE’s onscreen debug output. If you adjust the map scale so that the number of 8x8 tiles visible onscreen is the same as the number of 64x64 tiles was, you will see more or less identical performance. In all my tests the size of the tile is mostly irrelevant until you start pushing much higher, up to 256x256 or 512x512 for example. On most Android devices you’ll want to keep the total number of onscreen tiles around 1000. On iOS devices you can push closer to 2000. In general you’ll want to keep the number of sprites below 200. And of course the performance will vary with the hardware.
The update including Map Stitching is not quite ready yet. Map Stitching will work by loading the data from one map and inserting it into the current map with the starting location you specify, expanding the map’s dimensions to accommodate. Using a patchwork of smaller maps can give you more flexibility; you can choose when to load new parts of the patchwork instead of loading everything at the very beginning, and you can rearrange or randomize the map by changing which pieces of patchwork you load and where. Once everything is loaded, though, the performance between the two will be the same.
Out of curiosity, why do you need smaller physics bodies? What effect are you trying to achieve?
Hi Dyson,
I’m happy to receive your reply.
Say for example we wanted on screen “Zelda” and a castle. Originally we had a castle comprised of 6 64x64 tiles which was easy for me to draw, cut and stamp into Tiled.
Then I thought we needed a wall around the castle but I didn’t want it to be a huge 64x64 wall, I wanted it to be a thin wall, 8x8.
I tried stamping these smaller “wall tiles” in Tiled but they wouldn’t line up and I could only stamp one little 8x8 wall tile to the top left corner of a 64x64 map tile.
I hope this is making sense, the above may need a re-read if not.
Then I thought if the whole map was 8x8 then we’d have the flexibility to have the smallest possibile details that 64x64 couldn’t provide.
So we changed to 8x8 which was one of the most frustrating experiences I have had (piecing together a castle that used to be 6 * 64x64 from a tile set that jumbled the tiles to reduce redundant tiles was like doing a jigsaw puzzle).
Now we’re on 8x8 and have our castle, our “Zelda” and 15 goblins but we are getting black lines flashing during simulation most noticeably when the goblins surround “Zelda” on top of the castle (before we implemented collision detection detection).
Post collision detection we have a bit of lag which is worrying as the graphics are old school NES type graphics and our tmx is small.
Hence we wanted to know moving forward how to get optimum performance. If I read your post correctly, 6 64x64 tiles on screen should run smoother than if the same scene was replicated using 8x8 tiles (please correct me if I’m wrong).
Hi Dyson,
I’d really love your reply to my reply above please mate. 
Sorry for the delay. Lots going on over here.
The visual contents of a tile and the resolution of that tile’s image are irrelevant. If you fill a 1024 x 768 screen area with 64x64 tiles, that’s 192 tiles (16 x 12), which just about any hardware device could handle with ease. Fill the same 1024 x 768 screen area with 8x8 tiles and that gives you a whopping 12288 tiles (128 x 96)! No mobile device today could handle so many simultaneous display objects. In this scenario, switching from 64x64 tiles to 8x8 tiles is not a feasible solution. A far better solution would be to bake the walls into a new set of 64x64 tiles, custom designed for that specific castle. It means a little more work, but the performance savings will be enormous.
A note on performance and testing. The Corona Simulator does not emulate the hardware performance of a mobile device. When you run an app in the simulator it has access to the full power of your PC / Mac. It is important that you test your game on real mobile hardware often during development to keep on top of any performance problems.
Hi Dyson, thanks so much for your reply.
It seems that bigger tiles are better for performance since less of them have to be displayed on screen. This is good to know and we are going to change tiles accordingly.
One more question though… you said:
" bake the walls into a new set of 64x64 tiles, custom designed for that specific castle. It means a little more work, but the performance savings will be enormous."
Could you expound upon this and how it is done in MTE please?
Baking is actually more of a 3D graphics technique, but the idea here is that instead of using a large number of objects to achieve certain details, you decide what the overall image should look like- a castle with a wall- and you use an image editor to place those small wall tiles into the larger castle tiles. The wall becomes part of the castle tile images so you don’t have to represent it with seperate tile objects.
Thanks Dyson. The problem with baking (if I understand it correctly) is separating The physic able objects from the non physic ables ones.
Does MTE include code for this or do you suggest another api?
While you can’t define multi-bodies for tiles using Tiled properties, MTE does accept input from PhysicsEditor. Using PhysicsEditor you could do things like draw collideable solids within your tiles. If a baked tile has the corner of the castle and also some of its wall, you could create seperate physics bodies only covering the wall and castle, but not the space in-between. PhysicsEditors is available here: https://www.codeandweb.com/physicseditor. You can see PhysicsEditor-defined tiles in the Platformer - Angled sample project, in map AngledPhysics4.tmx.
Hello Aejfootball,
The largest performance impact by far is the total number of displayObjects at any given time; the sprites you create and the tiles and objects spawned by MTE. You can see the total number of active tiles in MTE’s onscreen debug output. If you adjust the map scale so that the number of 8x8 tiles visible onscreen is the same as the number of 64x64 tiles was, you will see more or less identical performance. In all my tests the size of the tile is mostly irrelevant until you start pushing much higher, up to 256x256 or 512x512 for example. On most Android devices you’ll want to keep the total number of onscreen tiles around 1000. On iOS devices you can push closer to 2000. In general you’ll want to keep the number of sprites below 200. And of course the performance will vary with the hardware.
The update including Map Stitching is not quite ready yet. Map Stitching will work by loading the data from one map and inserting it into the current map with the starting location you specify, expanding the map’s dimensions to accommodate. Using a patchwork of smaller maps can give you more flexibility; you can choose when to load new parts of the patchwork instead of loading everything at the very beginning, and you can rearrange or randomize the map by changing which pieces of patchwork you load and where. Once everything is loaded, though, the performance between the two will be the same.
Out of curiosity, why do you need smaller physics bodies? What effect are you trying to achieve?
Hi Dyson,
I’m happy to receive your reply.
Say for example we wanted on screen “Zelda” and a castle. Originally we had a castle comprised of 6 64x64 tiles which was easy for me to draw, cut and stamp into Tiled.
Then I thought we needed a wall around the castle but I didn’t want it to be a huge 64x64 wall, I wanted it to be a thin wall, 8x8.
I tried stamping these smaller “wall tiles” in Tiled but they wouldn’t line up and I could only stamp one little 8x8 wall tile to the top left corner of a 64x64 map tile.
I hope this is making sense, the above may need a re-read if not.
Then I thought if the whole map was 8x8 then we’d have the flexibility to have the smallest possibile details that 64x64 couldn’t provide.
So we changed to 8x8 which was one of the most frustrating experiences I have had (piecing together a castle that used to be 6 * 64x64 from a tile set that jumbled the tiles to reduce redundant tiles was like doing a jigsaw puzzle).
Now we’re on 8x8 and have our castle, our “Zelda” and 15 goblins but we are getting black lines flashing during simulation most noticeably when the goblins surround “Zelda” on top of the castle (before we implemented collision detection detection).
Post collision detection we have a bit of lag which is worrying as the graphics are old school NES type graphics and our tmx is small.
Hence we wanted to know moving forward how to get optimum performance. If I read your post correctly, 6 64x64 tiles on screen should run smoother than if the same scene was replicated using 8x8 tiles (please correct me if I’m wrong).
Hi Dyson,
I’d really love your reply to my reply above please mate.
Sorry for the delay. Lots going on over here.
The visual contents of a tile and the resolution of that tile’s image are irrelevant. If you fill a 1024 x 768 screen area with 64x64 tiles, that’s 192 tiles (16 x 12), which just about any hardware device could handle with ease. Fill the same 1024 x 768 screen area with 8x8 tiles and that gives you a whopping 12288 tiles (128 x 96)! No mobile device today could handle so many simultaneous display objects. In this scenario, switching from 64x64 tiles to 8x8 tiles is not a feasible solution. A far better solution would be to bake the walls into a new set of 64x64 tiles, custom designed for that specific castle. It means a little more work, but the performance savings will be enormous.
A note on performance and testing. The Corona Simulator does not emulate the hardware performance of a mobile device. When you run an app in the simulator it has access to the full power of your PC / Mac. It is important that you test your game on real mobile hardware often during development to keep on top of any performance problems.
Hi Dyson, thanks so much for your reply.
It seems that bigger tiles are better for performance since less of them have to be displayed on screen. This is good to know and we are going to change tiles accordingly.
One more question though… you said:
" bake the walls into a new set of 64x64 tiles, custom designed for that specific castle. It means a little more work, but the performance savings will be enormous."
Could you expound upon this and how it is done in MTE please?
Baking is actually more of a 3D graphics technique, but the idea here is that instead of using a large number of objects to achieve certain details, you decide what the overall image should look like- a castle with a wall- and you use an image editor to place those small wall tiles into the larger castle tiles. The wall becomes part of the castle tile images so you don’t have to represent it with seperate tile objects.
Thanks Dyson. The problem with baking (if I understand it correctly) is separating The physic able objects from the non physic ables ones.
Does MTE include code for this or do you suggest another api?
While you can’t define multi-bodies for tiles using Tiled properties, MTE does accept input from PhysicsEditor. Using PhysicsEditor you could do things like draw collideable solids within your tiles. If a baked tile has the corner of the castle and also some of its wall, you could create seperate physics bodies only covering the wall and castle, but not the space in-between. PhysicsEditors is available here: https://www.codeandweb.com/physicseditor. You can see PhysicsEditor-defined tiles in the Platformer - Angled sample project, in map AngledPhysics4.tmx.