Congrats, dyson, it’s finally out 
I will be trying it out in the next few weeks. But I am still in a learning curve and probably not going to help much in finding bugs. If I do find any, I will let you know of course.
Thanks for your hard work & exciting upgrade.
Hi dyson,
Now that I updated to the new Mte v 0980, I noticed that objects I made in Tiled with physics properties will only work half the time(i’m making static walls) and set in hybrid mode I can see that the physics turn off when my character moves in certain places on the map. I figured maybe this has to do something with the offscreenPhysics so I added this property to true and I noticed that it works now. Does mte know how many tiles are on screen or do i have to specify this? Not sure if this is a bug or not or whether Its my setup.
Also, this doesn’t have to do with the update. If I have a tile which has transparency(maybe a ball for example) the areas which should be transparent show as white when my game is loaded. In the tiled editor it looks fine. Is this something to do with tiled properties?
Hi dyson,
Right now my character is moving one tile at a time , can i reduce it to 1/2 tile at a time, or any other way to make my character move slowly .
Hello Trompeta and Kumarks,
The engine calculates the number of tiles it needs to fill the screen at any moment. You can use the cullingMargin parameter of setCamera() to push the edges of the active map region further from the edges of the screen, increasing the number of tiles and allowing physics objects to move further offscreen. Setting offscreenPhysics is your best bet if you need enemies or other important physics objects to move freely across the entire map. If you run debug() in your enterFrame event it’ll display a count of all active tiles.
I’ve never had that problem with transparencies before. Could you post a screen shot and a link to the tileset you’re using Trompeta?
As for moving the character by half a tile, I believe most of the samples use the locX and locY parameters of moveSpriteTo(), but the function also accepts levelPosX and levelPosY parameters for pixel-by-pixel movement. If your tiles are 32x32 in size, moving a sprite by 16 pixels will move it half a tile. You can also slow the movement down by adjusting the time parameter.
mte.moveSpriteTo({sprite = mySprite, levelPosX = mySprite.x + 16, levelPosY = 0, time = 500}) --OR mte.moveSprite(mySprite, 16, 0)Hi dyson,
I plan (at the moment anyway) to continue using addSprite and moveSpriteTo but would like to benefit from the increased performance. Do you have any plans to integrate Corona’s native transition and translation functions in to MTE’s movement functions?
I tried that early on in the rewrite, but I hit a snag I couldn’t fix or work around. Say you want to move a sprite from location to location, again and again, as in most of the samples. For example, walking in any one direction in CastleDemo. The sprite moves smoothly without pauses or breaks in the motion. When you try to accomplish the same thing using transitions, you’ll find that sprite pauses for a frame or two at each tile location. The problem I found is that the transition functionality does not allow a position transition for one sprite to stop and another to start all in the same frame. I worked the problem for a few days, but the complexity of my solution was beginning to outweigh the gain. The code would have been harder to maintain and less flexible than MTE’s current movement system. So, the engine rewrite was designed to allow the use of transitions and translations without using them itself.
If you guys could go to my survey and cast a vote on what you think MTE should cost, that would help me out!
http://forums.coronalabs.com/topic/44769-million-tile-engine-price-survey/
-or
http://forums.coronalabs.com/topic/44771-million-tile-engine-price-survey/
Please don’t answer both of them 
I’m trying to cast a wide net, not get duplicate results!
MTE 0v980-9 - https://gum.co/staO
This update corrects errors reported for MTE 0v980-6, most notably an error causing the camera to “stick” to the edge of a camera constraint in certain situations.
The update also includes a fancy new sample project demonstrating the use of perlin noise and heightMaps; Sledge! Guide the sledge around the mountainous, snowy terrain! Keep in mind that the heightMap functionality built into MTE is computationally expensive. This is best kept to relatively new devices such as the iPhone 5 or Samsung Galaxy S4.
Hi Dyson,
looks amazing on the video. I tried it on my mac, it runs very slow for some reason but thought it worth noting that it comes up with this message for us non pro users:
"Your project uses premium graphics features available to Pro (or higher) subscribers. You can view these in the simulator as a demo, but you must upgrade to see them on a device."T
Thanks.
Correction, it runs ok from the Corona Simulator, just very slow when I ran it in LuaGlider.
I added “portrait”, “portraitUpsideDown” to be supported in build.settings
and after I rotate the device (Simulator) to portrait mode, there is a black area at the bottom of the screen that MTE does not utlize. Is there some parameter that I need to set in order for it to work?
PS. I tried with CastleDemo, please see the attached screenshot.
Please forget my last post.
After I retried with your latest MTE release (0v980-9), this problem does not exist.
The heightMap system stores tile images in shape objects and deforms the shape by altering it’s path, which requires Corona’s Premium Graphics in Pro or Enterprise. I’m glad Corona at least lets people test in the Simulator! That is good to know.
Hey Dyson thanks for the reply,
I didn’t think it was MTE, the transparency problem was just with the tileset software I was using even though I set black to the transparent color in Tiled somehow it was still showing so I had to manually remove all the extra areas to make transparency in photoshop (for anyone whose wondering).
I have good news and bad news. The good news is that it is the end of January and the MTE rewrite is nearly complete! The bad news is that it is the end of January and the MTE rewrite is nearly complete. Trying to predict the challenges of programming something this complicated is tricky. I’m pleased that I was not far off, however not far off is still off. What went wrong? Nothing went wrong, really, but some unexpected difficulties reared their ugly heads when I moved into rewriting Isometric support. Orthographic maps match the coordinate system provided by the Corona SDK, however for Isometric maps MTE must work in an arbitrary, imaginary coordinate system managed internally by the engine. Whenever you have multiple viewports not all of which conform to “reality” you introduce the potential for real mind-boggling and difficult-to-debug display problems.
As of today I’m pretty sure those are behind me. I’ve said that before, of course, and that is why I choose to qualify the statement. My plan as of today is to get something out to all of you in two weeks. That gives me a week to finish up some of the things that fell by the wayside during my battle with Isometry, such as perlin noise and heightmaps. The second of the two weeks will be for updating and fleshing out the documentation.
Will that be version 1.0? Yes and no. It will be the feature-complete engine. However I’m going to wait a little while after releasing the update for bug reports to come in. I’d hate to move MTE out of Beta while there are still bugs lurking. More documentation and examples will also filter out during that time.
I apologize for these delays. I know some of you have apps waiting on the rewrite optimizations or the 1.0 release, and I am committed to getting these things out to you in a timely manner.
Thanks a lot for the update.
Can’t wait to see its coming out.
Why display one map when you can display four? Might as well use perlin noise to come up with some nice mountainous landscapes while we’re at it. And we might as well rotate each one at a different rate for the sake of vertigo.
[media]http://www.youtube.com/watch?v=aOjzaA7KYyY[/media]
Perlin noise is convenient, but we might as well run a couple completely different map types at once.
[media]http://www.youtube.com/watch?v=ohuxJg48peM[/media]
Why settle for moving a map when you can move the Container holding the map? Using a Container object is optional, but it does conveniently clip the edges of the viewport to nice clean lines.
[media]http://www.youtube.com/watch?v=Q2_GSSbXn1Q[/media]
Of course, any given hardware device can only handle so much. The iPad2 can handle on the order of 1500 simultaneous tiles. If you display four different maps simultaneously you’ll want to make sure the total tiles across all of them is within the 1500 limit, or whatever performance envelope your target device has. Each instance comes with overhead as well, so the total tiles should be somewhat lower than what you would aim for while displaying a single map.
I’ll have more information for you all over the next few days.
Hello Dyson,
I am new to Corona SDK and buy your product just yesterday. According to the instructions in your documentation and reference on the forum. I want to make an RPG game like hayday but there are some issues I do not understand.
Can you write some examples of how to use the camera functions via touch events to move (drag) map like Hayday game?
Here is my code:
display.setStatusBar(display.HiddenStatusBar) local mte = require("mte").createMTE() mte.loadTileSet("myTileSet","mytilesets.png") mte.toggleWorldWrapX(false) mte.toggleWorldWrapY(false) mte.loadMap("mymapfile.json") mte.setCamera({locX = 8, locY = 6}) local mapObj = mte.getMapObj() function mapObj:touch( event ) if event.phase == "began" then self.markX = self.x -- store x location of object self.markY = self.y -- store y location of object elseif event.phase == "moved" then local x = (event.x - event.xStart) + self.markX local y = (event.y - event.yStart) + self.markY self.x, self.y = x, y -- move object based on calculations above end return true end local gameLoop = function(event) mte.update() end mapObj:addEventListener( "touch", mapObj ) Runtime:addEventListener("enterFrame", gameLoop)
I want to drag the map is no longer black like the picture attached.
Look forward to receiving your help
sorry for my bad english
Wow!! Great work, dyson!
Speechless… Feeling spoiled!!! Thank you very much.