Computer Science Canada :: View topic - [tutorial] Basic Collision Detection

Computer Science Canada

[tutorial] Basic Collision Detection

Author:

DanShadow [ Fri Feb 06, 2004 2:31 pm ]

Post subject:

[tutorial] Basic Collision Detection

Collision detection is done through a large amount of ways...arrays, whatdotcolor,lines,and other assorted things. Ill try to explain a couple of these just so some of the newer people can do stuff with it or something.
The Bouncing Ball

code:

%Program: The Bouncing Ball
%Description: This program draws a
%--ball that bounces of the top,bottom
%--and sides of the program screen.
var ballx,bally,xmod,ymod:int:=200
xmod:=1
ymod:=1
loop
setscreen("offscreenonly")
View.Update
Draw.FillBox(0,0,maxx,maxy,0)
Draw.FillOval(ballx,bally,10,10,12)
ballx+=xmod
bally+=ymod
if ballx+10>=maxx then
xmod:=-1
elsif ballx-10<=0 then
xmod:=1
end if
if bally+10>=maxy then
ymod:=-1
elsif bally-10<=0 then
ymod:=1
end if
delay(200)
end loop

Whatdotcolor Collision

code:

%Program: The Bouncing Ball
%Description: This program draws a
%--ball that bounces of the top,bottom
%--and sides of the program screen
%--and a black box
var ballx,bally,xmod,ymod:int:=200
xmod:=1
ymod:=1
loop
setscreen("offscreenonly")
View.Update
Draw.FillBox(0,0,maxx,maxy,0)
Draw.FillBox(300,300,500,200,255)
Draw.FillOval(ballx,bally,10,10,12)
ballx+=xmod
bally+=ymod
if ballx+10>=maxx or whatdotcolor(ballx+11,bally)=255 then
xmod:=-1
elsif ballx-10<=0 or whatdotcolor(ballx-11,bally)=255 then
xmod:=1
end if
if bally+10>=maxy or whatdotcolor(ballx,bally+11)=255 then
ymod:=-1
elsif bally-10<=0 or whatdotcolor(ballx,bally-11)=255 then
ymod:=1
end if
delay(200)
end loop

Woops...I g2g. Ill update this later.

Author:	recneps [ Fri Feb 06, 2004 4:45 pm ]
Post subject:
I think we have enough collision detection tutorials. maybe you could delete the old stuff and just call it "Whatdotcolour Collision Detection" Just a suggestion, we have like 3 others....

Author:

Cervantes [ Fri Feb 06, 2004 4:46 pm ]

Post subject:

the whatdotcolour one is defective

it goes straight through the box.

code:

%Program: The Bouncing Ball
%Description: This program draws a
%--ball that bounces of the top,bottom
%--and sides of the program screen
%--and a black box
setscreen ("offscreenonly")
var ballx, bally, xmod, ymod : int
ballx := 200
bally := 170
xmod := 1
ymod := 1
loop
Draw.FillBox (0, 0, maxx, maxy, 0)
Draw.FillBox (300, 350, 500, 200, 1)
Draw.FillOval (ballx, bally, 10, 10, 12)
ballx += xmod
bally += ymod
if ballx >= maxx then
xmod := -xmod
elsif ballx <= 0 then
xmod := -xmod
end if
if bally >= maxy then
ymod := -ymod
elsif bally <= 0 then
ymod := -ymod
end if
if whatdotcolour (ballx + 11, bally) = 1 or whatdotcolour (ballx - 11, bally) = 1 then
xmod := -xmod
end if
if whatdotcolour (ballx, bally + 11) = 1 or whatdotcolour (ballx, bally - 11) = 1 then
ymod := -ymod
end if
View.Update
delay (2)
end loop

^^^^^ = my version of your code

Did it go through for anyone else? seems wierd... I was playing around and when I set the box and whatdotcolour = anything above 230 it didn't work... Thinking

anyone know why? Confused

other than that it should be a really good tutorial.

Author:	Delos [ Sat Feb 07, 2004 7:21 pm ]
Post subject:
Quite simple. Whatdotcolour looks at the colour of the specified pixel. It will consider it to be the closest value that it can figure from the 256 colours Turing uses. Colours such ass 255 code for black-like colours. Whatdotcolour simply looks at it, and says "Well, this sorta looks like black, so hey, it is." In other words, if one were to change the whatdotcolour line from Dan's programme from 'whatdotcolour (x, y, 255)' to 'whatdotcolour (x, y, 7)'...it would work properly. Because of this little bug...there are quite a few colours that cease to exist whence one begins to use whatdotcolour - i.e. all of the initial 15 or so colours will be selected instead of a higher number. That would explain why after 230 or so, whatdotcolour stops returning correct values. You want to know more? Read on. The first few colours in Turing are created using very high and very rigid RGB values. That is, all red and nothing else...etc etc. Colours 16-about 31 are greyscales...but the number of grey shades does not correspond very well with all the other colours. Colours 31 or so onwards are what I like to refer to as the 'Well Behaved' colours. Their RGB values are much more flexible, and sensible! I know, Turing + sensible usually = syntax error...but in this case it is quite nice. This obviously brings up problems. Since the rate at which the RGB colours increase in the 'Well Behaved' section occasionally produces values that are identical to colours 0-15 (30 too I guess), those specific numbers become redundant and inaccessible during whatdotcolour calls. Interesting eh? Why is this like this? Well, Turing started off with 16 or so colours, then 32 (in DOS the colours would flash), then in the upgrade to WinOOT, they added another 200 and something. But...the didn't do it too well. So as to avoid confusion, they left the old colours exactly as they were. IMHO, to make matters simpler they ought to have revamped the entire colour system to make it all 'Well Behaved'. For some odd reason, they must have guessed that students would much rather use colours 0-15 on a regular basis instead of using, say 32 for red (4). Makes things simpler for students? Perhaps in early stages. Makes things more difficult once you get past those early stages and move on to more advanced graphics...? I'll leave that one hanging. Incidentally, the RGB.WhatDotColour readings for colours 248-255 are identical (all are 0,0,0). It's really sad to think that in Turing 4.0.4c, the max colours attainable using RGB was 1024. Look mildly familiar? 2^10. I havn't tested 4.0.5, but I doubt it would be much different. Looks like Turing reserves only so much room for graphics...so sad... So, there you go. That is why it stopped working.

Author:	Cervantes [ Sat Feb 07, 2004 7:31 pm ]
Post subject:
wow that's really neat! how'd you figure all that out? NOTE: if you put "black" in the colour number section of the whatdotcolour and the drawfillbox then it works as well. I guess it uses colour # 16 for black, not 255

Author:	Catalyst [ Sat Feb 07, 2004 11:23 pm ]
Post subject:
dont use whatdotcolor for collision detection

Author:	Delos [ Sun Feb 08, 2004 10:44 am ]
Post subject:
That's a really good point. It really only works (sorta in a round about way) well when you have not more than 2 colours.

Author:	Cervantes [ Sun Feb 08, 2004 10:56 am ]
Post subject:
but for somethings, whatdotcolour is the only way to go. IE. your lens filter program Delos. a useless but fun program I made that bounces a bunch of lines around the screen and changes their colour whenever it bounces over another line. useless, but fun

Author:	Delos [ Sun Feb 08, 2004 11:00 am ]
Post subject:
Whatdotcolour as a command is extremely useful command as it stands. I shall not deny that. Just that it is not the best route to take when considering collision detection. I'm sure Dodge will have things to say against this though...hehehehe... Oh, and thanx for the plug!

Author:	Cervantes [ Sun Feb 08, 2004 11:10 am ]
Post subject:
collision detecting in Turing is rather poor... well, it was much worse before 4.0.5... Math.Distance and Math.DistancePointLine are really good, though I'm sure you could do both some way without the commands.. (I know you can for distance).

Author:	Delos [ Sun Feb 08, 2004 1:07 pm ]
Post subject:
Just use Pythagorean formulae. hypotenuse ^2 = adjacent ^2 + opposite ^2 and you're home and dry. The two Math. functions just do a little math calculation, round it, and return an int! Useful, but easily replicated. Hehe, reminds me of the time I replicated 'strint' without knowing it...that was back when I didn't know about it but needed to make an integral error trap...

Author:	DanShadow [ Wed Feb 11, 2004 4:07 pm ]
Post subject:
Catalyst wrote: Dont use whatdotcolor Yeah....I kind of agree....just use math of set boundaries. (But if dodge is reading, Use whatdotcolor, it is the best! nods very quickly Well, whatdotcolor can be used for pretty much everything....but math and boundaries are usually neater, more professional, and overall in most peoples opinion...better.

Author:	santabruzer [ Wed Feb 11, 2004 4:25 pm ]
Post subject:
the problem with what dot color.. is the fact that if you have a customizable program for example.. like the snake one i made.. which was crap... the food item.. if it's the same color as the sanke.. the program will exit upon you eating them.. so you have to make it very very smartly.. and plus some colours don't work, and are all recognized as black..

Author:	zylum [ Sun Feb 15, 2004 1:52 pm ]
Post subject:
why would you need collission detection for a snake game???

Author:	Delos [ Sun Feb 15, 2004 4:08 pm ]
Post subject:
When the snake collides with its food or its tail! Kinda the whole point of the game...but then everyone to their own...lol.

Author:	Cervantes [ Sun Feb 15, 2004 4:17 pm ]
Post subject:
you need collision detection for every single game well, every cool game. when's the next part of the tutoiral coming out?

Author:	shorthair [ Sun Feb 15, 2004 4:44 pm ]
Post subject:
do errors count as collision , cause i can make a game where ou ove my model around and you can go straight for about 20 minutes until it crashes , from an overflow , and its a really cool game , but not one peice of collision detection

Author:	Cervantes [ Sun Feb 15, 2004 4:50 pm ]
Post subject:
no I don't think that really counts as collision how could that game be fun?! what game is it? I honestly can't picture an entertaining game without somesort of collision.

Author:	shorthair [ Sun Feb 15, 2004 5:03 pm ]
Post subject:
Shorthair walks away with tears in his eyes as his dreams were shattered by a dirty dirty pirate , his hopes of making hte coolest game without collisions are gone

Author:	zylum [ Sun Feb 15, 2004 5:57 pm ]
Post subject:
aren't most snake games tile based? so the snake head doesnt really "collide" with the food or its tail, it just occupies the same area... so yo just check where the the head tile is occupied by another tile that isnt empty... is that considered collision detection? meh i guess it is... speaking of snake games, check out the one i made of this site... http://www.xxviii.net/blog/index.php?action=showall&page=1 (there's a link to it in the new stuff section) btw its made in flash

Author:	Maverick [ Sun Feb 15, 2004 6:17 pm ]
Post subject:
Ya I think thats how snake games normall work.

Author:	shorthair [ Sun Feb 15, 2004 7:01 pm ]
Post subject:
but there are boundaries in snake , thus there is collision detection

You can syndicate this boards posts using the file backend.php or view the topic map using sitemap.php.

Terms of Use | Privacy Policy