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
Really awesome Dyson, good work!
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.
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?
This is one of those features with the potential to bloom into many additional features. The more I think of it, the more potential I see. For example, with the way the lighting system works, each sprite is aware of the lights shining on it- and the sources of those lights. You can do so much with that information! This is easily folded into a line-of-sight detection feature.
Lights don’t have to be 360 degrees. You can define light arches, or you can specify individual rays to be cast out in a specific direction. Again, a ray cast by an object contains that object’s ID, and so anything illuminated by that ray knows precisely what cast it.
I hadn’t even thought of using masks, but that should be simple enough as well. A mask at least would be relatively inexpensive to add to the lighting stack. In fact a mask might be used in place of a dynamic light source when reacting to the map is not needed.
It has huge potential!
Out of interest, how flexible are the graphics 2.0 features when integrated with MTE? Have you had a chance to see what is possible?
I am particularly interested in the normal mapping feature, but slightly apprehensive it may not offer what I hope. I am a compositor by trade and I use 2d normal re-lighting fx all the time, it is an incredibly powerful tool, but as I am not yet a pro user I haven’t had access to the feature in corona yet to test out the limitations and flexibility.
This idea came to mind when looking at your latest lighting examples. To be able to reference a normal map version of the tilesets for relighting purposes, would be an incredible addition.
Here is an example of what I mean, a 2d sprite image re-lit with normal map effect: http://www.mattgreer.org/media/lightingShadows/pixel_shading.gif
I have been doing a few experiments with G2.0, but not with MTE itself due to the potential time demands of converting the engine to the new API- I’ve been busy working on MTE’s features. Initial tests suggest that a certain G2.0 feature may radically improve the performance of MTE’s tiling system, allowing for screens filled with many,many more tiles than possible now.
I’ll whip up a test of normal mapping and see how it applies to tile systems.
Dyson,
Thanks for a thorough answer, it belongs in an FAQ for MTE in my opinion.
Where do you want bug reports?
BUG:
Loading tilesets with spacing fails with an error like this: “mte.lua:6365: Incorrect number of frames (w,h) = (32,32) with border (1) in texture (w,h) = (256,256). Failed after frame 50 out of 56.”
FIX:
Change line 6344 to:
map.numFrames[index] = math.floor(map.tilesets[index].imagewidth / tempTileWidth) * math.floor(map.tilesets[index].imageheight / tempTileHeight)
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:
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.
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.
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”.
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.
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!
Dyson - do you have a video that gives an overview of all features in MTE by chance…
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.
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…
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.
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?
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.
Thanks arman7,
I’ll fold that fix into the next MTE release. It’s always nice to see people coming forward with solutions to bugs they encounter! You can post bug reports in this thread, particularly if you’ve already found a solution, but if you have open questions or need help with something it’d be best if you started a new thread. You can also PM me if you like. I’ll respond to emails as well, though I prefer to keep customer service here on the forum so others can benefit from answered questions.
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.
