English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 29 October 2013, 13:30   #1
nandius_c
Fernando Cabrera

 
Join Date: Oct 2013
Location: Spain
Posts: 86
Collision detection: 2 doubts

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!
nandius_c is offline  
Old 29 October 2013, 14:24   #2
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,449
Quote:
Originally Posted by nandius_c View Post
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.


Quote:
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.
phx is offline  
Old 29 October 2013, 15:13   #3
nandius_c
Fernando Cabrera

 
Join Date: Oct 2013
Location: Spain
Posts: 86
Quote:
Originally Posted by phx View Post
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.
nandius_c is offline  
Old 29 October 2013, 15:19   #4
thomas
Registered User
thomas's Avatar
 
Join Date: Jan 2002
Location: Germany
Posts: 5,855
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.
thomas is offline  
Old 29 October 2013, 15:47   #5
nandius_c
Fernando Cabrera

 
Join Date: Oct 2013
Location: Spain
Posts: 86
Quote:
Originally Posted by thomas View Post
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!
nandius_c is offline  
Old 29 October 2013, 19:40   #6
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
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.
Mrs Beanbag is offline  
Old 30 November 2014, 00:53   #7
jimmy2x2x
Beyond Mutton
jimmy2x2x's Avatar
 
Join Date: Mar 2011
Location: North West, UK
Age: 47
Posts: 347
Quote:
Originally Posted by Mrs Beanbag View Post
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.
jimmy2x2x is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
First doubts for game developing nandius_c Coders. Asm / Hardware 21 25 October 2013 12:21
Is there a Pacmania with sprite-collision disabled? Predseda request.Other 3 30 January 2012 17:10
some doubts on the rom (kickstart) management in rommgr.cpp pucci support.WinUAE 2 11 September 2011 14:42
what games need 'full' collision level ? kirk support.WinUAE 25 07 February 2010 02:01
Slamtilt and RTC collision Predseda support.Games 5 22 August 2009 22:28

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 00:56.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.06964 seconds with 13 queries