Million Tile Engine Beta Release

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

 

Another three weeks, another new update! MTE 0.8 focused on platforming and sidescrolling mechanics. MTE 0.820 returns to it’s RPG roots, bringing a number of useful new features:

 

Camera Constraints: define areas within which the camera and view must remain. Subdivide maps into distinct areas, break up rooms inside of a building, or just lock the camera to the map. This new feature will add new flexibility to RPG projects.

 

Tile Flip and Rotation: the Tiled map editor allows you to flip and rotate tiles before placing them in the map, and MTE now supports this functionality! It is no longer necessary to duplicate the same tile image facing four different directions in your tilesets. Just use one and rotate as needed!

 

A New Sample Project: RotateConstrainStoryboard. The sample lives up to its namesake by demonstrating tile rotation, camera constraints, and storyboard integration all in the same project. Tile rotation allowed for the use of an incredibly tiny tileset: just 2 x 3 tiles, only 5 of which were used! I’ve set up camera constraints to create the impression of distinct rooms inside of a building. The camera locks to one room at a time before moving to the next when the player hits a Tiled Object trigger. Storyboard integration takes the hassle out of switching from one map to another and another.

 

With this update out of the way I’ll be moving on to one of the two huge new features coming to the Million Tile Engine: Isometric maps. I expect this feature to take between one and two months to implement, at which point MTE will reach version 0.9 and I’ll move on to the final major update in the pipeline: physics integration.

 

http://gum.co/staO

Congratulations on the new version. Can’t wait to get my hands on your amazing work. Thanks much for all your efforts.

I’ve added flipped and rotated tiles to the list of features I would like to add. I’m talking about tiles which have been flipped or rotated from within Tiled itself and stored that way in the tile map. It’ll be some time before I get around to working on these.

Work continues on map constraints. Implementing them has proven more difficult than I thought, so the update will probably land sometime next week instead of this one. It seems two weeks always become three for me. In the future I’ll probably stick with a minimum of three weeks between updates.

EDIT: This post contains experimental features which are not a part of MTE.

I’ll be spending this week experimenting to see just how far I might be able to push isometric projection. That and starting to lay the groundwork for more traditional iso maps.

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

I’m dizzy!  :slight_smile:  That was amazing!!! Great work. 

Whoa! Just whoa!

We just bought MTE for use in one of our games. It looked excellent and much more efficient than writing our own. Unfortunately we’ve discovered it doesn’t support flipping or rotation of tiles which means we need to duplicated rotated or flipped tiles in the tile set itself.

We’ve been told it’s coming but it may be several weeks away. Just wanted to let people know in case it affects them as we couldn’t find reference to it being included/excluded until it was too late.

Seems great other than that :-).

Dyson, please let us know when you have more info. Thanks!

Looking good.

I have a quick question about the flipped and rotated tiles. It seems that if a tile is flipped AND rotated MTE isn’t sure what to do with it. Most of my tiles appear as they should, but a few of them are orientated incorrectly.

Have we done something wrong or is this a known problem?

Good catch; I’ve added flipped and rotated tiles to the list of limitations in the OP.

This is something we definitely need. If you’re planning on adding it in the next few weeks then we’re happy to wait patiently. If not then we need to look at other engines or do it ourselves. Please just let us know and thanks for the speedy response.

Hi, I am not sure this is related to the topic here, let’s see

I am using a tile as a background as follows

[lua]

    for i=1, 500 do

        local img=display.newImageRect( backgroundGroup, “assets/images/menuTypeBackground.png”, 320, 2 )

        img:setReferencePoint(display.TopLeftReferencePoint)

        img.x=0

        img.y=i*2

    end

[/lua]

The problem is that it takes a lot of time to generate it.

May this Tile Engine help in achieving that more efficiently?

Thanks, and great work. Looks promising

I looked into it. I’m happy to say that tile rotation will be included in the next update. This was made possible by the excellent BinDecHex lua library by Time Kelly of Dialectronics. You can see it here: http://www.dialectronics.com/Lua/

Future releases of MTE will include BinDecHex, unmodified, as a seperate lua file alongside MTE. I believe this is legal to do, but if I’m wrong someone please let me know so we can work the problem out. 

Tile rotation must be enabled before the map loads. This is done by calling mte.enableTileRotation(true). The performance impact is limited to map loading and will depend on how heavily you use rotated tiles. The in-game performance, so to speak, should be unaffected by the presence of rotated tiles, however the memory load will be increased by some degree again depending on how heavily you use rotated tiles.

Tile flips are impossible. The Corona SDK graphics API does not support image flips, only rotation. Corona Labs’ Graphics 2.0 release will probably fix this in the coming months, but it is out of my control.

Tile rotation AND flipping is coming in the next update! Thanks nick_sherman and richard9 (below) for clueing me in!

@AlanPlantPot; Thanks for bringing that to my attention. It seems I left out a few of the flip/rotate commands. I’ll have a new update out to address the problem by the end of the day.

@igenapps; I don’t think so igenapps. Loading 500 individual images will take a certain length of time whether you do it or MTE does it for you. I think you should look at using an imageSheet. Instead of 500 image loads there would be only one, and your loop would merely be loading frames from the imageSheet instead of individual image files. This might speed things up for you.

This might not be what you mean but can’t you flip display objects by giving them a negative scale value?

Yeah, dyson122, I believe negative scale flipping is specifically mentioned in the object:scale API doc.  :) Take a look.

Thanks guys! Just goes to show I don’t know everything :stuck_out_tongue:

Tile rotation AND flipping is coming in the next update, which should land by the end of next week. I have to be honest, setting up camera constraints proved far more troublesome than I thought it would, but at this point I have the algorithm down and it’s just a matter of implementing it where it needs to be, followed by some days of testing the movement functions for new errors.

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

Fixes a problem with the detection of tiles which have been both flipped and rotated. Update emails have gone out to all current customers.

@dyson122

Thanks for your help, but I don’t really understand the difference. I thought when an image had been loaded once, it was kept in memory so reusing it should not require the time to load it again. What you suggest is something like:

[lua]

for i=1, 500 do

        local img=display.newImage( imageSheet, frameIndex )

        img:setReferencePoint(display.TopLeftReferencePoint)

        img.x=0

        img.y=i*2

end

[/lua]

I actually tried it and it seems to be a lot faster, but I would like to understand the reason.

Thanks!

Excellent news. Looks like MTE will be out of beta in a jiffy! Good work.

I don’t know exactly what is causing the speed difference you’re seeing, but when you think about it, a frameIndex is a number while a filename is a string. In order to load a frame from an imageSheet, Corona need only process numbers, which is easy. In order to load a cached image Corona must compare the filename you gave it to the filename of the image, and comparing strings is much more expensive. There are probably other contributing reasons, but none come to mind.