Collision detection: 2 doubts

[nandius_c]

Hi all,

I'm working on an Arkanoid-type game for OCS, just for learning the best techniques for every kind of task. So it's time for some doubts about collision detection . The ball is made up of 2 sprites (son it can have 16 colours) and the pad uses the other 6 (3 groups of 2). My code goes as follows:

1) Check keyboard.
2) Move pad.
3) Move ball.
4) Check collisions between
4.1) Ball and pad.
4.2) Ball and walls.
4.3) Pad and walls.

For points 4.2 and 4.3 there's no problem as I just do collision detection by software and backtrack in case of the ball or pad penetrating the walls. Problem is with point 4.1. I have collision detection ball vs pad enabled by hardware. What happens is that I move the ball in point 3 so, if it's moving more than 1 pixel per frame the sprite can penetrate a few pixels into the pad. In point 4.1 I do backtracking to push the ball back and out of the pad but it's too late as point 3 has already drawn the sprite. So you can notice that the ball "enters" the pad and goes out quickly after that. Any ideas about how this should be managed?

Another question about collision between the ball or pad and the walls. As I said, I'm doing that by software. Do you think that's the best way or should I enable collision between the sprites and the playfield? In that case I guess I should use the bits MVBPx in CLXCON register to make the collision happen only when the ball hits certain parts of the playfield (the borders in this case). This implies redesigning the image used for the playfield and, probably, the palette. Am I right?

Thanks in advance!

[phx]

Originally Posted by nandius_c

I have collision detection ball vs pad enabled by hardware. What happens is that I move the ball in point 3 so, if it's moving more than 1 pixel per frame the sprite can penetrate a few pixels into the pad. In point 4.1 I do backtracking to push the ball back and out of the pad but it's too late as point 3 has already drawn the sprite. So you can notice that the ball "enters" the pad and goes out quickly after that. Any ideas about how this should be managed?

Either do it also by software (defining collision rectangles for each object and compare their coordinates) or live with it. The sprite collision hardware requires that sprites overlay each other, otherwise no collision is detected.

Also remember that the collision is not detected before the hardware has displayed the sprites, so you have to wait until the end of the frame (or beginning of the next one), before reading CLXDAT.

Another question about collision between the ball or pad and the walls. As I said, I'm doing that by software. Do you think that's the best way

Yes. Software collision detection is better in most cases.
In games a collision detection must rarely be that precise. A player won't notice if the collision happens one pixel too early or too late.

[nandius_c]

Originally Posted by phx

A player won't notice if the collision happens one pixel too early or too late.

Thanks for your answer! Yeah, you're right. I guess that if you use hardware collision detection for a bullet and its target it really doesn't matter. Problem here is that the ball has to bounce off the pad (it doesn't vanish, like the bullet does) and you can notice it getting a little bit into the pad.

[thomas]

Perhaps you could first move the ball and then the pad so that the pad goes into the ball and not the other way round. The player might consider the ball to be elastic and the pad may deform the ball a bit during a hit.

[nandius_c]

Originally Posted by thomas

Perhaps you could first move the ball and then the pad so that the pad goes into the ball and not the other way round. The player might consider the ball to be elastic and the pad may deform the ball a bit during a hit.

That's exactly what happens, I'm sorry if I didn't give a good explanation. However, the effect is that the ball hides a little bit behind the pad instead of being elastic... Anyway that's because the video priority of the sprite is higher than that of the ball but not because of the order in which they are moved.

Thanks for your answer!

[Mrs Beanbag]

I would do this using maths - line intersections. You can treat the ball as exactly circular rather than using bounding boxes, and detect even collisions where the ball is moving so fast it would go straight through the bat between frames.

[jimmy2x2x]

Originally Posted by Mrs Beanbag

I would do this using maths - line intersections. You can treat the ball as exactly circular rather than using bounding boxes, and detect even collisions where the ball is moving so fast it would go straight through the bat between frames.

I would be really interested in seeing some pseudo or even real code for this.