   what is wrong with this code?
  im trying to determin when the player and the enemy collides. when the player jumps/fall and lands on top of the enemy, the enemy is killed otherwise if theres a collision between them, the player is killed(like in mario)however the player seems to get killed whenever he is in above the enemy(in the: 'enemy->x - enemy->x+enemy->width' zone)(so obivusly the code for comparing the x-axis is correct), however im not quite sure why the y-axis is messed up as it looks correct to me, but please take a look: this is the code im using, they return a char to determine if the player or the enemie won.Its a 2-d sidescrolling mario clone done in c++. Im using boundary rectangles for collision.[source lang = "cpp"]char checkcollision(SPRITE* player,SPRITE* enemy){ if((player->x >= enemy->x && player->x <= enemy->x+enemy->width) || //comparing x (player->x + player->width >= enemy->x && player->x+player->width <= enemy->x+enemy->width))  //comparing y  if(player->y +player->height >= enemy->y+10 && player->y +player->height < enemy->y +enemy->height/2)   return player->name; //player won  else   return enemy->name; else  return 'n';}[Edited by - MadsGustaf on August 30, 2007 11:03:34 AM]
  Ok I had a quick look at your code and dismissing the stuff like the fact we don't know which corner the xy is taken from what the magic number (10) represents and which way you jump +/- on the y axis. There may be some simple ways I can help you but I won't be able to refer to your code much.The main problem you've got is travel over time. Imagine Mario is 15 pixels above the enemy coming down from a jump. The enemy is only 10 pixels tall, so we do a collision test and we don't get a hit. We then update mario and he moves down at 15 pixels per frame so he ends up on ground. We then do a collision test but because mario is on the ground we think he ran into the enemy.Now if you know enough about the travel speeds of your game you can cheat a little so it works better. If we know the maximum amount mario can move down per frame is 3 pixels we can test whether: (This assumes the y of an object is the bottom of the object)if ( EnemyY + EnemyHeight - MaxMarioYTravel <= MarioY &&EnemyY + EnemyHeight >= MarioY )    return MarioJumpedOnEnemy;else if ( EnemyY + EnemyHeight < MarioY )    return NoHit;else    return MarioDead; ;  Because your collision detection doesn't know about the velocity of the player. It can't tell whether the player is falling or moving sideways.A creature gets killed not only when it collides, but specifically when it *falls* on top of a creature. And this second criteria is the one you're not checking.Without certain additional assumptions, you won't be able to reliably determine which event happened.Consider this:+---+|P+-+-++-| C |  +---+P = playerC = creatureWhat happened here? Did player land on top first? or did he hit sideways first? Unless you have a velocity vector, you cannot tell.Without knowing how you increment the positions of sprites, it's impossible to find a reliable solution.   ;  thanks both! you posts inspired me to the solution. what i did is checkinf if their boundary boxes overlay, if the do, i check if player is in the air, if he is(becouse he can only land on top of the enemie since he is falling) the enemie die.code:[source lang = "cpp"]char checkcollision(SPRITE* player,SPRITE* enemy){    if( player->x <= enemy->x+enemy->width &&  enemy->x <= player->x + player->width &&  player->y <= enemy->y+enemy->height && enemy->y <= player->y + player->height)  if(jump != JUMPIT && jump < 0)  return player->name;  else return enemy->name;   else  return 'n';   }sorry for not explaining proberly.   ;  Naming your entities with single letters, and returning a letter code to indicate the collision, is a bit strange. It's also error-prone: sooner or later you'll introduce an enemy that you want to name 'n', and you get screwed. Not to mention, there could be several enemies of the same type on screen at a time (and if the 'name' is supposed to be unique, you'll soon find chars insufficient).The simplest reasonable strategy would be to return a SPRITE*: that of the "winner", or NULL if no collision.Also, putting braces around your if blocks (even when there's only one statement inside) is a good idea to protect yourself from problems later. Code changes, you know. :)   ;  That still seems like it could have issues, your best solution is to have a direction vector and use that to figure out which direction your character is travelling.   ;  The problem with just checking if he is in the air is that you could be one pixel away from landing and just cross the x boundary for a collision it then looks like you should have died but instead you land on them. THIS IS NOT HOW IT HAPPENED IN MARIO ;)   ;  Or you might have just started the jump (going up!) and collide with the enemy on the side...  Now if I remember correctly, on Super Mario World you could actually kill an enemy if you were in the 1st half of the jump (going up) and hit the enemy at the right point... didn't it actually boost your jump too?  (My memory may not be serving me correctly, admittedly)  I'm willing to bet that nintendo checked for a bounding box collision, than just tested whether the bottom of the mario sprite was at, say, 3/4 of the enemy sprite's height or higher.  This probably fixed other problems such as jumping up, and an enemy jumping up and "landing" under you while you were still both going up.  Anyway these are just thoughts... it really depends how you want the collisions to be handled under these special case scenerios.CheersEDIT: Not that this actually helps solve your initial problem.  Best bet is start with the direction vector solution, and use that to calculate WHERE the collision happened (on you and on the enemy sprite), then use that to determine what happens next (depending on how you want the collisions handled once you have the *correct* information)   ;  are those mathematic vectors(i have no idea what they are, but we are supposed to learn about them this year) or vector containers(c++)? im not quite following the vector thingy you guys are talking about.   ;Quote:Original post by MadsGustafare those mathematic vectors(i have no idea what they are, but we are supposed to learn about them this year) or vector containers(c++)? im not quite following the vector thingy you guys are talking about.Mathematic vectors. An x, y pair.   