[isometric] - Collision detection not working properly #52
Comments
|
Well i've been working around this problem, and as i've realized that in an Isometric map, the collitions are made when the base of two objects are colliding, not the rectangles around them. So, i've been able to even correctly zSort objects, but using extra parameters:
these parameters also fix the positioning bug, because we can translate the tile to pixels position, and get the pixel position of the tile where the object must be placed, and then substracting the position on the first tile, we can place the object correctly. I know there's probably a better way of doing it, but this is how i've done it, also I have a little method for zSorting the isometric objects, there's also a little patch for melonjs. Maybe we can get some of this bugs fixed... I hope this helps |
|
For this one, we just need non-AABB collision detection. #103 includes some improvements to the general collision detection system. Apart from the performance boost, it also changes the internal storage structure used to determine how objects should be considered for collision tests (this is before the actual collision tests take place). With the new storage system, we can now support "collision object layers" in a map, so any polygon or polyline object can be used as collision shapes. That said, the focus on #103 is on the performance aspect and fixing general bugs. Another ticket should be created for adding non-AABB collision tests. I know there was discussion on some other tickets about implementing the Separating Axis Theorem algorithm, though there are others available as well, like Minkowski Difference Also, I found https://github.com/jriecken/sat-js which we may be able to use directly. Anyway, with a better collision testing algorithm, those collision shapes can easily be created using the polygon object tool in Tiled. This is the only thing that I can recommend, moving forward. Attempting to wrangle the AABB tests to support per-pixel collisions on isometric rectangles is not going to be pretty. And we already have to do something similar for backward compatibility with slope tiles. :( |
|
Well, instead of "attempting to wrangle the AABB tests to support per-pixel collisions on isometric rectangles", you could calculate collisions in tile coordinate system - this way the bases would be perfect rectangles. |
|
Yes, I thought more about it, and basically the same approach would work for both types of maps (orthogonal and isometric). The only drawback I see is that you'll have to call |
|
i did not really tested that one, but with the new SAT based collision algorithm, and the coming ticket #538 , this one should be done too. (keeping it open until properly tested) |
…e collision system based on the following one, courtesy of Pierre, that I had hanging around since a while : https://github.com/mfpierre/melonJS/tree/isometric_example
|
here is the result so far : |
|
Hehehe! I see the projection on the shapes needs to be fixed. So this should be really done after that! |
|
That looks cool though :) On Fri, Oct 10, 2014 at 3:43 AM, Jay Oster notifications@github.com wrote:
Aaron McLeod |
|
so I've been playing with this one a bit, rotating shapes by 45", scaling vertically by 0.5 and translating by half the height, and yet it is not coming out right at all, so it appears this is a bit more tricky that I initially thought :) |
|
nah cause i think the scaling would compound. I think that would work if it wasn't for the rotation. |
|
what do you mean by "would compound" ? |
|
Probably a bad choice of words (had no caffeine at the time, and it's morning). Meaning when you perform a rotation, then scale & move up, spaces would likely appear in spots that you don't expect them to. Doesnt know how to consume the space between tiles as easily. |
|
As far as I know, the only requirement is rotate and scale. Both operations need to be anchored on the same point. |
|
All done. |
|
amazing! On Tue, Oct 14, 2014 at 2:56 PM, Jay Oster notifications@github.com wrote:
Aaron McLeod |
…jection - Do not reuse vectors between each line segment in a TMX PolyLine, or rotation/scale will double the operation on each. - Fixed some documentation in TMXObjectGroup. - Added a new `orientation` property to TMXObject. - Added collision detection and simple 8-way movement to the isometric RPG example. - The numbers used to scale are arbitrary, and I came upon them through trial and error. I originally thought (4 / 3), (2 / 3) would work, but that make the shapes too small. TODO: - Come up with a better rationale for the magic numbers
|
Looks good on my end. This can be closed, even though there's a TODO note in the commit comment. ;) It's not a super big deal, I just don't really understand what the numbers in |
|
Out of curiousity, how well does it work when you walk around the tree or rock with just the one side for collision? |
|
About as well as you expect. ;) I'm not sure why those were the only shapes placed for the rocks and tree. It would be better to just use rectangles for those. |
|
Spoke too soon! Rectangles are not positioned correctly. Even the player entity's default position doesn't match Tiled
|
- Circle positions are still incorrect, but will be fixed when rotation and scaling is supported for that shape.
|
Woohoo! DONE and DONE! The only thing left is properly scaling and rotating the ellipses. That will be taken care of in #583 |
|
I cannot beleive this one is finally closed, and how almost easy it was with the new collision system! That was a beautiful work team guys :):):) |
|
How do I enable debug panel in melonJS 2? |
|
and how do I enable devrlopment mode? I am not very expert, I don't know anything about wasm, em6, ecmascript, boilerplate or whatelse, I use plain javascript. |
The issue is related to #51 and the fact that in an isometric world, the tile 0 is in fact not at position (0,0) on the screen. This means that when the getTile(x,y) position is invoked for collision detection, the wrong tile is returned.
I guess this could be fixed by either managing the isometric case in a different way in the getTile function, or by computing xLUT and yLUT in a different way when in an isometric level.
The text was updated successfully, but these errors were encountered: