Hi,
You are mixing two separate notions:
1) Collision detection: detecting when two entities overlap each other.
2) Obstacles: allowing or not an entity to traverse another one.
In your case, you are interested in 2).
(Indeed, you could also use 1) to detect the overlapping *after* it happened and force the hero to move back. This is complicated and seems like a dirty hack).
For custom entities, 1) is add_collision_test() and 2) is set_can_traverse() and set_traversable_by().
You can do
but here, the rectangle (the bounding box) of the custom entity will entirely be an obstacle.
It is possible to do something more elaborate by passing a function instead of a boolean:
I use this kind of code in the engine to implement complex traversable properties of diagonal jumpers. But this is quite advanced. If you really need that, there is usually something wrong.
I'm not sure it is a good idea to make a sprite that blocks the hero depending on the exact pixels that overlap him. It is very strange that the obstacle part of the sprite changes at each frame. What if the hero is outside the sprite during one frame, and at the next frame blocked by it? This is weird. The hero should never be inside an obstacle. Plus, there is no easy way to implement that with the API. Also, it would be slow.
For example, if your entity a big sprite of 64x64, most of the time you can give the entity a smaller (fixed) bounding box, like 48x32 or something else and you will be okay with obstacles. You don't need another entity to act as a protection square.
If your entity is really too irregular for that, can you tell me more? What kind of entity are you making?
You are mixing two separate notions:
1) Collision detection: detecting when two entities overlap each other.
2) Obstacles: allowing or not an entity to traverse another one.
In your case, you are interested in 2).
(Indeed, you could also use 1) to detect the overlapping *after* it happened and force the hero to move back. This is complicated and seems like a dirty hack).
For custom entities, 1) is add_collision_test() and 2) is set_can_traverse() and set_traversable_by().
You can do
Code Select
your_custom_entity:set_traversable_by("hero", false)
but here, the rectangle (the bounding box) of the custom entity will entirely be an obstacle.
It is possible to do something more elaborate by passing a function instead of a boolean:
Code Select
your_custom_entity:set_traversable_by("hero", function(custom_entity, hero)
local hero_x, hero_y = hero:get_position()
local traversable = ......... -- some kind of elaborate test here depends on the exact position of the hero on the custom entity
return traversable
end)
I use this kind of code in the engine to implement complex traversable properties of diagonal jumpers. But this is quite advanced. If you really need that, there is usually something wrong.
I'm not sure it is a good idea to make a sprite that blocks the hero depending on the exact pixels that overlap him. It is very strange that the obstacle part of the sprite changes at each frame. What if the hero is outside the sprite during one frame, and at the next frame blocked by it? This is weird. The hero should never be inside an obstacle. Plus, there is no easy way to implement that with the API. Also, it would be slow.
For example, if your entity a big sprite of 64x64, most of the time you can give the entity a smaller (fixed) bounding box, like 48x32 or something else and you will be okay with obstacles. You don't need another entity to act as a protection square.
If your entity is really too irregular for that, can you tell me more? What kind of entity are you making?