Million Tile Engine Beta Release

[maxisto]

@dyson122

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]

[dyson122]

Maps 2 and 3 of the Isometric Sample Project are more or less finished. What remains to be done is the implementation of remaining features related to Isometric support. What it amounts to is a whole lot of little things, going through each function and checking for compatibility with the new maps, getting physics support to play nice with the isometric view… a few other things. 

A notable new addition is that moveSpriteTo and moveCameraTo now have onComplete event listener parameters, useful for applying some effect to a sprite after it has finished moving. In the case of the sample project it is used to move the player sprite up or down a level in response to changes in terrain elevation.

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

[dyson122]

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!

[maxisto]

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 )

[dyson122]

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.

[maxisto]

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…

[Abiz]

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?

[dyson122]

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?

[dyson122]

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.

[maxisto]

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.

[Abiz]

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

[dyson122]

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?

[ojnab]

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

[dyson122]

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.

[dyson122]

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.

[ojnab]

Hi Michael

Great! Yes I think it is pretty straight forward to implement it.

Been looking at your code to see if I could implement it myself,

but it will probably be better if you do it, since you know your code much better than I do.

Thanks.

[greg886]

Michael/all

How does MTE/Corona perform in terms of the various versions of iPhones? Just wondering for example is it a given that a complex game with MTE, physics etc, with Corona might need and iphone 5+ to be snappy?

Any tried a complex physics / MTE game on an iphone 4? An iphone 3s?

Ultimately wondering if a game is sluggish on an iphone 4 is sluggish, is this kind of normal or not. Eg if not is this a sign you need to do some more optimization your code?

[dyson122]

MTE loaded a map directly from a .tmx file for the first time today! The coming update will support both Tmx map files and their corrosponding Tsx tileset data files.

What this means, is that folks don’t necessarily have to worry about exporting their maps to Json files anymore, nor setting up the same properties on the same tileset used across several different maps. Reading the XML data from these files currently takes about 3 times as long on the first load, but it is as yet unoptimized, and of course preloaded maps will load as quickly from memory as they would in any case.

The new MTE update will be available next Friday (Sep 20)!

[dyson122]

Just as an FYI to everyone, I know a lot of you do your programming work on the weekends, but for me it is the opposite. I work on MTE during the week, and I’m usually unavailable on the weekends. Now that I’m back to work I’ll start working through the backlog of emails and questions I’ve received since Friday. I don’t mind getting questions and emails on the weekend at all, just be aware that I may not get to them until the start of the following week.

[dyson122]

Sorry for the delay, greg886.

Unfortunately my iPhone3GS has refused to install new apps as of late, but I did do some tests with my iPhone4 and Platformer - Angled PHYSICS 0v918, which has a few dozen physics objects and potential for some quick movement if you get the player up to speed. What I found is that the iPhone 4 is beginning to show its age. If you increase blockScale to 80 from 72 (thereby decreasing the number of onscreen tiles) and set the default fps to 30, it will just about hold this speed. Then again, the iPhone 4 is the last of Apple’s single-core phones.

Simple maps with no physics will of course work smoothly across all devices, but I think it’s safe to say you’ll want to target the iPhone 4S as the minimum if your thinking of doing something complex with a lot of physics.