Collision map boxes behave like a line when checked with collideMap()
-
Please tell me if collideMap() works as designed or what I do wrong, because thats an incredible helpful function, I would like to use. Example is shared, SW-4464-9632-0709.
What I expected: I put a sprite on top of a collision box, set with the map editor and by calling collideMap(sprite) its coordinates just gets moved outside of the collision box.
Problem 1: the collision box, in the map editor is behaving like a line
Putting the collsion box exactly on top of the floor-image, did place the sprite with its feet inside the collision box. So, I moved the collsion box first, fitting its center line to the floor, like this:
Problem 2: the sprite is moved 3 pixels below the center of the collision box
Image before drawing the result of the collideMap():
What happens, after calling the collideMap() function:
So, I added 3 pixels in the sprite to the feet of the sprite character.
So, if the collision box could actually just be placed right over the floor-tile-image and the sprite would be moved exactly on top of it, this would make the work with the sprite and map editor very smooth.
Thank you for reading and checking my problem!
-
Ok. Guess I have to dig deeper through the map examples. Found fact: the default collision shape border is not as big as the sprite image. Interesting: if i do setspritecollisionshape witht the correct size, it still shows a smaller shape than the sprite. So i just added 60 pix to the collision shape height. And it works for now.
-
-
I'm similar to @pianofire in that I've not done too much with maps yet, but I did help someone with theirs.
Saying that, I'm struggling to understand what your exact problem is?
The thing is that a map and collision box are not designed to prevent your sprites from entering into the box, just to give you the information to know when the sprite has entered inside the collision box and allow you to do whatever you wish with that info. If you want your player to move along the top of the ground then there is no reason to make the box anything other than the exact size of the ground but you will have to write the code to ensure your sprite doesn't actaully go inside the box. You can do that using the information in the resolution_a vector returned by the call.
Apologies if I am misunderstanding the question.
Help might be a bit thin on the ground this week. The primary business of Fuze outside of Fuze4 Nintendo Switch is coding workshops for young people and because it is school holidays this week in the UK the team are very tied up with that.
-
@spikey I noticed that too! I added a debug flag to my current program, and when enabled I show the collision boxes. When I flipped that on for the first time, I was surprised to see that the hit box was smaller than the actual sprite boundaries.
-
@Spacemario the automated collision shape is only really going to work for the simplest of shapes. For everything else there are commands to define your own
-
@Martin That makes sense! That's what I'll wind up doing-- I saw the commands there, just haven't hooked them up yet.
-
Thanks a lot. Your elaboration is very helpful.
So the collision box is not meant to be used to cover a whole wall to not run into it. You have to cover the wall middle with a collision box and you still check the distance by yourself, as soon you get collision condition?
I thought i could smash two flies with one slap.What commands?
-
Well, no - you can cover an entire wall but it won't stop your sprite from moving into the wall by itself. You need to do that bit.
I may not be explaining myself very well and I'm not at my Switch at the moment. One of the included sample programs on collision maps shows what I mean very well.
