removing tile on overlap with player

Gymbyl Coding
#1

Hi,

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 ) &nbsp; &nbsp; if ( event.phase == "began" ) then &nbsp; &nbsp; &nbsp; &nbsp; local tile = event.object1 &nbsp; &nbsp; &nbsp; &nbsp; if(tile.layerIndex==1 and not tile.collected) then &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; if(tile.gid \< 100) then &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; tile.alpha=0 tile.collected=true &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; end &nbsp; &nbsp; &nbsp; &nbsp; end &nbsp; &nbsp; end end

my questions are

  1. 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

  2. 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!

#2
  1. 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.

  1. 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.
  • Caleb
#3

thanks Caleb,

i didn’t notice it being re-drawn originally as I have downwards gravity…but you can bounce back up. … so yes theyr’e there again

I’m having trouble accessing that function… i thought it’d be something like

map.layer[1].lockTileErased(tile.tileX, tile.tileY)

but i just get errors

thanks for any advice

j

#4

not sure why accessing via index didn’t work (it couldn’t find lockTileErased function)… this works great now thanks

&nbsp;map.layer['Layer1'].lockTileErased(tile.tileX, tile.tileY)
#5

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?

  • Caleb
#6

yeah i got confused somewhere

my collectibles are on ‘Layer1’… this all works now… I just wasn’t sure about the index references

local function onCollision( event ) &nbsp; &nbsp; if ( event.phase == "began" ) then &nbsp; &nbsp; &nbsp; &nbsp; local tile = event.object1 &nbsp; &nbsp; &nbsp; &nbsp; if(tile.layerIndex==1) then -- \<== what does layerIndex refer to (Z?) &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; if(tile.gid \< 100 and not tile.collected) then -- these both work now, i had assumed they were bottom-up ordered &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; --map.layer['Layer1'].lockTileErased(tile.tileX, tile.tileY) &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 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)

#7

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 :).

  • Caleb
#8

i would assume the other way round. lowest index  = lowest z = lowest layer… i guess it depends how you treat Z. 

if you look at the image on my last post Layer1 is the lowest layer, Layer2 is above it.

so i’d expect the bottom layer to be 1, and the layer above to be 2.

i guess that’s the opposite of how you’ve implemented it.

thanks

j

#9

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.

  • Caleb
#10

It’s easy enough to workaround now I know how it’s working, but yes normally things with higher z-order get drawn on top of others https://eliasdaler.wordpress.com/2013/11/20/z-order-in-top-down-2d-games/

#11

I might change this in Dusk 1.0 (aye, Dusk isn’t even out of beta!). For the time being, you’ll have to get used to opposite Z-ordering :D.

  • Caleb
#12
  1. 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.

  1. 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.
  • Caleb
#13

thanks Caleb,

i didn’t notice it being re-drawn originally as I have downwards gravity…but you can bounce back up. … so yes theyr’e there again

I’m having trouble accessing that function… i thought it’d be something like

map.layer[1].lockTileErased(tile.tileX, tile.tileY)

but i just get errors

thanks for any advice

j

#14

not sure why accessing via index didn’t work (it couldn’t find lockTileErased function)… this works great now thanks

&nbsp;map.layer['Layer1'].lockTileErased(tile.tileX, tile.tileY)
#15

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?

  • Caleb
#16

yeah i got confused somewhere

my collectibles are on ‘Layer1’… this all works now… I just wasn’t sure about the index references

local function onCollision( event ) &nbsp; &nbsp; if ( event.phase == "began" ) then &nbsp; &nbsp; &nbsp; &nbsp; local tile = event.object1 &nbsp; &nbsp; &nbsp; &nbsp; if(tile.layerIndex==1) then -- \<== what does layerIndex refer to (Z?) &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; if(tile.gid \< 100 and not tile.collected) then -- these both work now, i had assumed they were bottom-up ordered &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; --map.layer['Layer1'].lockTileErased(tile.tileX, tile.tileY) &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 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)

#17

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 :).

  • Caleb
#18

i would assume the other way round. lowest index  = lowest z = lowest layer… i guess it depends how you treat Z. 

if you look at the image on my last post Layer1 is the lowest layer, Layer2 is above it.

so i’d expect the bottom layer to be 1, and the layer above to be 2.

i guess that’s the opposite of how you’ve implemented it.

thanks

j

#19

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.

  • Caleb
#20

It’s easy enough to workaround now I know how it’s working, but yes normally things with higher z-order get drawn on top of others https://eliasdaler.wordpress.com/2013/11/20/z-order-in-top-down-2d-games/