MTE does not currently support isometric maps. Once support is in place, doing what you describe would likely be a simple matter of looking up the current angle and setting the sprite sequence accordingly.
On an unrelated note, Corona Labs has stated that official Ouya support is “coming soon.” What a perfect excuse to buy the console! Now that I’ve finally tracked one down I’ll run some tests with the sample projects and see how they perform.
@corona5196; The most common causes of these problems are misplaced
files and misspelled filenames. Your code expects cavemap1.json to be in
the root directory of your app. You should also make sure you aren’t
missing any capitalization.I’ve run out of time for now, but I will be on later today to help as well.
Thanks Dyson. well as far as I can see everything is fine. In my project folder I have…
build.settings
cavemap1.json
cavetiles1.png
config.lua
main.lua
mte.lua
Those all look fine to me and my code has the right caps etc. What the heck?
If anyone can offer any insight that would be great. Here is a link to a zipped version of my project if anyone can look and see if it works for them? NOTE: zip file doesn;t include the MTE.LUA file so you would need to dump that in there.
That would be pretty straightforward to code, jstrahan, as long as you don’t use the Physics API. I’ll see what I can do about getting Physics working correctly with world rotation.
doesn;t include the MTE.LUA file so you would need to dump that in there
I appreciate the forethought 
I apologize for the inconvenience here, but MTE is very picky about the width of tileset images. They must exactly fit the number of tiles in the row. If you crop your image from 512x512 to 510x510 and update the imageheight and imagewidth values in cavemap1.json from 512 to 510, it will work. Just remember to load the new image.
Okay my brain is becoming a bit numb right now.
I have my source tileset in gimp which is 480x480 in size. Each tile is 32x32. I web slice those to a folder and then run a renamer over them so they will have the correct order in texturepacker.
I run texturepacker and set geometry width and height to 512, layout algorithm to basic, sort by name, and order ascending. This makes mu tiles appear in texturepacker the same as they do in gimp. I disable auto alias and trim. I set border padding and shape padding to 0, and set extrude to 1.
I then publish the tileset as cavetiles1.lua and cavetiles1.png
I apologize for the inconvenience here, but MTE is very picky about the width of tileset images. They must exactly fit the number of tiles in the row. If you crop your image from 512x512 to 510x510 and update the imageheight and imagewidth values in cavemap1.json from 512 to 510, it will work. Just remember to load the new image.
So what am I supposed to change and how am I supposed to change it? Please forgive me but I am new to corona etc.
Okay I totally get it now, I think. can you confirm…
I make my tileset and I subtract 2 pixels from it’s width and height. then in my json file modify the tileset width and height to match.
If this is correct then is it always the case that you need to modify files to suit the engine? Or does this only happen in some circumstances?
In TexturePacker you can change the Size Constraints in the Geometry section from “POT (Power of 2)” to “Any size.” This will always yield a useable image.
Alternatively, add 2 to the size of your tiles, which are 32x32. This gives you 34x34, the size of the tile images after extrusion. Count the number of tiles in one row of the source tileset. There are 15 tiles in each row of your source tileset. Multiply 34 by 15 to get the exact ideal width of your new tileset. The result is 510.
After running your tiles through the renamer, add them to TexturePacker, set Size Constraints to “Any size” and Fixed Size W: to 510. Set the rest of the options as usual. This will yield a tileset image with the correct width, and also keep all the tiles in the same order and place as they are on the source tileset.
Many thanks dyson! So it seems that I don;t need to resize the tiles in gimp to 34x34 or anything. Just changing tilepacker to “Any size” and setting both width and height of output file to 510 makes it work
Hi, I noticed that when I was using MTE that my memory (ram) on the debug function keeps continuing to rise no matter what. This alarmed me because I thought I made a memory leak, however when I run the castle demo I get the same thing. Is this just the simulator having problems or is there something broken with the castle demo too? Maybe it has to do with the recently added physics?
EDIT: I noticed that after a minute or so the memory will drop down to the original value. Do you know what causes this steady rise and then drastic fall back?
The memory usage rise and decline is caused by the accumulation of Lua garbage and the eventual collection of it. I’m not sure if this is entirely avoidable, but I’ll look into it. There could be memory leaks here and there I have to plug up. A simple solution for the moment is to place the following line of code in your enterFrame event:
collectgarbage("step", 40)
You may have to adjust the step size depending on the size of your map, but 40 is sufficient to hold CastleDemo at about 5MB.
Playing with vector Tiled Objects:
Next on my todo list is adding physics support to all of them.
Hi,
I’m quite new to Corona and Lua (and coding) but managed to get a 100x100 map working using Tiled which drops into other maps when encountering objects. I’ve used your code example on RotateConstrainStoryBoard to build it using scenes. So far I have three scenes setup where one is the main 100x100 map and the other two are small instances of a few tiles each at present. And this works great back and forth between scenes.
Today I decided to enlarge the map to 100x100 tiles. This still works as expected but now the time to return to the main map from a instance is pretty slow (several seconds). I realise this is due to the map size but given the capability of MTE to use large maps I was wondering whether you have any suggestions.
The main issue is that once I leave scene1 and then return it needs to run mte.loadMap to acquire the data such as tile properties (from Tiled). mte.loadMap resides in willEnterScene. In my naivety I’ve tried moving it to the start of the code but this fails in the same way as the data isn’t there after returning from scene 2 or 3. I guess I could attempt to load the map into the mydata.lua store where M resides for global data to cross between scenes but this is beyond me right now and I’m not sure it avoids doing mte.loadMap anyway.
Ideally I’d like my map to be able to handle larger than 1000x1000 as you’ve demonstrated in one of your videos but I can’t see this being feasible. I have considered breaking the map into smaller chunks as new scenes but one of the things I’ve setup is the zoom and scroll function to move around the map at will and that would then become unworkable I think.
So how do I load a large map and keep it so a loadMap isn’t needed or how do i assist loadMap to reload the map quickly?
Many thanks for such an awesome tool
On second thoughts perhaps I’m being overambitious with expecting a million tiles to load quickly. I’ve tried it at 500x500 and it’s just about ok I think. My tiles are at 42x42 at the moment which I now realise is wasting memory as it’s not the 2 factor and I should go for 32x32 or 64x64.
However, I’d still appreciate you thoughts on this.
ah, I see you’d thought of this issue previously.
At the moment I handle map removal by not handling map removal. Loading a map clears out all of MTE’s map arrays and refills them with the new information. Now that you mention it I should probably allow users to handle this themselves if, for example, they want to hold the world map in memory while going into a town to reduce loading times between the two. That shouldn’t be too difficult to implement.
Thanks for reminding me about this, Coldwilson. As I mentioned back then, this sort of thing should be simple to implement. I’ll see if I can work a solution into the coming update, which is a couple weeks out. Probably add an optional flag to mte.refresh() to store the map arrays out of the way until the same map is loaded again.
That would be absolutely fantastic. If it weren’t for this tool I’d have probably given up trying by now.
While you’re here (or anyone else if they know). If it’s more optimal on memory to have 32x32 or 64x64 tiles then what’s the right thing to do in an editor (e.g. TexturePacker) when using an extrusion value. I’ve got an extrusion border of 1 so that would make the tiles 34x34 for instance. Should I make the tiles 30x30 to account for this to keep within the bounds?
The tiles are less important than the tile set image as a whole. A 510x510 tile set occupies 512x512 worth of memory, while a 513x513 tile set occupies 1024x1024 in memory.
wow - so just to get this right, I am far better off from a texture memory point of view using 62x62 size tiles (extruded by 1 pixcel to 64x64 using texture packer), then using my current 64x64?
That would be true if the tiles were loaded as individual images, but they are not, they are frames in an imagesheet. The imagesheet -the entire tile set- is the thing whose dimensions you should try to control. For example, if you extrude 32x32 tiles to 34x34 and arrange them in 15 rows of 15 tiles you get a tile set image of 510x510. This is an efficient size, because it is just under 512x512 and so you aren’t wasting much space in memory. The 34x34 tiles do not occupy 64x64 in memory because they are not individual image files, they are frames in a sheet.