Feature Requests

Million Tile Engine
#1

Hey dyson,

Happy new year! I hope the engine rewrite’s going well. I’ve spent some time over Christmas working on my MTE-powered apps and my new years resolution is to finally get one, if not more, published some time this year - obviously the sooner the better but at the very least in time for next Christmas(!)

I have a feature request, below, which could be the first of many. Hope you can help.

Many thanks!

= = = = = = = = = =

REQUEST:

Would it be possible to add an “onComplete” parameter to moveCameraTo() function, as is available with moveSpriteTo()?

Example

onComplete: (listener) Creates a temporary event listener for the camera. The listener is triggered when the camera’s current movement is complete, and then removed.
 

#2

That’s great news about your apps! I look forward to seeing what you come up with.

The engine rewrite is proceeding smoothly. The new algorithms are in place and now it’s a matter of re-enabling various features. I’ve moved on from tile lighting to physics and object drawing, and from there I’ll hit up isometric support. Also on the list is a feature for allowing physics objects to be active and interact with the map at any position on the map, onscreen or off; support for 1 normal map light active in the scene; completion of the perlin noise helper functions; and functions for manipulating the geometry of a map layer as seen in the most recent Height Map video. Some of these features make use of what Corona Labs calls “Premium Graphics”, which require a Corona Pro license.

That’s a good idea about having an onComplete listener for camera movement. I’ll add that in and release it in a minor update this week.

#3

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

With the new onComplete functionality, setting up simple camera oscillations is easy.

moveBack2 = function(event) print("done1", event.levelPosX, event.levelPosY, event.layer) mte.moveCameraTo({levelPosX = player.getLevelPosX() + 48, levelPosY = player.getLevelPosY() + 48, time = 1500, layer = event.layer, easing = "inOutQuad", onComplete = moveBack1}) end moveBack1 = function(event) print("done1", event.levelPosX, event.levelPosY, event.layer) mte.moveCameraTo({levelPosX = player.getLevelPosX() - 16, levelPosY = player.getLevelPosY() - 16, time = 1500, layer = event.layer, easing = "inOutQuad", onComplete = moveBack2}) end mte.moveCameraTo({levelPosX = player.getLevelPosX() + 48, levelPosY = player.getLevelPosY() + 48, time = 1000, layer = 1, onComplete = moveBack1}) timer.performWithDelay(50, function() return mte.moveCameraTo({levelPosX = player.getLevelPosX() + 48, levelPosY = player.getLevelPosY() + 48, time = 1000, layer = 2, onComplete = moveBack1}) end) timer.performWithDelay(100, function() return mte.moveCameraTo({levelPosX = player.getLevelPosX() + 48, levelPosY = player.getLevelPosY() + 48, time = 1000, layer = 3, onComplete = moveBack1}) end) timer.performWithDelay(150, function() return mte.moveCameraTo({levelPosX = player.getLevelPosX() + 48, levelPosY = player.getLevelPosY() + 48, time = 1000, layer = 4, onComplete = moveBack1}) end) timer.performWithDelay(200, function() return mte.moveCameraTo({levelPosX = player.getLevelPosX() + 48, levelPosY = player.getLevelPosY() + 48, time = 1000, layer = 5, onComplete = moveBack1}) end)
#4

Thanks dyson that’s great!

That’s an interesting demo. Now I think I know what sea sickness feels like. :wink:

Great news on the rewrite! Look forward to seeing what you come up with!

#5

Hey dyson,
 
The recent MTE update has been a great help - thanks! I have another feature request that I think will be useful to others, I know it will be to me, and I wondered what you thought. I note in your last update you said no new features will be added after the release candidate so I’m hoping it might be possile to squeeze this one in if it’s viable.
 
Until now I’ve been experimenting with MTE using simple sprites created with display.newSprite( imageSheet, sequenceData ) and everything has been great. However, my game now requires some more complex and optimised sprites, which are essentially a display group containing several sprites (I’ve added several custom methods to the display group to manipulate and animate the sprites within). It’s essentially a variation of the ideas presented in this Corona Labs tutorial: Dynamically-Optimized Sprites .
 
I experimented with this approach, using a display group containing several sprites, and encountered the following error:

stack traceback: &nbsp;&nbsp; &nbsp;?: in function \<?:218\> &nbsp;&nbsp; &nbsp;[C]: in function 'setFillColor' &nbsp;&nbsp; &nbsp;...uilds)\mygame\libs\mte\mte.lua:1513: in function 'addSprite' &nbsp;

 
Which raises 2 questions…

  • Would it be possible to allow such complex / optimised sprites to work with MTE? This would be a HUGE help to me and I’m sure to others.
  • Is there anything within MTE that would cause issue with the programatic tinting discussed in the above tutorial (see “Tinting” the Elements). I intend to use this method to randomly create a vast amount of visually different enemies using just a few simple greyscale assets. I’m thinking tintLayer / tintLevel / tintMap might conflict…?

And that raises a 3rd question I’ve just considered… how do you easily untint a layer / level / map? A possible scenario might be where you want a blue-ish room that eases to original colours once a light switch is flicked or perhaps a flickering light that quickly alternates between 2 or more colours (a broken overhead light, a neon sign, a disco, etc)
 
A few thoughts there and lots of potential. Look forward to hearing from you and thanks as always!

#6

Yes, this is all supported already, but not obviously so.

  1. You can add group objects to MTE just as you would any other sprite, you just have to change setup.kind from “sprite” to “line”. Line was an unusual label choice I admit; it’s changing to “group” and/or “vector” in the new rewrite. Essentially all this does is prevent MTE from calling unsupported functions on it, like setFillColor.

  2. Using groups as sprites has not been thoroughly tested. In theory any problem that may come up will be easily solvable. The engine doesn’t attempt to alter the contents of a group running as a sprite. On the plus side, it doesn’t apply layer lighting to the group’s contents. This allows unobstructed tinting of the individual elements. On the downside… it doesn’t apply layer lighting to the group’s contents. This prevents the sprite from automatically responding to layer lighting changes.

Easing the layer lighting is easy. Just call mte.tintLayer(layer, color, time, easing). Color is a table of the three color values. If you call the function with color and time set to nil, the function will return a boolean specifying whether a tint operation is in progress or not. Other available functions are tintTile(), tintLevel(), and tintMap(), which all work much the same way. The flickering might be a little trickier because tinting happens in mte.update, so turning the lights “on” immediately after turning them “off” may not produce a flicker if mte.update hasn’t executed the “off” yet.

#7

That’s great news about your apps! I look forward to seeing what you come up with.

The engine rewrite is proceeding smoothly. The new algorithms are in place and now it’s a matter of re-enabling various features. I’ve moved on from tile lighting to physics and object drawing, and from there I’ll hit up isometric support. Also on the list is a feature for allowing physics objects to be active and interact with the map at any position on the map, onscreen or off; support for 1 normal map light active in the scene; completion of the perlin noise helper functions; and functions for manipulating the geometry of a map layer as seen in the most recent Height Map video. Some of these features make use of what Corona Labs calls “Premium Graphics”, which require a Corona Pro license.

That’s a good idea about having an onComplete listener for camera movement. I’ll add that in and release it in a minor update this week.

#8

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

With the new onComplete functionality, setting up simple camera oscillations is easy.

moveBack2 = function(event) print("done1", event.levelPosX, event.levelPosY, event.layer) mte.moveCameraTo({levelPosX = player.getLevelPosX() + 48, levelPosY = player.getLevelPosY() + 48, time = 1500, layer = event.layer, easing = "inOutQuad", onComplete = moveBack1}) end moveBack1 = function(event) print("done1", event.levelPosX, event.levelPosY, event.layer) mte.moveCameraTo({levelPosX = player.getLevelPosX() - 16, levelPosY = player.getLevelPosY() - 16, time = 1500, layer = event.layer, easing = "inOutQuad", onComplete = moveBack2}) end mte.moveCameraTo({levelPosX = player.getLevelPosX() + 48, levelPosY = player.getLevelPosY() + 48, time = 1000, layer = 1, onComplete = moveBack1}) timer.performWithDelay(50, function() return mte.moveCameraTo({levelPosX = player.getLevelPosX() + 48, levelPosY = player.getLevelPosY() + 48, time = 1000, layer = 2, onComplete = moveBack1}) end) timer.performWithDelay(100, function() return mte.moveCameraTo({levelPosX = player.getLevelPosX() + 48, levelPosY = player.getLevelPosY() + 48, time = 1000, layer = 3, onComplete = moveBack1}) end) timer.performWithDelay(150, function() return mte.moveCameraTo({levelPosX = player.getLevelPosX() + 48, levelPosY = player.getLevelPosY() + 48, time = 1000, layer = 4, onComplete = moveBack1}) end) timer.performWithDelay(200, function() return mte.moveCameraTo({levelPosX = player.getLevelPosX() + 48, levelPosY = player.getLevelPosY() + 48, time = 1000, layer = 5, onComplete = moveBack1}) end)
#9

Thanks dyson that’s great!

That’s an interesting demo. Now I think I know what sea sickness feels like. :wink:

Great news on the rewrite! Look forward to seeing what you come up with!

#10

Hey dyson,
 
The recent MTE update has been a great help - thanks! I have another feature request that I think will be useful to others, I know it will be to me, and I wondered what you thought. I note in your last update you said no new features will be added after the release candidate so I’m hoping it might be possile to squeeze this one in if it’s viable.
 
Until now I’ve been experimenting with MTE using simple sprites created with display.newSprite( imageSheet, sequenceData ) and everything has been great. However, my game now requires some more complex and optimised sprites, which are essentially a display group containing several sprites (I’ve added several custom methods to the display group to manipulate and animate the sprites within). It’s essentially a variation of the ideas presented in this Corona Labs tutorial: Dynamically-Optimized Sprites .
 
I experimented with this approach, using a display group containing several sprites, and encountered the following error:

stack traceback: &nbsp;&nbsp; &nbsp;?: in function \<?:218\> &nbsp;&nbsp; &nbsp;[C]: in function 'setFillColor' &nbsp;&nbsp; &nbsp;...uilds)\mygame\libs\mte\mte.lua:1513: in function 'addSprite' &nbsp;

 
Which raises 2 questions…

  • Would it be possible to allow such complex / optimised sprites to work with MTE? This would be a HUGE help to me and I’m sure to others.
  • Is there anything within MTE that would cause issue with the programatic tinting discussed in the above tutorial (see “Tinting” the Elements). I intend to use this method to randomly create a vast amount of visually different enemies using just a few simple greyscale assets. I’m thinking tintLayer / tintLevel / tintMap might conflict…?

And that raises a 3rd question I’ve just considered… how do you easily untint a layer / level / map? A possible scenario might be where you want a blue-ish room that eases to original colours once a light switch is flicked or perhaps a flickering light that quickly alternates between 2 or more colours (a broken overhead light, a neon sign, a disco, etc)
 
A few thoughts there and lots of potential. Look forward to hearing from you and thanks as always!

#11

Yes, this is all supported already, but not obviously so.

  1. You can add group objects to MTE just as you would any other sprite, you just have to change setup.kind from “sprite” to “line”. Line was an unusual label choice I admit; it’s changing to “group” and/or “vector” in the new rewrite. Essentially all this does is prevent MTE from calling unsupported functions on it, like setFillColor.

  2. Using groups as sprites has not been thoroughly tested. In theory any problem that may come up will be easily solvable. The engine doesn’t attempt to alter the contents of a group running as a sprite. On the plus side, it doesn’t apply layer lighting to the group’s contents. This allows unobstructed tinting of the individual elements. On the downside… it doesn’t apply layer lighting to the group’s contents. This prevents the sprite from automatically responding to layer lighting changes.

Easing the layer lighting is easy. Just call mte.tintLayer(layer, color, time, easing). Color is a table of the three color values. If you call the function with color and time set to nil, the function will return a boolean specifying whether a tint operation is in progress or not. Other available functions are tintTile(), tintLevel(), and tintMap(), which all work much the same way. The flickering might be a little trickier because tinting happens in mte.update, so turning the lights “on” immediately after turning them “off” may not produce a flicker if mte.update hasn’t executed the “off” yet.