COLLISIONS
----------

Part of what could be said about detecting collisions 
when writing games can be understood by reading the 
following interchange:

.......................................................
??? wrote:

  I want to know a good way to implement 2d sprite 
collision detection between main character sprite and 
tile world. My game is 2D, main character 16x16, tiles 
also has size 16x16 pixels. How to detect, for example, 
that main character stands on the floor (to prevent 
falling down) , or to detect character-walls detection?


Part of the reply:
It would much depend on the characteristics of your 
floor.  When I've done it in the past I haven't 
bit-checked for collisions of sprites vs "tile" 
(background).  You can save a great deal of comparison 
time if you simply do a mathematical range comparison, 
according that is to the way your floor is laid out..



He continues:
  Currently i do following to check collision against the 
walls:
  I pick 4 sprite corners i.e  [x,y], [x+15, y], [x, 
y+15], [x+15, y+15], next i get each tile code that 
belongs to each corner:
  tilecode = tilemap[y>>4][x>>4], and next i check that 
each corner is not collide with any non-empty tile.

reply:
Again, you could save all that if you avoid bit collision 
detection.  As I understand it, I save bit 
collision detections for what I call "active" situations.  
By "active" I mean collisions that may affect my sprites 
visually or dinamically, not their physics.  An example 
of "passiveness" would be bumping 
into a wall.  An example of "activeness" could be my 
sprite walking over a floor of nails, or touching 
something explosive, or plunging into a tub of acid, you 
get the idea..




He continues:
  To check collision with floor,  I pick two points 1-
pixel under sprite and check that this points not in air, 
otherwice I move my character down.

  Is that correct? Please suggest me other (fastest?) 
techniques to do sprite vs tilemap collision detection. 
What if tilemap is moving freely (scrolled x-y)?

Reply:
If you consider what a collision is you'll realize that 
it happens when particles coincide with each other in 
"motionally conflicting" ways.  What that means is that 
on screen, the only way to get an honest-to-God collision 
is to have two pixels occupying "the same space".

If you used that criteria to decide wether to move your 
sprite up,down or in any direction, you realize that only 
when a collision has taken place you will act in such a 
way.  But if you consider "real" collisions, it doesn't 
really seem to happen that way:  Before two points occupy 
the same space, a lot of energy gets involved.

What that means is that when you bump into something, 
although part of you interacts with whatever you bump 
into atomically, most of your mass stays out of bounds 
and you feel a force that keeps you from occupying the 
space currently occupied by whatever you bump into.  At 
least that's what physicists say.

That would translate into computers as "feeling the 
force" BEFORE actually colliding.  I would suggest then 
to look ahead AT LEAST one pixel in the direction of your 
movement before displacing.  That's the way I did it and 
it works just fine.

If you consider, for example, a sprite character walking 
over some "tile" floor from left to right, and at this 
very moment the sprite character is "standing on the 
floor" (his weight rests on the floor), then to move him 
or her one pixel to the right you would consider the 
vectors of movement involved, and then you could take 
action.  From there on it can get as complicated as you 
need it.

One simple way to do it would be to set the sprite 
animation as in motion, check before moving him to the 
right when the time is right.  If he's about to "bump" 
into something (an obstacle) prevent him from advancing.  
How can you tell the difference between the floor and any 
obstacle, even when it's part of the same floor (i.e., a 
wall or a lump in the terrain)?  It's simple.  His motion 
vector gives you his direction.  If there's anything in 
that direction about to occupy the same space he would 
like to occupy by moving that pixel to the right, even if 
it's a single pixel,  then you know he shouldn't move 
that way.  When you stop him from moving, PLEASE make him 
respond elastically to the "bump".  That means, don't 
just stop his motion counter.  Give him a little elastic 
bounce, as it would happen in 
everyday physics.  It's a little trouble to program, but 
the difference when your game is played is cosmic.

If your tilemap is moving freely then how you do it will 
vary depending on the particular situation of your game 
and on the angle of your view (your viewpoint), but the 
principles should remain basically  the same.  It's 
physics after all isn't it?
.......................................................