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.
What’s a good workflow / tools for creating images=>tilesets(with extrusion) that will allow you to add/modify/delete tiles to the tileset as you go, without the need to potentially have to rework any of the Tiler maps?
I have TexturePacker for example and it seems to automatically layout sprites for you, so the concern would be it it rearranges the order of images on it. Then you might have to go back and completely rework your Tiler maps. I have spritehelper2 also and I know this lets you update sprites, haven’t double-checked if you can make the sprites same in the same positions however.
Is there actually a way to manage images, extrude, create tilesheet in Photoshop (CS6) itself perhaps that avoids the need for TexturePacker or SpriteHelper and satisfies the above-mentioned goal?
Well I create individual tiles and name them so that I can use texturepacker to sort them by name in the layout area. That way it keeps the order the same and groups like things together. Of course if I added an extra tile that’s already been done in a group (say a type of tree) then if I were to add that in it would insert this into the tile set and could cause an issue in the code.
What you might be better doing is a naming system that adds any new tiles to the end of the layout (numbering for instance).
hi dyson,
I’ve setup zooming and panning on the map but as you’ve highlighted before, it starts to look bad when you scale out (scaling in and panning is perfect) as the edges become visible (and the culling, etc). I’m guessing this is a tricky thing to overcome? I’d have a go at it myself in the MTE file but it looks very complex unless you can suggest where to look? m.zoom function hasn’t helped me figure it out.
Cheers
If you know how far you want to pan out, a simple workaround would be to set a smaller blockScale and start off zoomed in. For example, instead of using blockScale = 64, use blockScale = 32 and call mte.zoom(2, 1) before your enterFrame. This has a side-effect of increasing the apparent camera constraints if you’ve set any.
The upcoming updated will allow you to set a cullingMargin parameter when you call goto() to specify how far the active map region should extend from the edges of the screen. This is also useful to allow physics simulations to run beyond the edge of the screen. This part of the update is actually already in place and working, if not particularly well tested yet.
Both of these have the effect of increasing the number of active tiles, which may impact performance on older, slower devices.
That sounds perfect for the map. I was probably going to have a wide sea border on the edges anyway. I can therefore make the sea border wide enough to allow the zoom out to the level desired.
But I’ll try out the blockScale trick you mentioned in the meantime.
Do you have a view on what features you’ll release on the version after this coming one? Putting it out as a topic thread might be useful when you have time.
Physics support for the various different kinds of Tiled objects is coming along nicely. The objects will automatically generate the correct physics body shape for themselves if the shape property is set to auto, and this includes automatic multi-body generation for polygons, polylines, and non-circular ellipses.
At the moment all objects can be displayed with colored line strokes while ellipses and squares can also have a fill color.
[media]http://www.youtube.com/watch?v=9m044O8W-Xc[/media]
@Coldwilson; The plan was to shift gears over to isometric support after the physics was more fleshed out, and that is still the plan at the moment. I’ll have a better idea exactly what that entails after this update is finished and I can devote some time to it. The seperate thread idea’s a good one. This thread is starting to get a little long, a little more difficult to read through.
@Coldwilson; Preliminary map-storing functionality is in place. Obviously the simulator isn’t the ideal test of this, but without map-storing the 60x40 maps in the RotateConstrainStoryboard sample project take about 22ms to load each time. With the new map-storage code, which was indeed incredibly simple to implement, they take 22ms to load the first time and then about 2ms on subsequent loads.
This time refers to only the code going on in mte.loadMap(). Calling the necessary goto(), loading your sprites, and all that will of course take the time it always does, but these things are pretty small compared to the load time of a large map before the new storage code. This will be particularly useful for people with a very large world or overworld map.
All that Physics’y stuff looks awesome Dyson. I’ve yet to get to making something that’s a simple 2D map with a rectangle (as in basic platformer demo). Making tools takes so long 
@dyson122; That’s fantastic news. my 500x500 is taking about 1.5 seconds on my Galaxy Note 2, it doesn’t sound much but it’s quite noticeable and would cause irritation for people. Not so concerned about it on first load and it can be masked if needed.
I tried out the blockScale idea you suggested for zooming out and it does work properly. I needed to scale it from 42 to 7 to get the zoom level I was after but anything above a zoom of about two (i.e. blockScale of 21) started causing the map to pause and stutter when dragged around. I don’t think this is a phone memory constraint as the map moves around smoothly when I’m not zoomed out using this method or just the same method previously. It might not be an issue on the cullingMargin approach but something to be aware of perhaps.
Hi dyson,
great news, can’t wait to try out these great improvements. Do you have a view on when the documentation will be revised?
I just spotted that you’ve provided the updated docs in the download files, so no worries right now. I was looking at the docs on the website which are the previous versions.
Good catch, Coldwilson. I’ve updated the docs here in the sale thread.
@Everyone: I have a question for all MTE customers and prospective customers, which I’ve stashed in a separate thread to keep this one nice and neat: http://forums.coronalabs.com/topic/38235-mte-coronastein3d-price-increase/
Hi all,
Firstly, dyson, many congratulations on MTE! It looks awesome and I just wanted to join others in saying what a great piece of work it is!
I only purchased it recently and this morning has been the first proper chance I’ve had to play with it but I’m pleased to say it does everything it promises and is looking great! I really can’t wait to start digging in, deconstructing the demos and learning how to use it to create a couple of RPGs and platform games I’ve been thinking about for a while.
Great stuff! Looking forward to all future updates!
Android Performance
I thought I’d feed back on Android performance as there were some queries/concerns relating to this (I know I had some). Well, I’m pleased to say it’s good news. Very good news. I have the following 3 Android devices (my old phone, current phone and tablet) and I’ve built and deployed all the demos to each:
HTC Desire / Android 2.2.2
HTC One X / Android 4.1.1
Asus Eee Pad Transformer Prime (TF201) / Android 4.1.1
As you’d expect, the HTC One X and Asus Transformer Prime had no problems at all with performance. The biggest surprise, however, was that the older HTC Desire performed brilliantly as well. Here are the average FPS for each demo on each device:
0v844 Demo / HTC Desire / HTC One X / Asus Transformer Prime
CastleDemo / 30 / 30 / 30
Platformer - Angled / 30 / 60 / 60
Platformer - Angled PHYSICS / 20 / 60 / 60
Platformer - Basic / 30 / 60 / 60
Platformer - Basic PHYSICS / 20 / 60 / 60
Platformer - Sonic Finale / 30 / 30 / 30
RotateConstrainStoryboard / 30 / 30 / 30
Performance was even good when the average FPS occasionally dropped to 22 on the Castle Demo on the HTC Desire, which mostly occurred near the animated water tiles when not on basement level. Any visual lags at these points were negligible and certainly didn’t interrupt gameplay or enjoyment. If the FPS were not output to screen I doubt I would have even noticed.
I tested the 2 physics demos in both “hybrid” (MTE default) and “normal” draw mode. On the HTC Desire the average FPS were 20 for each in both modes and while it obviously wasn’t as smooth as the HTC One X it was still perfectly playable. It’ll be interesting to see how physics performance progresses with future updates.
So, overall I’m very impressed - not to mention happy and relieved! I’ll certainly be targeting all 3 in future game development with MTE.
Hopefully all that will prove useful to someone besides me. 
I appreciate the kudos, AppDeveloperGuy!
I also much appreciate the performance testing you’ve done. A lot of people have asked for Android performance and, given the range of devices and manufacturers, the more numbers we have the better.
CastleDemo, SonicFinale, and RotateConstrainStoryboard are configured to run at max 30fps in certain situations, for example if the detected device is not an iPad, or if it is an Android device. If you’d like to test your newer devices against 60fps in these apps you can alter the fps selection in each app’s config.lua file. The samples were designed to run properly at both framerates. SonicFinale in particular is a treat at 60fps.