Million Tile Engine Beta Release

Million Tile Engine
#681

I’m aware of the problem. It’s less a bug than an expected result of the ray-casting routines used to test for tiles. Tiles presenting very narrow aspects toward a light source can fall between two rays and thus not be counted by the lighting system. I’m planning to introduce a bias towards the number of diagonal rays to counter this, as well as a few other nifty techniques.

One thing you can try right now is to increase the angular resolution of the lighting system. You do this by changing mte.lightingData.resolution to something other than 1. A value of 2.1 works pretty well to eliminate some of what you’re seeing. The impact of this is that 2.1 times the number of rays will require 2.1 times the performance to process.

#682

When do you think the performance enhancements and flexibility improvements will be complete? We have a game written against MTE which is in need of a lot of optimisation due to the amount of moving sprites. We really want to offload the sprite movement to corona native transitions but can’t do that with current version of mte.

#683

I plan to have the entire engine rewrite finished by sometime in January, but I’m expecting to release incremental changes whenever possible. I’m not yet certain whether I can do this piecemeal or whether a stable release will require the completion of the whole thing. I’ll have a better idea of the timeline after I finish up the lighting and begin work on the rewrite.

I have been doing some transition experiments on my end with MTE’s current release. How many moving sprites are you dealing with?

#684

I figure a status update is probably in order! I have been quiet over the past two weeks only because I have had nothing specific to report or show off, but I have indeed been hard at work on the rewrite.

The new culling algorithm is finally coming together, and quiet nicely too. The new algorithm responds immediately to changes in scale and rotation as applied to the masterGroup; you can change the xScale and yScale and rotation on a frame by frame basis and let the engine cull and render new tiles as necessary to fill the screen.

The library will now support multiple instances of MTE’s engine. For example you could create mte1instance and mte2instance( or 3 or 4 or 5, limited by memory and performance, named whatever you like), load different maps into each of them, move each instance’s camera independently of the others, and so on. 

#685

Hi Dyson - can you refresh my memory re adhoc images with MTE.  What I’d really like is for Tiled to support adding adhoc images (not tiles) to the image layer, position them where you want/scale etc, and then for MTE to pick up the details and place these.  Not sure that Tiled is up to this yet however.  I see there’s a “Level Director” product but it’s on windows, which looks like it might be basically Tiled with added features for image placement too…wondering if you’ve looked into this?

#686

Last time I looked at LD it was basically just a raw level formatting tool. There was very little resembling a tile engine and it had no ability to load/unload contents from memory, meaning the size of levels you can build is limited by device power and memory. Cool if you want WYSIWYG level construction, but nothing approaching Tiled for structure.

#687

oh ok - so ultimately would be good if Tiled could just get upgraded to best support image flexible adhoc image placement 

#688

Tiled has some rudimentary support for precisely positioning images, but it could be better.

Tiled allows per-pixel placement of tiles on a map’s Object Layer. You can add a levelWidth and levelHeight property to the object in Tiled to override its display size in MTE. You could load the images you want as individual “tilesets”, each containing a single tile, to be placed in this manner. This is a sort of roundabout way of doing things though, and MTE 0v956 does not cull Tiled Objects (though this will be available in the rewrite).

#689

hey dyson, 

I have about 20 sprites moving onscreen with about 200-250 sprites within the level, (most movement is  not processed until the game window move close enough to the relevant sprite).

I will however need much more flexibility when it comes to later iterations of the game code due to the game AI and movement pattern requirements.

Best,

Steven

#690

We will def need this update before releasing our game with MTE. So will advise client to wait until then before we do a proper optimisation pass over the code.

If its not ready, or client can’t wait, we may have to write a lightweight tile engine in house. :S

#691

I certainly hope it doesn’t come to that! An MTE update focused on finishing up lighting support is coming tomorrow. After that I will begin work on the rewrite and have a better idea of a timeline.

#692

How is everyone’s experiences of MTE with graphics 2.0?  

We use MTE in the game we are currently developing, and since switching to graphics2.0 we’ve noticed that the frame rate has dropped dramatically (approx 1/2 of what it was before).

I’m not saying that MTE is necessarily the cause but I wondered Dyson122, whether you have found any need to optimise for g2.0 in your own tests?

#693

Hell Alan,

My tests in CastleDemo 0v956 show no performance difference between g1.0 and g2.0. What MTE features are you using and what device are you testing on? I would also double check the config.lua’s fps parameter, just in case.

#694

MTE v0.956 - http://gum.co/staO
 
Continuing a now well-established cycle of releasing a feature and then expanding upon it, MTE 0.956 expands upon the lighting system introduced in version 0.943 and brings various user-requested features and fixes to the table as well!

The new sprite method addLightingListener(lightID, listener) allows a much greater level of interaction between sprite objects. Check out the MTE Sprite Properties documentation to read more, and definitely have a look at the newly revamped Lighting 0v956 sample project to see it in action.

I’ve implemented several other features based on community feedback:

  1. The lighting algorithms have been reworked. Light is cast more smoothly, with less likelihood of anomalous unlit tiles appearing when a light source is close to a wall.

  2. The sortSprite parameter of a sprite’s setup table controls whether MTE implements its sprite depth buffer. The new sortSpriteOnce parameter will instruct MTE to sort the sprite a single time and then set sortSprite to false. Setting sortSprite to true will trigger another single sorting operation.

  3. The new saveMap() function allows developers to easily save an altered map to a file as encoded json data. MTE can open these modified files without modification, provided the file’s extension is “.json”.

  4. A new Tiled reserved property is available: noDraw. If a tile’s noDraw property is set to true, the tile is not rendered. If a layer’s noDraw property is set to true, no tiles on that layer are rendered. If a tileset’s noDraw property is set to true, none of the tiles from that set are rendered.

  5. The goto() function is now setCamera(). The latest beta versions of Lua use goto as a reserved word; this change is necessary to avoid a possible future conflict. The old goto() call is still available in this build, but I recommend switching over to setCamera()

The release by Corona Labs of their Graphics 2.0 public build came sooner than I thought it would, but I managed to squeeze in some compatibility tweaks at the last minute. MTE 0.956 is nominally compatible with the new graphics system, but I recommend sticking with the previous Corona build for now.

Moving forward from here, I will begin work on a major engine overhaul next week. The new MTE code will be more efficient, lighter, easier to use, and built from the ground up to make use of Corona Labs’ new graphics API.

As usual I will have an eye out for bug reports and feature requests here on the forums.

Enjoy!

#695

Dyson - do you have a video that gives an overview of all features in MTE by chance…  

#696

I’m afraid not, greg. I will be coming up with much more thorough documentation for the version 1.0 release, but that won’t be until after this crucial engine overhaul is finished. I would solicit others to come up with such videos, but many of the MTE function calls will be changing, so now probably isn’t the time for it anyway.

I’m always here to help if you need it, though.

#697

just haven’t keep up really  :)  but seeing all the good stuff coming out - I’m using my own basic tiled approach for which the code is a bit of a mess & is just enough to do the simple things I want, so keen to keep across MTE.  From memory the initial reason I didn’t port across to MTE was I wanted the ability to keep my own display groups and physics objects as is and not have to have to move to doing physics functions & moving objects using MTE’s functions…

#698

Ah yes, you are not the first to voice that concern! The upcoming engine rewrite will address those issues. The new code will have a more hands-off approach to sprites and other display objects. AddSprite(), moveSpriteTo(), etc will become a thing of the past. You’ll be free to use all of Corona’s standard methods for creating and manipulating display objects; changing raw x/y coordinates, translating, using transitions, all that jazz. Adding a sprite to MTE will be as simple as adding the sprite to a parent group, just as you would in another project.

#699

cool - hey any comments re whether Graphic 2.0 could take the place of a tiled based approach for physics games (e.g. horizontal scroller) for which a level may be many screens wide? So currently one can use the approach of limited set of “tiles” (images) that are created/destroyed by a tile engine as the player moves through the world.

For example, could you just create as many shapes as you want/where ever you want with Graphics 2.0 and just use the “fill” with pattern approach (i.e. no need for images)? I’m assume you would still have a memory issue with having a large number of such objects (with physics bodies) anyway, and would still probably need a tiled engine type approach?

#700

The pattern fill repeats a single image over and over again inside of a shape object. In theory you could create something which visually resembles tiles, but you surrender a great deal of control and flexibility in the process. As you say, you will run into performance and memory constraints as you create more of the objects. On the other hand, you probably could come up with a level several screens wide using a relatively small amount of display objects, if you were alright with different level components being made of monolithic blocks of identical “tiles”. I suppose you could add a little variety by applying different composite fill effects to your large shape objects.

I do like the idea of pattern fills, but I would tend to use them in complimentary fashion within a tile map.