Woot! Thank you Dyson and I know that personally I can’t wait!
Great stuff and much appreciated!
Awesome looking forward to it!
Collision detection is something you would set up in much the same way as in orthographic maps! The difference here is that you’ll want to put the collision points / physics body down near the enemy’s feet.
Speaking of physics, while there won’t be anything stopping people from using physics in an isometric map, it is important to remember that the map’s axis’ are skewed in relation to each other. We see this as perspective, but the physics API does not. For example, if you put a flat diamond shaped physics body near the player’s feet, basically the size and shape of one isometric floor tile, and you put the same body on a wall or stone or what have you, when the player hits the obstacle he will slide against it rather than coming to a stop. From our perspective he is walking directly against it, but in the physics simulation’s perfectly flat plane he is actually moving against it at a slight angle. I don’t believe the physics API can be configured differently, but if so someone please let me know!
thanks for clarifying! I see you are using a virtual gamepad in the engine, do you also think about moving by touch? like a pathfinding to the point you clicked (or attack an enemy you clicked)?
MTE v0.910 - http://gum.co/staO
The big one-oh grows ever nearer! MTE update v0.910 is to Isometric Map support as MTE update v0.844 was to Physics support- Isometric Maps are now supported, however there is still some work to do, some refinements to be made.
So, what works as of right now? A great deal, actually! Most of MTE’s standard movement and camera functions are setup to work with both orthogonal and isometric maps, as well as world wrap, constraints, and many others.
What isn’t quite there yet? In a word; Physics. I definitely advise MTE users to experiment with physics in Isometric Maps. The more feedback I get, the more quickly I can hunt down and squash any related bugs.
This new update also brings preliminary support for TMX map files and TSX tileset files, both of which are XML files used by Tiled. TMX files are Tiled’s native map file format. The new support for TMX files allows developers to make changes in Tiled, hit save, refresh the Corona Simulator, and immediately see the changes reflected there. No more exporting new Json files after every little change! TSX files are perhaps less well known. Tiled allows you to export all of a tileset’s properties into a TSX file. You can then load these properties into each new map you make with that tileset, rather then having to reenter them all over again for every different map.
MTE v0.910 includes a brand new sample project demonstrating both Isometric Maps and TMX/TSX support; the creatively named IsometricStoryboardTMX 0v910. The sample also shows off a way to vary the appearance of your tiles using property listeners. Not much has changed in the documentation, so this sample project is definitely the best place to start for those of you who want to dive right in.
As it was with Physics in 0.844, this update is not the end of the work on Isometric support. I’ll be looking forward to hearing what MTE’s users still need in terms of functionality and what bugs and glitches need to be corrected. The next update will not take five weeks to finish! I’ll be endeavoring to get things patched up as soon as possible. There are also some corrections and alterations requested that I have yet to get to- such as a flag to allow sprites to leave the map bounds- and these will be among the first things I complete for the coming patches.
What comes next? Physics and Isometric support were the two mega-features I originally promised, but they are not the end of MTE development. The engine will continue to evolve and expand as developers seek more functionality and Corona Labs adds exciting new capabilities to the SDK! On the immediate horizon after patches and bug fixes is the addition of a lighting system and a mechanism for allowing physics collisions anywhere on the map at any time, regardless of the current camera position.
Enjoy!
Great! Thanks for your hard work. Downloading now!
Nice thank you Dyson! Can’t believe how smooth and great this Iso example is!
Totally groovy! A whole new world of possibilities opens up now, especially with the amount and quality of free iso tilesets available on the net.
I wonder however how much all these added features (physics, iso, etc) affect the performance of the actual tile engine. That is what I purchased MTE for… lightning fast 2D tile maps.
My brain is pretty fried right now, but off the top of my head, the new functionality should have very little impact on performance. In the cases of Physics and Isometric maps, the new code is not run unless you are actually using Physics or Isometric maps. In the case of Physics you have to explicitly turn it on, at which point it does of course use the necessary processing power to run it’s black box physics simulation. This is inescapable. In the case of Isometric support, the new code for translating a 2D grid of tile data to an Isometric view is triggered by a map property generated automatically by Tiled.
This is all handled by sparse if-then blocks throughout the engine. The function updateTile() is a great representative example of what I’m talking about. You’ll see a handful of lines such as “if map.orientation == 1 then” (is the map Isometric) and “if enablePhysics[layer] then” (is Physics enabled). If you aren’t using these features, the code contained in the blocks doesn’t execute. The engine does have to run these checks, but the overhead of if-then statements is trivially small compared to the processing demands of the rest of the engine.
The inclusion of Isometric support should not impact performance, but Isometric maps do themselves have a higher performance demand then orthogonal maps at the moment. If you zoom the map out you’ll see why. The engine generates a diamond-shaped culling region large enough to fill the rectangular device screen. Isometric tiles also tend to take half the vertical space of orthogonal tiles because of the squashed perspective, requiring twice as many.
Now, I do often roll back certain performance improvements which make working on the engine cumbersome or obfuscate certain details of its operation. As an example take the two internal functions used for generating tiles and moving the camera, moveCameraProc() and updateBlock(). Ideally moveCameraProc would contain the code of updateBlock to avoid making a function call, however this makes moveCameraProc very long and difficult to work with. The performance impact of these changes is very low, and they are only temporary; easily converted back to the more optimized form.
Of course, please do let me know if you run into unexpected performance problems! Optimizing code is one of those things I find oddly enjoyable, trying to get that little bit of extra performance, trying to work out clever ways to avoid unnecessary calculation. It’s fun stuff!
Thanks for the in-depth reply Dyson, much appreciated. I have yet to actually delve into MTE’s code and am still not getting enough free time to even play with it. that should change very soon however 
Do you have an example of this?
Thanks,
Noral
Hello Noral,
The new sample project IsometricStoryboardTMX uses both TMX and TSX files for loading its maps and tile properties. It’s folders are arranged in such a way that you can open any of the map TMX files in Tiled, make changes, click save, and see those changes by relaunching your game in the simulator.
The gamepad is not integral to the engine, but rather one of the things set up in the user code for the sample projects. Clicking a direction basically calculates the destination tile and calls a moveSpriteTo with the location of the tile as the destination. In this case I go with the gamepad because most of the examples have been about other functionality, like storyboard, or platforming movement, rather than about the input itself.
Touch movement would be pretty simple, depending on whether you wanted to do pathfinding or not. An mte.convert call in a touch listener would give you the map location of the touch. You could move the sprite directly to that location, or you could run the locations through your pathfinding code. From there things get tricky with the current MTE version because you’d have to set up code to iterate through the waypoints generated by your pathfinding code.
The plan, as it currently stands, is to modify moveSpriteTo so that it will accept a “path” parameter. From there it would move the sprite from start to finish, through the waypoints, automatically. And, as I said before, I’ll probably add Jumper or come up with another pathfinder function for MTE.
What I’ve been doing this week is working on suitable painter’s algorithms for isometric maps. You saw part of that in the previous video; the player sprite appeared in front of the stone pillars while walking in front of them and behind the stone pillars when walking behind them. That was not a trick of split tiles and layers; those pillars and wall pieces are single, tall tiles, they are not broken up messily into top and bottom pieces. I’ve fleshed it out and added a second optional algorithm useful when you have many different terrain levels you’d like to move between. Think of the worlds of such Dwarf Fortress clones as Towns, which are composed of isometric blocks. I’ll have a video of this ready tomorrow.
Hey Dyson I’m intrigued by why you’re saying pathfinding is tricky in the current iteration of MTE - I managed to get AI bots walking in a patrol state, and searching for the player using raycasting (i.e a stealth game) then switching to a chase state pretty quickly and without much fuss. It was based on an A* algorithm from MobileTuts and a FSM implementation - essentially the AI bot class had a destinationReached method that checked whether the bot was at its target destination and if so to increment to the next location stored in a path array.
More then happy to share ideas if people need it as that project is currently on hold (sniff)…
Hi SegaBoy,
If you have any examples or code snippets you could post that would help out with using A* and the features you mentioned I know I could use some real examples. I am new to pathfinding and mobile gaming in general so a lot of this is new to me. Just wanted to throw that out there as others may also be in the same position!
Thanks and nice work!
Hopefully I’ll have some time over the weekend to prepare some code - I don’t want to supply everything as it’s a project I’m still going to work on in my own time. However I do see lots of people ask about these kinds of features, so more then happy to help - however be warned, I’m not the type of person that just gives code as I don’t believe that ever really helps people in the longterm
Also Dyson I may be going against the grain here however I don’t think it’s your responsibility to add features to MTE that developers can implement themselves. Sure make things more achievable, but adding pathfinding capabilities when it’s already possible seems a little redundant to me. I’d much rather you worked on features that are someway beyond our control.
Hi there,
I moved from LIME to MTE because of performance and especially sprite artifacts!
So I started to read the tutorial “MTE Tilesets, Map Structure, Getting Started.pdf”
and followed the instructions:
Step-by-step what I did so far:
-
I got a 32x32 Tileset .png (from the Lime Tutorial, doesn’t matter)
-
I opened it with TexturePacker:
disable Auto Alias; disable Trim
Padding to 0; Shape Padding to 0
Extrude to 1
=> publish as forest.png
(named the old one to original_forerst.png)
3.Opened Tiled:
New 32x32 Tileset => name=“forest”
loaded the (extruded) forest.png
=>Set Margin to 1 and Spacing to 2.
=>Set Drawing Offset X and Y to 0.
saved as mytestmap.json
-
Put everything in the project folder
-
Change main.lua to:
local mte = require “mte” mte.loadTileSet(“forest”, “forest.png”) mte.loadMap(“mytestmap”) mte.goto({locX = 10, locY = 10, blockScale = 32})
Now I’ve got the error:
mte.lua:5450: Incorrect number of frames (w,h) = (32,32) with border (1)
in texture (w,h) = (512,2048)
Failed after frame 901 out of 907.
I know, that “=>Set Margin to 1 and Spacing to 2.” and the new Tileset.png is the cause,
otherwise the code works with no problems.
I’m sure some of you guys figured out to solve this, so please help me with this.
I’m getting really desperate to solve this artifact problem, else I can’t start with
my project. And I really wonder, why MTE/Corona doesn’t accept this Tileset 
I know that other guys will have the same problem with this, that way please help!
Thanks so far.
(I’ve added the files, that way you can check, what’s wrong. And I don’t have @2x files, because
I tested it without a config for @2x and it’s still the same bug)
Please, don’t forget to add mte.lua
https://dl.dropboxusercontent.com/u/13923659/My_TestProject.zip
That sounds awesome, SegaBoy! I’d love to see a video of that in action.
Also, good point about adding features Devs can add themselves.
Hi SegaBoy,
I appreciate it - I definitely wouldn’t want your entire project but I was just saying I am new to a lot of this so any snippets/examples of certain functions etc. are extremely helpful - especially when it comes to something not native to the engine.
I know a lot of these features may be somewhat easy to implement, but finding the easiest examples to learn from isn’t always easy!
Thanks and it sounds great!
Oh Dyson - that Isometric example looks amazing!
The problem is that you did not split your original tileset into individual tiles before loading them into TexturePacker. You can do this by following steps A-F, between steps 1 and 2
A. Load a tileset into Gimp.
B. Click and drag from the vertical ruler to place guides between each column of tiles.
C. Click and drag from the horizontal ruler to place guides between each row of tiles.
D. Go to Filters -> Web -> Slice…
E. Choose the desired output folder, image type, and name prefix. Do not add spacing.
F. Click OK.