sprite appearing ithin the floor

[teamrocketboyz]

hello all i have a small problem where my character can walk around and when i press down he rolls along the floor, upon releasing down i want the sprite index to return to the standard player sprite but this sprite returns at the same height that the rolling sprite was at meaning that my player is now stuck in the floor.

i have messed around with the centre point of the player but so far nothing has resolved this.

 

[Simon Gust]

Do you displace your x and y coordinates manually when changing to rolling? You might be setting the player inside the floor where he can't escape anymore. The centre point should be x in the middle and y at the bottom.

 

[teamrocketboyz]

Do you displace your x and y coordinates manually when changing to rolling? You might be setting the player inside the floor where he can't escape anymore. The centre point should be x in the middle and y at the bottom.

havent a clue how to do that buddy. as ive only created a few "clone" games in the past this is something ive never had to do before.

my animation skills are next to none, all this sprite index stuff is new to me. Most of my projects have been single sprite games and im just starting to expand upon that.

 

[teamrocketboyz]

sorry to bump but can anyone help with this.

 

[Michael McMullen]

You might have to post some code for us to see what's going on. How are you detecting collisions, are you tripled checked all the collision boxes on your sprites, and checked the origins on all of the sprites, etc...

 

[teamrocketboyz]

The only way i can explain it is with this (albeit bad) drawing done in paint. the black dots are where i have my sprites centralized at. what i guess is happening is that when i change sprite from player to roll it is creating that sprite on the players central point, and then when i go back from roll to player it is creating the players sprite at the rolls centre meaning that it is now below the ground, is there a way to make the 2nd player sprite appear higher than the roll sprites centre.

 

[Carolusclen]

I had this issue before. It has to do with bounding boxes. and you are right, it is when you change your sprites because the image center changes position but because its smaller then it was, it just drops due to gravity, but when it changes back, it doesn't compensate. The way i got around this was to make the roll images the same size as my walking ones. that way you can make the center of the image the same for all of the images.

Or you could try when you change back from a roll, just move the character up a few pixels to counter the height difference. so from walking to rolling, if the difference is 8, then when you change back to walking from a roll, move the character up by say 9 or 10.

 

[teamrocketboyz]

yeah i tried to make the roll image the same size as the walk sprite. but i want the roll to be lower so you can get through gaps, so i come to the exact same thing.

 

[Carolusclen]

you can make both images the same size and just change the collision mask of the roll, that way it will go through smaller spaces without changing the size

 

[teamrocketboyz]

its annoying because im so close to having my platform movement down, its at the pointwhere i may even remove the roll, but i like it too much.

 

[Carolusclen]

have a look at this. Its done in Game Maker 8.1 but might give you an idea. Its not complete but hope it helps. I made it ages ago https://drive.google.com/file/d/1flIvOXob1pCVuQuX-VCISEVRioZCkKEY/view?usp=sharing

 

[teamrocketboyz]

i swear if i hadnt started to create a game focused around rolling i would have taken it out by now.

 

[TheouAegis]

Let's not over simplify things. LOL

A sprite's collision mask is defined by 6 variables: x-offset, y-offset, left bounds, top bounds, right bounds, and bottom bounds. The offsets define naturally where the sprite will be placed in the room when no form of physics is applied. The offset doesn't even have to be within the sprite itself - you could have anorigin of (-32, -128) if you wanted. The game then calculates based on the offsets where each of the bounds will be in the room. Applying gravity based on a collision with the ground means you are telling the game to use the bounds to calculate a collision, then apply gravity to the y-offset. However when you change sprites, the game does not care about the bounds at all, it only cares about the offsets. So if the lower bounds are four pixels away from the origin in one sprite and 8 pixels away from the origin in the other sprite, changing sprites is going to change the bbox_bottom value. This causes the issue you're experiencing. One way around this that many Platform game programmers use is to set the origin at the feet so that the difference between the bottom bounds of any sprite will be the same. So instead of centering the origin both horizontally and vertically, only center horizontally and place it at the bottom of the sprite vertically. Do this for both your rolling sprite and your standing sprite. This way when you change sprites, bbox_bottom will not change.

 

[teamrocketboyz]

Let's not over simplify things. LOL

A sprite's collision mask is defined by 6 variables: x-offset, y-offset, left bounds, top bounds, right bounds, and bottom bounds. The offsets define naturally where the sprite will be placed in the room when no form of physics is applied. The offset doesn't even have to be within the sprite itself - you could have anorigin of (-32, -128) if you wanted. The game then calculates based on the offsets where each of the bounds will be in the room. Applying gravity based on a collision with the ground means you are telling the game to use the bounds to calculate a collision, then apply gravity to the y-offset. However when you change sprites, the game does not care about the bounds at all, it only cares about the offsets. So if the lower bounds are four pixels away from the origin in one sprite and 8 pixels away from the origin in the other sprite, changing sprites is going to change the bbox_bottom value. This causes the issue you're experiencing. One way around this that many Platform game programmers use is to set the origin at the feet so that the difference between the bottom bounds of any sprite will be the same. So instead of centering the origin both horizontally and vertically, only center horizontally and place it at the bottom of the sprite vertically. Do this for both your rolling sprite and your standing sprite. This way when you change sprites, bbox_bottom will not change.

Great solution.... the reason i didnt do this before was because i was rotating the rolling sprite on its x origin during a step event (spriteroll +=5/room_speed*60) this was rotating the sprite so the origin had to be bang in the centre if you get me.

i suppose a workaround would be to use your method and not rotate my sprite based on room speed but to instead keep the sprite upright and create a rolling animation within the sprite itself.

 

[TheouAegis]

I'd personally do that anyway just because the CPU wouldn't have to calculate the sprite rotations.