Have you seen this game? It’s what came to mind when I saw your lighting video: http://www.robotloveskitty.com/LoD/
Also I saw in corona graphics 2.0 they have normal maps so they would work perfectly together.
I have seen that game, and I think it looks great!
Quick status update: I’ll be igniting a petroleum product at zero hundred hours to get this update finished for release tomorrow. It was not quite as ready as I though it was earlier this week.
Woot! Thank you Dyson and I know that personally I can’t wait!
Great stuff and much appreciated!
Awesome looking forward to it!
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.
This friday I’ll be releasing yet another update allowing base64(uncompressed) and csv layer encoding in TMX files, PhysicsEditor support, and a function for automatically ordering sprites based on Y position ala Double Dragon and similar fighting games!
Next week and probably the week after it I’ll be working on MTE’s new lighting system.
Nice you already did the physicsEditor support. Thanks. Looking forward to try it.
Also looking forward to see what the new graphics engine can do for MTE.
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.
MTE v0.927 - http://gum.co/staO
MTE v0.927 adds user-requested functionality and improvements.
MTE can now load TMX files with CSV and Base64(uncompressed) encoding. I’ve reworked the XML parser to significantly improve loading times, but the best current option for encoding is CSV. CSV encoded files are very small and can load nearly as quickly as Json exports.
Preliminary PhysicsEditor support is in place. PhysicsEditor is an amazingly-useful tool for automatically generating shapes for complicated objects and setting up their physics properties. You can direct MTE to the PhysicsEditor output file by setting a tileset’s physicsSource property in Tiled. You can load a physics shape into a tile by setting it’s shapeID property. It is also possible to give an arbitrary tile both physicsSource and shapeID properties to load shapes from different output files in the same tileset. The Platformer - Angled PHYSICS sample project has a new map, AngledPhysics4, demonstrating this new functionality.
You can now sort sprites in a given spriteLayer by their Y position on the map. Activate the feature by setting mte.enableSpriteSorting = true. Set sortSprite = true in a sprite’s setup table to add it to the depth buffer. Sprites closer to the top of the map will be further behind sprites closer to the bottom of the map. This is useful for when “tall” RPG style sprites are used, or in games with a forced 3D perspective ala Double Dragon and other side scrolling fighters.
Aside from these new features I’ve made a few changes and corrections.
-The lighting parameter of a sprite’s setup table now takes a boolean instead of the string “off”.
-The function loadTileSet() will now immediately throw a warning if the source file you specified does not exist (in the form of a path-to-file not found message), instead of allowing you to specify a nonexistent file.
-I’ve updated CastleDemo with some user-suggested improvements and modifications. The sample also now includes the code necessary for touch scrolling and pinch zooming on multitouch devices in a commented-out section. The old four-button Dpad is now a single displayObject.
I’ll have an eye out for bug reports and user requests.
I hope you’ve enjoyed the updates to MTE thus far! I have some fun new functionality in the works, as always… 
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
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.
Thanks for your fast response, I thought that already…, thought it should be a help to create a tileset…
I didn’t understand, that you mean to split the tileset into every single tile into a file as preparation for TexturePacker(I’m new to this, seems to be like the program works).
Thank you so far, I hope it will work.
Unfortunately I have 2 more questions:
Update:
a) In Lime, you could use map:slideToPosition(worldPosition.x, worldPosition.y, 800) to slide around the map.
Do you have something similar to this?
Testing mte.moveCameraTo rightnow.
b.) Solved: I was looking for mte.constrainCameraToScreen({})
I just keep landing outside my painted map,
means a black background. If I set locX = 0, locY = 0 for example, I’m half outside my map.
Is there a possible way to fix this easily?
It looks like this (tile coordinates):
[black][black][0,0][0,1]
[black][black][1,0][1,1]
After Gimp you will have a large number of individual image files, each one containing exactly 1 tile. When you load these individual tiles into TexturePacker and set extrude = 1, what TexturePacker is doing is stretching the edges of the tile by 1 pixel in every direction. In your case, every tile is 32 x 32 pixels. Extruding them increases their size slightly to 34 x 34 pixels.
When Corona loads an image such as a tile, by default it uses linear interpolation (if I remember right) to smoothly scale the image to the desired size. What this often does is create visible edges between tiles, the grid you mentioned in your private message. The reason for this, as I understand it, is that Corona is interpolating between the pixels at the edge of the tile and the pixels of the neighboring tiles. Extruding the tiles keeps the interpolation within the bounds of the tile, solving the problem.
I’ve whipped up a quick example using a small part of your tileset.
Steps A through C instruct you to set up guides in Gimp. These guides will appear as dashed blue lines and are used by Gimp’s Slice tool to divide an image into pieces.
Steps D through F instruct you on how to properly set up Gimp’s Slice tool. After clicking OK (step F) Gimp will process for a moment. When it is finished navigate to the folder you chose in step E. You should see a long list of image files named slice_0_0, slice_0_1, and etc.
Open TexturePacker. You can add your tiles to TexturePacker a few different ways. 1) You can select all of the files in your folder and click and drag them into the Sprites pane of TexturePacker, or 2) you can click Add Sprites in TexturePacker, navigate to the folder you chose in step E, highlight all your tile image files (slice_0_0, slice_0_1, etc) and click Open. At this point you can continue on with the steps in “MTE Tilesets, Map Structure, Getting Started.pdf” as written.
After steps 2 through 5 you should see something like this:
You’re tiles may appear out of order. I recommend setting Algorithm to “Basic”, Sort By to “Name”, and Order to “Ascending”. You can alter Max Size and Size Constraints to get all tiles lined up properly.
The difference between an extruded and non-extruded tileset may not be obvious at first, but if you look closely at some of the grass tiles, you’ll see that the borders between the tiles are exaggerated. They’ve been extruded- stretched out- by one pixel.
The stretched area between tiles is not visible when you run your game, only the center 32x32 pixels are used. The stretched areas simply prevent Corona SDK from creating edge artifacts between tiles.
There are other ways to prevent edge artifacts, but I’ve run out of time for the moment, so I’ll touch on those later!
Thank you so much! It’s nicely written, you should put it into your tutorial .pdfs!
Well, I figured myself out after you mentioned the gimp story. But somehow it keeps crashing with the same error…
But there is fortunately another way to solve this.
(the sort by TexturePacker is kinda strange, but thanks for the advice and please answer my other 2 questions please, especially the last one )