LÖVE

I love the collision implementation, after building my own (take a tile and create a individual 32x32 shape etc)

I had run into a issue, some of my tiles are not actually a full 32x32 solid, one is 13x32 pixels, so i had to make a change to my builder to look at the gid and have a separate file provide how the shape is made.

THEN having to deal with many physics things on large maps made me wonder if i could optimize this, blending tiles together into a single shape. ie a 64x64 map whos boundaries are full 32x32 solids. If i optimize this map i can have instead 256 objects but 4 (4 walls)
So i also noticed what about my 13x32 solid tiles? Another file would provide how tile A "blends" its shape into tile B to form a single shape.

Iterating only along the X-axis making long horizontal shapes out tiles that are adjacent to each other was my goal (i would deal with the Y axis afterwards)

I failed miserably, It did blend, but when i tried including the 13x32 tiles i couldnt wrap my head around the coordinate information.

--==--==--==--==--==--==--==--==--
In the short stack, instead of using STI per Tile collision, i simply defined some rectangles in Tiled and set those as Collidable for STI.


I have a request though. Can you please make it so that the fixture or container of the fixture and shape created by STI also have a variable that points to the object that STI used. IE in the collisions table returned by initWorldCollision : This is mostly because some collidables may want to do something special when a player collides, and its hard to know if the fixture collided with is a special tile or even a tile at all.

At the moment i assume all collidables are "ground" tiles, and on collision with a contact normal.y that puts the player ontop the ground_tile sets a variable that lets the player move or jump, but it would be nice to say if the tile is a slippery tile then set a variable that changes the slipperiness of the players movements etc etc

End.

print("Thanks for STI anyhow...")

Well, I'm still concerned about that flipping bug (or a bunch of bugs to be exact).

First of all, there is still no handling for the case when all three flip bits are set. Here's the solution, I guess.

Secondly, the implemented scale/rotation shift compensation method does not work correctly for two of the flipping cases: when all three flip bits are set and when there is only diagonal flip bit set (as you can see on the attached screenshot; note that this is the behavior that is observed when the above fix is applied, the original behavior can be seen here). I'm unsure how to fix this one correctly. Probably with something like this? Don't look at me like that, this thing came out kinda cumbersome and obscure but it works fine and even handles non-square tiles the same way as the Tiled editor itself.

Furthermore, these calculated coordinates which are used when adding a quad to the batch are then saved to the instances table and are used to generate collision objects' positions. This causes them to appear misplaced (that can also be seen on the screenshots). I think the correct way would be to save the "original", not compensated coordinates here since it makes more sense in terms of later use. Also, the collision objects do not rotate when generated for non-square tiles but I haven't looked into this part yet.

Hope to get your feedback to eventually resolve these issues.

Hey, sorry for being so late to respond. I was out of the province for a few weeks and hadn't much time to work on STI. I also have another project I am working on that has my attention. I'll see if I can't focus on STI today and knock out a few of these bugs.

¡Double Post!

I merged your pull request and that fixed the flipping issues you were having. I also found another issue when dealing with flipped tiles that I fixed.

I added some helper functions to get the properties form a layer, tile, or object. Check 'em out! I'll update the documentation at some point, too.

Here's another couple of suggestions.

1. I still think that it would be really convenient to have access to tile/object properties within collision callbacks. In my opinion it makes it easier to implement a lot of things related to player-environment interaction (e.g. using doors, taking damage from traps etc). What do you think of this solution?

2. Before adding tiles to sprite batches STI processes their GIDs, flips tiles accordingly and stores them in map.tiles table. But it doesn't perform this before setting sprite batches for tile objects, so when there's a flipped tile object in the map the following lines throw an error (trying to index tile which is nil): (Of course, if there is also a correspondingly flipped tile in this map and it's been already processed then there won't be any error)

I'd personally put that GID processing code in a separate method and then reuse it in the code above.

That solution looks pretty reasonable, yeah. Feel free to send a pull request.

You're right, I totally overlooked that! I'll be sure to put a fix in soon.

Updated to 0.9.7.

If i understood the change correctly, wouldn't this work? But this give me an error: attempt to index field 'object' a nil value

User-defined properties are stored in object.properties for objects or tile.properties for tiles so you should do something like a:getUserData().object.properties.type instead. But I'm not sure what's wrong with that object field. Hard to tell without seeing the entire code.

I was wondering if there was a way for the gridlocked player tutorial to work with this library. It may be my misunderstanding of lua but so far I haven't been able to lock a sprite to a 16 x 16 grid.