I’m currently porting over some Phaser prototype code to Corona
I have a ball that drops from the top of the screen and collects items on the map from “Layer1” and rebounds off objects on “CollisionLayer”.
the collectible items are drawn on a layer in Tiled so currently I’m doing this:
local function onCollision( event ) if ( event.phase == "began" ) then local tile = event.object1 if(tile.layerIndex==1 and not tile.collected) then if(tile.gid \< 100) then tile.alpha=0 tile.collected=true end end end end
my questions are
i’m currently using a physics layer for Layer1, so every tile is a sensor object to allow overlap check… so with a lot of tiles, I’m wondering if this is going to kill mobile performance. (in my JS prototype i just checked 8 points around the player which seemed to suffice). any other suggestions welcome! thanks
other than setting tile.alpha=0 , is there a fast way to remove a tile from the map?
thanks for any advice
great library though… i got my 3 layer prototype up and running *really* quickly
regards
J
ps I’ve attached an image explaining the 8 way basic coordinate check “overlap” method I used in Phaser… it’s accurate enough, just not very!
A tile layer full of physical tiles usually runs pretty fast. Unless you’re experiencing a lower FPS rate, I wouldn’t worry too much about it.
On the other hand, if you’re using physics to detect which tiles you’re on, you might want to switch for other reasons. I like to stay away from Box2D as much as possible for a number of reasons - among them are complexity, “black-box-ness”, and lightweight-ness. For a simple overlap check (with maybe basic collision resolution), it’s a bit overkill.
To actually remove a tile (as in really, truly remove it so it won’t ever come back), you can use layer.lockTileRemoved(x, y). To only hide the tile, you can use plain ol’ alpha or isVisible setting. Keep in mind that you’ll have to reset the tile’s alpha or isVisible each time it’s culled and re-drawn.
If layer #1 isn’t a tile layer you’ll get an error because it’s not available in object layers (for obvious reasons). Otherwise, what errors are you getting?
my collectibles are on ‘Layer1’… this all works now… I just wasn’t sure about the index references
local function onCollision( event ) if ( event.phase == "began" ) then local tile = event.object1 if(tile.layerIndex==1) then -- \<== what does layerIndex refer to (Z?) if(tile.gid \< 100 and not tile.collected) then -- these both work now, i had assumed they were bottom-up ordered --map.layer['Layer1'].lockTileErased(tile.tileX, tile.tileY) map.layer[3].lockTileErased(tile.tileX, tile.tileY)
looks like ‘Layer1’ is my third layer, but it’s layerIndex=1 because it’s on the bottom?
my “collisionshapes” objects layer also has physics enabled but its layerIndex is ‘nil’. is that because it’s not a tile layer?
(essentially ‘Layer1’ is a tile layer with all sensors, so the player can overlap and collect, and “collisionshapes” contains invisible objects for the platforms and bumpers)
Hm. Layers are indexed from top to bottom; layer[1] is the top and layer[#layers] is the bottom. This made the most sense to me since it reflects the layers’ Z-indexes.
Now that I think about it, the layerIndex property does seem a little counter-intuitive. It’s meant to represent the index in Tiled, which stores the layers from back-to-front, but you’re right, it should probably be the index of the layer in map.layer. I’ll cut it into tile.tiledLayerIndex and tile.mapLayerIndex or something like that and deprecate layerIndex until I make a full switch.
[EDIT]: Also, only tiles get the layerIndex property. Sounds like layerIndex needs some serious work :).
Weird… I’ve always thought of Z-index as going back “into” the screen with higher values. I don’t know, it just felt more intuitive to me. That’s why I made it that way in Dusk. I realize now that a lot of things use the opposite approach that you’re meaning. Not much I can do about it now - swapping the order of the layers just like that might result in some unhappy Dusk users :D.
A tile layer full of physical tiles usually runs pretty fast. Unless you’re experiencing a lower FPS rate, I wouldn’t worry too much about it.
On the other hand, if you’re using physics to detect which tiles you’re on, you might want to switch for other reasons. I like to stay away from Box2D as much as possible for a number of reasons - among them are complexity, “black-box-ness”, and lightweight-ness. For a simple overlap check (with maybe basic collision resolution), it’s a bit overkill.
To actually remove a tile (as in really, truly remove it so it won’t ever come back), you can use layer.lockTileRemoved(x, y). To only hide the tile, you can use plain ol’ alpha or isVisible setting. Keep in mind that you’ll have to reset the tile’s alpha or isVisible each time it’s culled and re-drawn.
If layer #1 isn’t a tile layer you’ll get an error because it’s not available in object layers (for obvious reasons). Otherwise, what errors are you getting?
my collectibles are on ‘Layer1’… this all works now… I just wasn’t sure about the index references
local function onCollision( event ) if ( event.phase == "began" ) then local tile = event.object1 if(tile.layerIndex==1) then -- \<== what does layerIndex refer to (Z?) if(tile.gid \< 100 and not tile.collected) then -- these both work now, i had assumed they were bottom-up ordered --map.layer['Layer1'].lockTileErased(tile.tileX, tile.tileY) map.layer[3].lockTileErased(tile.tileX, tile.tileY)
looks like ‘Layer1’ is my third layer, but it’s layerIndex=1 because it’s on the bottom?
my “collisionshapes” objects layer also has physics enabled but its layerIndex is ‘nil’. is that because it’s not a tile layer?
(essentially ‘Layer1’ is a tile layer with all sensors, so the player can overlap and collect, and “collisionshapes” contains invisible objects for the platforms and bumpers)
Hm. Layers are indexed from top to bottom; layer[1] is the top and layer[#layers] is the bottom. This made the most sense to me since it reflects the layers’ Z-indexes.
Now that I think about it, the layerIndex property does seem a little counter-intuitive. It’s meant to represent the index in Tiled, which stores the layers from back-to-front, but you’re right, it should probably be the index of the layer in map.layer. I’ll cut it into tile.tiledLayerIndex and tile.mapLayerIndex or something like that and deprecate layerIndex until I make a full switch.
[EDIT]: Also, only tiles get the layerIndex property. Sounds like layerIndex needs some serious work :).
Weird… I’ve always thought of Z-index as going back “into” the screen with higher values. I don’t know, it just felt more intuitive to me. That’s why I made it that way in Dusk. I realize now that a lot of things use the opposite approach that you’re meaning. Not much I can do about it now - swapping the order of the layers just like that might result in some unhappy Dusk users :D.