HELP!!! Ground collision issues

[Ruination]

Hey guys, I came across an issue whenever I try to move an animated sprite the character sprites to the mid air sprite, as if it isnt touching the ground and at times it even starts sinking into the floor.

I am using the following code that I found in a video tutorial

//vertical collision
if place_meeting(x,y+vsp,par_block)
{
while (!place_meeting(x,y+1,par_block)) y += 1;
vsp = 0;
grounded = 1;
}
else
{
grounded = 0;
}

//horizontal collision
if place_meeting(x,y+hsp,par_block)
{
yplus = 0;
while (place_meeting(x+hsp, y-yplus,par_block) && yplus <= abs(2*hsp)) yplus += 1;
if place_meeting(x+hsp,y-yplus,par_block)
{
while (!place_meeting(x+sign(hsp),y,par_block)) x += sign(hsp);
hsp = 0;
}
else
{
y -= yplus;
}
}

any help is welcome ,

[Blyxx]

I'm not confident that I can help you, but looking at your horizontal collision stuff, there seem to be a lot of "y" and "yplus" references that I don't understand just from glancing at it. Why are there so many references to the values that affect vertical movement in the horizontal collision code? That's where I would begin trying to figure it out.

[Mr Moopsy]

Horizontal collisions and slopes:
http://www.youtube.com/watch?v=5hMujzHSso8&list=SP_pDUk-0qMnd47pdkELJEU0dJE545xX7G&index=6

Gravity and vertical collisons:
http://www.youtube.com/watch?v=v-uv_Xp8X_w&list=SP_pDUk-0qMnd47pdkELJEU0dJE545xX7G&index=3

Hope that helps :P

[Duh]

it could be the sprite colision box of your sprite. if your sprite is round and you give him a square box around him, it will look better, but if he's round with a round delimeter and at the time he hit the floor, it was a frame too late in the calculation, it's possible that he is going to sink in because he is not hitting your floor constraint. Just play with the sprite colision box.

[Mr Moopsy]

Shape actually should not matter in collisions. The common issue I see is people check for collisions when it is to late, after or during the collisions itself. Checking collisions ahead of time gives you much more control of being able to determine how you want that collision to react.

A box, a circle, a star. Whatever the shape it should not matter. If you are checking for a place meeting at a future location. It basically ensures that if any pixel of object 1 would be in object 2 it is true.

[Jared]

Here's a quick snippets I just typed up for your "y" collision.

// Collision @ y +/- 1
if (place_meeting(x, y + sign(vsp), par_block))
    {vsp= 0;}

// Collision @ y +/- vsp TO y +/- 1
if (place_meeting(x, y + vsp, par_block))
{
  if (!place_meeting(x, y + sign(vsp), par_block))
  {
    var yy = floor(vsp);

    repeat(abs(yy))
     {
       if (place_meeting(x, y + vsp, par_block))
         {vsp -= sign(vsp);}
       else
         {break;}
     }
  }
     vsp = floor(vsp);
}

// Update y position
if (!place_meeting(x, y + vsp, par_block))
    {y += vsp;}

So, let me break it down for you. The first bit under

//Collision @ y +/- 1

checks '1' pixel in either direction for a collision. If 'true', then the speed is set to '0'.

The second bit under

//Collision @ y +/- vsp TO y +/- 1

checks 'vsp' pixels in either direction for a collision. If 'false', it then checks '1' pixel in either direction for a collision. If 'false', it then uses a repeat iterator (I prefer this rather than a while as it prevents infinite 'game-crashing' loops) to loop through every possible pixel between the object and 'vsp'. If there is a collision at the current 'vsp', the 'vsp' is reduced by 1. If there is no collision, then it breaks out of the loop. The vsp is then 'floored' (truncate the decimal) to fix any decimal offsets.

The last bit under

//Update y position

simply checks 'vsp' pixels in either direction for a collision. If 'false', the object's 'y' position is then updated by the 'vsp'.

-------------------------------------

Also, a MAJOR ISSUE I noticed with your horizontal movement is that you manipulate the 'y' position of the object. Horizontal movement is performed on the x-axis, so you need to check for collision along the x-axis and alter only the 'x' position. The 'y' position isn't altered in horizontal (left / right) movement.

[Mr Moopsy]

His horizontal collision was also taking into account slopes.

Also the OP has not responded in 15 days.

[Ruination]

hey guys, sorry for taking so long to respond.

because I am running out of time to get the game done since its for an assessment i opted for a dumbed down version of what i inteded to do by using the drag and drop. I do intend to make a proper version of this game in the near future but i might wait until we pick up game programing in java next trimester.