Million Tile Engine Beta Release

Oh, sorry, I didn’t see those!

  1. You can move the camera around the map with the functions moveCameraTo(parameters) and moveCamera(deltaX, deltaY). 

  2. You can prevent the camera from leaving the map with constrainCameraToScreen(parameters), or you can define your own constraints using constrainCamera(parameters).

You really should read the API documentation! You can find the details and specifics of these functions there. Of particular usefulness are “MTE API 0v910 HTML.htm,” defines all the MTE function calls, and “MTE Reserved Tiled Properties 0v910 HTML.htm,” which describes the properties you can set in Tiled to define such things as an object’s physics characteristics. Both open in your web browser and have convenient indexes at the top.

Well thanks! (and you didn’t see my update^^)
I just found recently the API, it’s very helpful, but thanks again for mentioning it.

But I have a small problem to make the slide function:

I’m looking for a hint how to get a startX and startY(after map load).

I want for example the TilePosition at CenterX and CenterY of the current screen, but somehow I can’t figure out to get these positions.

local startX = 0 local startY = 0 local moveit = function(event) currentX = event.x currentY = event.y mte.moveCameraTo({locX = currentX/scaleFactor, locY = currentY/scaleFactor, time = 5000}) --mte.moveCamera((startX - currentX) / scaleFactor, (startY - currentY) / scaleFactor) startX = currentX startY = currentY mte.update() end Runtime:addEventListener("touch", moveit)

I’ve made this, and none of those moveCamera orders work smooth like the mentioned function in Lime.

If I use easing, Corona crashes.

I would be glad if you could help me out with this last thing. Then I shouldn’t have questions for a long time :).

By the way:

Please mention at the Camera API mte.update(), I wondered why nothing didn’t work :D…

I downloaded the latest version of MTE, and figured I want to try using .TMX maps, I had a look at the sample project for .TMX maps and it seemed to me that the only difference was adding a “.tmx” when loading maps, but when I did that I got an error.

mte.lua:7393: attempt to index field n '?' (a nil value)

if I remove the “.tmx” from loadMap the project runs fine (after I export to .json), am I missing an extra step in using .TMX maps?

Maxisto: You can get the current camera position and location using getCamera(layer). The function returns a table containing the level position and location of the camera.

For exmaple: 

local camera = mte.getCamera(1) print(camera.levelPosX, camera.levelPosY, camera.locX, camera.locY)

You can convert a screen coordinate to a level coordinate using mte.convert(operation, arg1, arg2, layer). For example:

local touchPosition = mte.convert("screenPosToLevelPos", event.x, event.y, 1) print(touchPosition.x, touchPosition.y) 

You can read about the different operation options for convert in the API documentation.

Good catch about met.update in the documentation! I’ll make sure to add a reference. Something else to keep in mind is that mte.update() should be called once every frame. The easiest way to do this is to put it in your game’s enterFrame event. Calling mte.update() in a touch event can cause strange behavior and/or crashes.

Abiz: It looks like the tmx parser isn’t finding any tile data on one of your tile layers. I think I see the problem. Does one of your layers not have any layer properties? The parser expects tile data to be stored beneath layer properties. I’ll remove this limitation on my end for the next patch, but in the meantime could you add at least one layer property to your layers and test your TMX map again?

I’ll be releasing a new patch this friday adding/fixing the following:

  • constrainCamera, constrainCameraToScreen: fix to prevent the camera from revealling black bars on the edges of a map when letterBox scaling is used.
  • addSprite: new optional constrainToMap parameter (boolean) specifying whether a sprite is allowed to move out of the map when worldWrap is disabled.
  • moveSpriteTo, moveSprite: new optional constrainToMap parameter (boolean), overrides the sprite’s constrainToMap parameter.
  • goto: new overDraw parameter (number of pixels) used to set a slight scale increase on tiles to help hide the edge artifacts of non-extruded tilesets. 
  • setParentGroup: new function for specifying a user-defined group object to be the parent of MTE’s layer groups, sprites, and objects.
  • goto: new parentGroup parameter.
  • Improvements to the TMX parser.
  • Improvements to Isometric Physics support.

Hi there,

it’s very amazing, that you’ve made that fast a new update.

Especially the improved goto sounds good to me :lol: I want to check it out then.

And thank you very much for your help, especially mentioning the converting operation.

Thanks to you, I’ve made up this slide function similar to lime, even better!

It works very good and is smooth, especially you did well creating these easings.

So I want to share it with the other guys:

local gameLoop = function(event) mte.update() end local slide = function(event) --easings: inExpo, inQuad, outExpo, outQuad, inOutExpo,inOutQuad, linear. local touchPosition = mte.convert("screenPosToLevelPos", event.x, event.y, 1) mte.moveCameraTo({levelPosX = touchPosition.x, levelPosY = touchPosition.y, time = 500, easing ="inQuad"}) end Runtime:addEventListener("enterFrame", gameLoop) Runtime:addEventListener("touch", slide)

Okay, then in short words one question and a few suggestions (+for the API:)

Now I can start to work and I have one last question after reading your API.

I’ve read that you can change the RGB color of a layer, right?

Is it possible with your current version to change the RGB color of a

single tile? For example I want to turn everything I click to black/blue

whatever. Is there a function? I mean that you don’t have to change the tile, just tilt it.

moveCamera(deltaX, deltaY) maybe add time like in mte.moveCameraTo

API: moveCameraTo(parameters)

levelPosX: “The Y level position to which the camera should move if sprite is not
specified” -> Well it works without thinking about sprite, maybe you should add

Example 3: mte.moveCameraTo({levelPosX = 200, levelPosY = 50 time = 50, easing =“linear”}),

cause I didn’t know whether locX was just a simple name or the really required name of the system.

Hope you know what I mean.

I have added a layer property to each layers in my TMX map, and I think it loaded successfully, but there is another problem that comes when i use the goto function.

mte.lua:3735: attempt to compare number with nil

Are you afraid of the dark?

p7f7.png

Excellent Dyson!  This is what I was looking for in http://forums.coronalabs.com/topic/40220-lighting-and-mte/.  Will this tutorial/code and change be available in the next release.

Noral

Yes, that is the plan!

There is still some work to do. The above is static lighting calculated when the map loads. The system will also support dynamic (moving) light sources. All pertinent variables are RGB tables, allowing for lights of any color and allowing tiles to absorb only the colors you want. So, for example, you could make vine tiles absorb mostly red and blue light, allowing only green light to pass through. By setting the falloff table to your liking, you could have certain light sources cast reddish light further than blue and green light. Stuff like that.

Just bought MTE, looks nice :slight_smile: No documentation makes learning difficult though… Is this the right thread to post questions about MTE usage? If so, then question #1: what would I use Tiled image layer for? For background you recommend putting the image into sprite, yes?

Thanks for pointing out these Documentation problems, maxisto! I’m going to go through the API tomorrow and clean it up some.

You can tint a tile using tintTile(locX, locY, layer, color, time, easing). You can also retrieve the tile object with getTileObj(locX, locY, layer) and use Corona’s standard API call to change it’s color as well, if you’d like. 

Abiz, would you mind uploading your TMX file, TSX files (if any), and tileset images and either emailing them to me or posting them here?

Hello arman7,

For future reference, the documentation can be found in the root directory of the MTE zip file you downloaded. There are five files:

  • MTE API 0v927 HTML.html - Lists and defines all the function calls for controlling MTE.
  • MTE Reserved Tiled Properties 0v927 HTML.htm - Lists and defines the reserved Tiled properties used by MTE.
  • MTE Sprite Object Properties and Methods - Lists and defines the parameters MTE adds to sprite’s displayObject when it is added to a map at runtime.
  • MTE Tile Object Properties and Methods - Lists and defines the parameters MTE adds to a tile’s displayObject when it is spawned by MTE’s map culler.
  • MTE Tilesets, Map Structure, Getting Started - A short and, admittedly lacking tutorial on creating a basic tileset, map, and loading MTE.

The API and Reserved Tiled Properties docs are kept up-to-date, but I agree that the rest definitely needs some love.

How you implement a background will depend on how you want your background to behave. If the background is a static, unmoving image you can simply use Corona’s newImageRect call for adding images, and place it behind MTE’s parent group. If the background is expected to move, and it is made up of tiles, it is easiest to just add it to the map as you would any other tile layer, in Tiled. Loading the background as one big sprite can be useful on certain lower-performance devices because MTE does not have to load in and remove background tiles as the level scrolls. This is most useful on worlds which don’t wrap, because a sprite background will not wrap. 

Tiled image layers instruct MTE to create a sprite for you. They are functionally the same as you adding the background as a sprite yourself.

Hello 

Been playing around with MTE and I’m impressed.

I don’t know if anyone already requested this but here goes:

I would really like to be able to load physics shapes created in physics editor ( the one from code’n web ) into MTE.

Then we could easily create advanced physics shapes for tiles and apply them by typing in a physics shape

id in the tile-properties in tiled. 

What do you think? Thanks

Good idea, ojnab! I wasn’t aware of PhysicsEditor until now, but there shouldn’t be any major roadblocks to supporting it. I’ll look into it.

MTE v0.918 - http://gum.co/staO

MTE v0.918 is an incremental update of the features in MTE v0.910.

The isoOverDraw parameter of goto() has become the overDraw parameter, and it now works on both Isometric and Orthographic maps. The purpose of overDraw is to help hide the edge artifacts inherent in non-extruded tilesets. OverDraw slightly increases the size of the tiles without altering the blockScale of the map. The result is that the tiles overlap slightly and cover the edges where artifacts occur. An overDraw of as little as 0.5 can help alleviate edge artifacts, but extruding your tiles in a program like TexturePacker is still the best solution.

This update corrects a bug in constrainCamera and constrainCameraToScreen which could allow black space to come onscreen when letterBox scaling is used in an app. The camera will now stay fully within the bounds you set, provided the bounded area is large enough to fill the screen.

The new constrainToMap parameter of addSprite allows you to specify whether it is okay for a sprite to leave the map area when worldWrap is disabled. For example, sending a sprite to a location of (-2, -2) would ordinarily move the sprite to location (1,1) and stop, because (1,1) is the nearest valid map location to (-2, -2). If constrainToMap is set to false, the sprite will move out of the map to (-2, -2). 

moveSpriteTo() also has a constrainToMap parameter. If it is set, it will override the constrainToMap parameter of the sprite for the duration of the move operation. This is more useful when you’d like to selectively prevent a sprite from leaving the map, rather than selectively allow a sprite to leave the map. A sprite whose constrainToMap parameter is set to true will eventually snap back into the map if moved out of it.

You can now provide your own group object to be MTE’s parent group by setting the parentGroup parameter of goto(), or by calling setParentGroup(group) at any time.

The TMX parser has been updated to be more flexible and less likely to throw errors when reading maps.

player.light = {source = {255, 255, 255}, range = {10, 10, 10}, falloff = {25, 25, 25}}

[media]http://www.youtube.com/watch?v=LZzILs7i8y0[/media]

It’s coming together now. There are some optimizations left to do, and a lot of little things to handle sprite’s changing scenes, automatic dynamic source creation on Tiled objects, etc.

Nice work! :slight_smile:

Really awesome Dyson, good work!

very cool indeed!

would it be particularly complicated to multiply simple masks through this setup for even further effects? 

lets say for a simple shape that followed sprites to define the look even further, or a custom shape around a light source in the scene?