(04-11-2020, 04:37 PM)megamarc Wrote: Hi!
Of course, you have to use the function TLN_GetLayerTile() on the layer you want to test. You pass layer index, the x and y pixel position you want to test, and a pointer to a TLN_TileInfo struct. This struct will be filled with the tile at that position, its type, flags, offet inside the tile, color of the pixel at that position... this is what you need to implement sprite vs layer collision.

Let me know!

(04-13-2020, 02:59 PM)megamarc Wrote: A boolean "Collidable" would be impractical, as there are many types of collisions: is the block solid walkable floor? One-way platform? A ladder?  Sliding slope? Dangerous spikes? All of them are collidable but must behave differently.

Currently up to version 2.4.x, Tilengine reads a custom property called "type" in the tileset. It is numeric in type, and is the value returned in TLN_TileInfo::type structure member (http://www.tilengine.org/doc/struct_t_l_n___tile_info.html). The example project SuperMarioClone uses this system to determine the type of tile, if you open the file smw_foreground.tsx you will see it.

Since I implemented this feature, the Tiled editor has had the standard property Type added to the tilleset. In a future update that I am preparing, it will also bring this property to get the type, although I will leave the current custom property for backwards compatibility. You can even see this parameter unused in your screenshot, just below ID.

There are other gameplay implementations that use a layer exclusively for collisions, in which there are as many different tiles as there are collidable block types, and it uses the tile ID as a type. It is a bit redundant, and although it can be done it is preferable to work directly with the "type" property in the main tileset:
https://ansimuz.itch.io/sunnyland-forest

(04-14-2020, 03:36 AM)megamarc Wrote: Hi,
You're experiencing two unrelated problems:

1. Seems that TLN_GetTileInfo() is not correctly protected against passing negative values as world coordinates, that's why sometimes "segfaults" when walking left and up. I should protect it, menawhile you can do it in your application, checking against negative values and if so, adding the size of the negative dimension. You can get them at runtime with TLN_GetLayerWidth() and TLN_GetLayerHeight().

2. Bad detection: you forgot to initialize city->initx and city->inity to 0 at startup, they have undefined values you're setting up the starting position of the layer with these unknown values. That's why what you see is not what you expect, you're checking in one place but displaying another. Setting them to 0 and then calling TLN_SetLayerPosition() will fix it.

(04-14-2020, 02:45 PM)megamarc Wrote: That's because you're just checking collision in a single point in your character, that is not representative of its shape. To properly manage it, you should work with an array of collision points around the edge of your character, and when you move it, check all the points that are on the edge of the walking direction (if you move to the right, check all collision points on the right side of the character).

How many points and at which locations? That depends on your gameplay structure, but as a general rule, they should be separated at most the size of the tiles in the collision tileset. In your project, city tiles are 16 pixels per side, and beeb is 32, so you have to use between 2 and 3 points per side. For example [0,16,31], or [8,24]. The second set leaves a small border of 8 pixels that in some cases may feel more natural than clipping to the outer edge. In 3/4 top-down perspective -like classic Final Fantasy games-, the upper collision edge should be a bit above feet, not on the head. As I said, it depends on gameplay being created. But consider an array of points per edge.

This article may help you. It's about platformers, but the concepts about motion and collision are quite general:
http://higherorderfun.com/blog/2012/05/20/the-guide-to-implementing-2d-platformers/

• when the intention of a function is to return a true/false value, define it as bool and return an explicit expression that evaluates to bool. test_direction() and detect_collision_area() have unclear intention, they return the numeric type of the tile but are treated as boolean.
  
• logic of test_direction() is wrong. Implement it in a way that returns true only when all calls to detect_collision_area() return false, any positive in detect_collision_area() must return false. In layman terms: only allow motion if all testpoints are not colliding.
  
• test_direction() has another problem, it only tests the corners of the character that are 32 pixels away, but tile size is 16 pixels. There are holes inside the character. Collision points must not be farther than 16 pixels. Insert an extra collision point in between.