That is what we do 
We also have logic in place where the player and camera move at different velocities and constrained differently when level constraints are hit.
Having the camera *catch up* to the player allows for smoother experience. For example you do not want the camera moving quickly when the player is making a difficult jump while running.
Excellent that sounds great - Thank you both again for all of your help - it helped me tremendously!
MTE v0.943 - http://gum.co/staO
Way back at version 0.7 MTE was just a simple tile engine, very fast yet limited to perfectly square tiles and not all that much else. We’ve since seen the addition of Physics, Isometric Maps, a multitude of new functions and capabilities, numerous performance improvements, hundreds of diligently crushed software bugs, and nine new sample projects. We’ve come a long way!
I have no intention of stopping there. Version 0.943 adds something hinted at and touted throughout the development of MTE; a lighting system. Sure, you could tint each layer to simulate some basic lighting effects before, but now you can create point light sources! Tiles and sprites can be set to emit light of any color, tiles can block light, absorb light, let some light pass through, or all of it! Walls can cast shadows! Developers can rob the players of their miraculous ability to see around corners!
The stars of the show in 0.943 are the numerous new tile and object properties for use in Tiled. Properties determine the strength of a light source; the range of the light; whether a full circle is cast or only an arc, or a list of individual light rays; how quickly that light diminishes with distance; and more. Objects and Tiles share most of these properties. Definitely have a look at the updated MTE Reserved Tiled Properties documentation to get the lay of this new land.
What would this update be without a cool new sample project demonstrating the lighting system? Check out Lighting 0v943 to see the system in action. Move with the Dpad, touch the player sprite to toggle his dynamic light on and off. Did I mention dynamic lights? The static tile lighting is all well and good, but moving light sources really open the door to fun gameplay mechanic possibilities.
Aside from lighting, 0.943 incorporates a few user-requested additions and changes:
The constrainToMap parameter of a sprite’s setup table now takes a table instead of a boolean. The table has the format of {left, top, right, bottom} and specifies whether the sprite’s movements are constrained at each edge of the map.
Tile display objects now have a property named ‘property’ which contains the table of all the tile’s properties as defined in Tiled. Easily retrieve the tile’s Tiled properties in your collision events!
The new engine incorporates a suggested fix for loading tilesets with spacing.
Various minor performance improvements to the engine tasks of loading tiles and loading the map.
Following the pattern established with the introduction of Physics and Isometric Maps, this is only part 1 of the lighting update. There is more to come in the near future. Coming soon are lighting events triggered when a sprite or tile is first exposed to light, while it is still exposed to light, and when a given light stops landing on it. I’m investigating the possibilities of sprites casting shadows and of smoothing out the edges of shadows cast by map tiles. Of course, there will be performance improvements and optimizations.
After lighting I’ll be working on fundamental improvements to the core functions of the Million Tile Engine allowing for far greater flexibility in controlling sprites and maps, loading multiple maps, stitching maps together, adding maps TO maps AS sprites, allowing physics collisions anywhere on culled maps instead of just onscreen, and, again-and-as-always, performance improvements. In addition to updated documentation and tutorials, this will bring us right up to the 1.0 Release of the Million Tile Engine.
What comes after 1.0? You’ll just have to wait and see!
As usual I will have an eye out for bug reports and feature requests here on the forums.
Wow!!! Congratulations. Thank you very much for your continued hard work. Can’t wait to see 1.0 and beyond!!!
dyson122, I’ve installed lighting example from this new version. I see there’s a small bug with lighting.
https://drive.google.com/file/d/0B0hTcBlT0TZuVTVDT0dSaUlCN1E/edit?usp=sharing
I mean the 2 tiles that have 2 coordinates (-3,1) and (3,1) from the character position that are darker than (-4,1) and (4,1).
This is consistent bug so you’ll likely find it easy.
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.
This friday I’ll be releasing yet another update allowing base64(uncompressed) and csv layer encoding in TMX files, PhysicsEditor support, and a function for automatically ordering sprites based on Y position ala Double Dragon and similar fighting games!
Next week and probably the week after it I’ll be working on MTE’s new lighting system.
Nice you already did the physicsEditor support. Thanks. Looking forward to try it.
Also looking forward to see what the new graphics engine can do for MTE.
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.
MTE v0.927 - http://gum.co/staO
MTE v0.927 adds user-requested functionality and improvements.
MTE can now load TMX files with CSV and Base64(uncompressed) encoding. I’ve reworked the XML parser to significantly improve loading times, but the best current option for encoding is CSV. CSV encoded files are very small and can load nearly as quickly as Json exports.
Preliminary PhysicsEditor support is in place. PhysicsEditor is an amazingly-useful tool for automatically generating shapes for complicated objects and setting up their physics properties. You can direct MTE to the PhysicsEditor output file by setting a tileset’s physicsSource property in Tiled. You can load a physics shape into a tile by setting it’s shapeID property. It is also possible to give an arbitrary tile both physicsSource and shapeID properties to load shapes from different output files in the same tileset. The Platformer - Angled PHYSICS sample project has a new map, AngledPhysics4, demonstrating this new functionality.
You can now sort sprites in a given spriteLayer by their Y position on the map. Activate the feature by setting mte.enableSpriteSorting = true. Set sortSprite = true in a sprite’s setup table to add it to the depth buffer. Sprites closer to the top of the map will be further behind sprites closer to the bottom of the map. This is useful for when “tall” RPG style sprites are used, or in games with a forced 3D perspective ala Double Dragon and other side scrolling fighters.
Aside from these new features I’ve made a few changes and corrections.
-The lighting parameter of a sprite’s setup table now takes a boolean instead of the string “off”.
-The function loadTileSet() will now immediately throw a warning if the source file you specified does not exist (in the form of a path-to-file not found message), instead of allowing you to specify a nonexistent file.
-I’ve updated CastleDemo with some user-suggested improvements and modifications. The sample also now includes the code necessary for touch scrolling and pinch zooming on multitouch devices in a commented-out section. The old four-button Dpad is now a single displayObject.
I’ll have an eye out for bug reports and user requests.
I hope you’ve enjoyed the updates to MTE thus far! I have some fun new functionality in the works, as always… 
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?
Are you afraid of the dark?
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.
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
Just bought MTE, looks nice 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?
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:
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.
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!