Okay, so I was asking around on how to do collision in apong like game where a ball can collide with a series of bricks stacked vertically or horizontally one after another. I was pointed to stuff that talked about AABB and box-sphere collisions. This was great, I got excited and t hen read more... I even found some code samples, made sense mostly etc.. but then I realized some of the samples I found (all of them I think) only returned a true or false if there was a collision on the AABB with a sphere, so then its up to the collision response. But I have to ask, how can I respond to a collision on a square box when I am not sure HOW the sphere collided witht he box...obviously there is more here correct? (oh and does the box-sphere change when the sphere is of course a 4x4 bitmap, so its essentially a box too even if its being drawn as a sphere, or can I just make it a sphere with a radius of 2 still?) Thanks for any info here , id like to really crack this nut (sorry if this seems remedial, my original post was in the beginners forum ...i posted here cause I thought it would be better..) Shane it should be mentioned my brick is really a simple 32x32 sprite, with a x,y and thats it. The ball is a 4x4 sprite with an x,y and a vx, vy. so i wasnt originally using vectors (but after reading some it seems I need them?)

I will have to read up on this, so if the AABB finds a collision, how do i determine what section collision happened in if the aabb code just returns true or false? thre is no spiffy way, and i have to brute force and just figure out where hte ball was, and where it was traveling too? oh and another thing, when u say:
"The normal of the reaction contains both points."
im not using normals expressly, i meant is just simple 2d sprite engine with data to hold x,y and vx, vy values... but in either case hitting a corner u are saying the ball then reflects about both axis's so it comes flying right back the direction from where it hit it... this would be great if it hits a isolated brick on the corner, but what if you have a row of bricks

[1brick][2brick][3brick][4brick][5brick]

and the ball comes flying under brick 3 to hit the bottom right corner of brick two, since its essentially like hitting brick two in 8 sector (as per ur ascii drawing) how is it smart enough to know to reflect it just about the y axis? so it he ball still bounces down left, in stead of its previous up right.

hmmmmm

Quote:Original post by Codejoy
and the ball comes flying under brick 3 to hit the bottom right corner of brick two, since its essentially like hitting brick two in 8 sector (as per ur ascii drawing) how is it smart enough to know to reflect it just about the y axis? so it he ball still bounces down left, in stead of its previous up right.

simple answer: it isnt.

if you want realistic pong collisions, you have one hell of a long road ahead. its really funny that pong is often adviced for beginners as a good first project, since getting the collision detection right is pretty damned hard even for an experienced programmer.

most pong clones i know dont handle vertex-ball collisions, things just go pretty fast and you dont notice if the collisions arnt that accurate.

a good compromise between ease and accuracy:

-imagine the grid created by your bricks.
-first, find the cell your ball starts in.
-its easy to check which border it will cross first. move it towards this border into the adjecent cell.
-if this cell is occupied, youve got a collision and a direction to reflect your ball in (back into the cell you came from)
-repeat this process until you have covered your balls speed.

quite fast, you dont miss collisions, its stable and its not too hard adapt this algo a little to solve some of the flaws its has, including the lack of vertex collisions.

Ya this problem isnt trivial. It took me by suprise when the game im making now i attempted long ago on the pc (no redoing it on a mobile device with a new game engine I ported to this device).

Ya the bricks are going to be the size of a grid...i.e. all objects (mminus the ball) will be the same width by height, just not sure what that is yet...

(the reason is cause the level creation then for this game will be really easy as it can just be a simple map I can read in).

Quote:
-its easy to check which border it will cross first. move it towards this border into the adjecent cell.
-if this cell is occupied, youve got a collision and a direction to reflect your ball in (back into the cell you came from)
-repeat this process until you have covered your balls speed.

Hmm ill have ot think about this, what do u mean repeat this process until you have covered your balls speed? do you mean look ahead that many cells for how fast hte ball is travling?
is there a name fo this type of check/collision etc.. so I can read more on it.

i think its called grid traversal or something similar.

what i mean by repeating: say you start somewhere in the centre of a box. divide the distance to a given boundary by the speed in that direction to obtain the time until you hit that boundary. the lowest positive time indicates the gridboundary youre going to cross first. however, youve only traveled a certain distance by now: most probably less than the total speed of the ball. so you need to check where youre going to end up in the next cell, or if youre going to cross another boundary.

draw some scetches on paper and i think it will soon become obvious how to exactly implement this.

hmm im having a hard time visualizing this...ill have to look on grid traversal (im afraid ill geta ton of unrelated hits though). Know of any psuedo code even that demonstrates this?

+----------+----------+----------+|##########|##########|          ||##########|##########|          |+---------3+----------+----------+|        / 2          |          ||       O  |\         |          |+----------+-1--------+----------+|          |  \       |          ||          |   o      |          |+----------+----------+----------+

consider the picture above.

o is the ball start position
1, 2 & 3 are three cell edge intersections.
O is the ball endposition
# denotes a brick

1: we calculate what cell o is in.

2: line intersection is done between the speedvector and all 4 edges.

3: point 1 is found to be the first intersection, thus we move one cell up, and conclude its empty, thus we repeat 2

4: point 2 is found, again the next cell is empty, so step 2 is done another time.

5: we again cross the top of a cell, this time into an occupied one. we stay in the same cell, but the speedvector's y component is reversed, call a function to process the correct collision events like sound and stuff, and again go to 2.

6: intersection is found again, however, we conclude based on the speedvector and the distance already traveled this frame we are not going to make it to the other side of the cell, so we calculate where we do end up and store this for use in drawing and the start of the next collision update.

Quote:Original post by Charles B
And what if the bricks are moving ? :)

very simple: it wouldnt work at all.

maybe the physics system we have in mind wouldnt be able to handle stacking, but atleast it would enable someone to write the probably first physically accurate pong clone ever, with minimal effort. including equally underestimated ball-bat collisions. :)