Objects not fitting snug in collidable spaces?
Tryangle
Member Posts: 37
I make an "spawner object" that spawns two rectangles 128 pixels tall, one of the left and one on the right, so that the space between them is exactly 64 pixels.
I make that same "spawner object" spawn two 64x64 squares between the two rectangles, one 32 pixels up and one 32 pixels down so that together, all the objects make a large square shape.
I make the squares collidable with the rectangles and squares.
All objects are on non-fractioned pixel locations (e.g. position x of an object is at 500, not 500.399). Without fail, I have the following problems:
1. One of the squares always moves off its pixel, leaving a sliver of space between it and a wall, despite any physics properties I give it, and despite any functions I use to reposition them to be evenly on a pixel, including floor, change position, and so on. Even constraining a square while the square is not intended to move does not work.
2. If I have a behavior where a square moves up from between the rectangles, and then I have it move directly back down, it always collides with the rectangles and will not go back between the rectangles. Upon closer examination, the squares do not even touch the rectangles vertically when moving downward, there is a sliver of empty space. Furthermore, the 64x64 squares appear slightly horizontally longer than the 64x64 empty space between the rectangles. How can the squares, being exactly 64x64 pixels, and the empty space which is 64x64 pixels, not be the same size?
Is this a recurring problem? Does it turn out that exact mathematical measurements do not apply to square and rectangular objects that have collisions? What I want to do, is be able to have collidable 64x64 squares within 64x64 spaces move through those empty spaces. But apparently Gamesalad can't do this?
Answers
Seems to work fine for me ? (example attached)
I added a modulus switch to the red blocks to move upwards and back down, and there is no problem with your project example. However, I am doing the exact same thing in my project and I have the problem. I am going to remake what I am trying to do from scratch in my project and see what happens.
https://dropbox.com/s/l4fnu1bt7bobt24/Uncooperative%20objects.png?dl=0
Redesigned all the involved objects, and still have the same issue with exact same numbers. Note in the image that the 512's are the spawner object saying what its position is, and the top/bottom numbers on the squares are their x.y coordinates.
I am ready to say that I am having a bug, because your project behaviors and my project behaviors are identical (aside from placing squares on top layer so numbers aren't obstructed) but it is producing two different outcomes.
Very frustrating.
@Socks Unchecking movable, which would be a requirement for a wall object for which the squares would fit snug, breaks your project. I migrated your objects into my project and changed them one attribute at a time until I found what was different. Then I unchecked the box in your project and got the same problem. The reason why your project version worked was because your blue walls are pushing off the squares equally, so that the red squares don't move but the blue walls do, leaving the red boxes to not have a changed x coordinate.
So it would appear that GS has bad collision maths?
GameSalad uses Box2D physics. I would suggest that the kind of precision you were expecting was not the intent of this fun little physics engine. The math always seems to be a little fudgy with Box2D, due to rounding errors and such -- but its great for goofy fun games.
The way I look at it is, if your game uses goofy sounds like "sprong," "boink," or "klunk" then GameSalad's physics engine is for you. If instead, your game will have precise sounds like "psst," "pfft." or "shup" then you want to use more precise movement (using interpolate, or change attribute) and skip relying on GameSalad's physics engine.
I unchecked 'movable' and it still works just fine for me.
EDIT: Just checked, I see, you mean that making an actor movable (leaving movable checked) breaks the project.
I'm not sure what this means ("a requirement for a wall object for which the squares would fit snug"), but can you not simply switch movable off ? Do you need it on for a reason ?
Making the side rectangles and the centre squares 'moveable' seems to work too.
@Socks -- I hope you don't mind that I edited the above quote to show that @Tryangle made that comment.
Cheers !
@Socks This is what I want to do: Put a box in a passage way that has walls. I want the box to be exactly equal width to the passage size. I want to be able to move the box through the passage cleanly. I want the passage to kitty corner at 90 degree angles so that the box can move through the passage. In your project, the blue rectangles would be walls, and the red square would be the box. It is important for my project that there are no empty spaces between the box and the walls, because things will be able to get through that I don't want to get through, e.g. small objects.
@RThurman Your input is insightful, and a good explanation for how the engine works, but does not solve the problem. The problem is that objects are not actually the measurements you give them, or/and object positions are not representing their true positions. Otherwise the project in the link I am adding here would work.
https://www.dropbox.com/s/mzzkwxbjlhlp3vv/S with changes.zip?dl=0