[comp.sys.cbm] Sprite Collision detection in M/L on the Commodore 64. Or: HELP!

sean1@garfield.MUN.EDU (Sean Huxter) (03/14/89)

I am an experienced programmer in BASIC on the 64 and 128. I own a 128 with
1571, 1581, 1750 REU and am an avid user of GEOS.

I have always wanted to program for GEOS, but unfortunately, this can't be done
in BASIC. So I was forced to delve into M/L which is tedious.

Using geoProgrammer made it easier, and having both Alex Boyce's and Berkeley's
Programmers' Reference Guides helped. I discovered how to extend GEOS's main
loop so I could write a program that didn't rely entirely on events.

Now, the point of this posting is that I invented a rather simple game which
requires detection of collision between a sprite and the background and 
another sprite.

I have done this kind of programming in BASIC (both 2.0 and 7.0) many times,
but the routine I wrote in M/L will not work.

Here is what my routine looks like, basically:


start:  CmbBI $D01F,0     ; a macro for comparing the contents of
                          ; $D01F, the background collision register, with 0.
        bne Collision
		rts
Collision:
	   ; code here to reset the pointer to beginning, and make beep.

Now, my problem is that the collision register never seems to be anything but
zero, which seems wrong, since I can move the sprite (which is sprite #0, the
GEOS pointer) over graphics and nothing happens.

The routine has an rts since it is called from the GEOS MainLoop every time
MainLoop executes. The code is pointed to by appMain. I have successfully
placed other pieces of code in this place which executes perfectly each
MainLoop, but this doesn't work.

My question to anyone out there with M/L experience is: Why does this not
detect the collision when it clearly happens?

Does GEOS clear the collision register each MainLoop?  Am I programming it
incorrectly?

Or, more succinctly:  HELP!!!!


          /|
         / /       //   Sean Huxter   |UUCP: {utai,utai,
    ____/_/__ __  | |   P.O. Box 366  |    watmath}!garfield!sean1
 -=<_________|__|=|<<   Springdale    |INTERNET: sean1@garfield.mun.edu
        \ \       | |   NF, Canada    |
         \ \       \\   A0J 1T0       | "THUNDERBIRDS are GO!"
          \|
-- 
"And remember, Evil will always prevail because Good is dumb!" - Dark Helmet
"Smoke 'em if ya got 'em." - Dark Helmet / Elliot Ness / Colonel Hogan / 
                Judge Harry Stone / Christine Sullivan, public defender.

labc-4db@web-2h.berkeley.edu (Greg Burrell) (03/15/89)

In article <5103@garfield.MUN.EDU> sean1@garfield.MUN.EDU (Sean Huxter) writes:
>
>Now, the point of this posting is that I invented a rather simple game which
>requires detection of collision between a sprite and the background and 
>another sprite.
>
>Here is what my routine looks like, basically:
>
>start:  CmbBI $D01F,0     ; a macro for comparing the contents of
>                          ; $D01F, the background collision register, with 0.
>        bne Collision
>		rts
>Collision:
>	   ; code here to reset the pointer to beginning, and make beep.
>
>Now, my problem is that the collision register never seems to be anything but
>zero, which seems wrong, since I can move the sprite (which is sprite #0, the
>GEOS pointer) over graphics and nothing happens.
>
>The routine has an rts since it is called from the GEOS MainLoop every time
>MainLoop executes. The code is pointed to by appMain. I have successfully
>placed other pieces of code in this place which executes perfectly each
>MainLoop, but this doesn't work.
>
>My question to anyone out there with M/L experience is: Why does this not
>detect the collision when it clearly happens?


Hi Sean,
	Regarding the above mentioned problem, I will assume that you 
are setting things up correctly and that the above would work if it
were done in ML outside of GEOS. (Maybe you could try doing this in
a small test program outside of GEOS just to see if it works okay.)

	Although I just recently started programming under GEOS, I
have read the BSW book carefully. (All those spelling, formatting, and
example code errors are annoying!) I think the GEOS kernel banks out
the video chip in order to use the RAM underneath. When I wanted to
go to multicolor high-resolution I found it necessary to do:
	
	jsr 	init-for-io
	;; 	turn on multicolor
		...
	jsr 	done-with-io

This will turn off all interrupts and bank in the video and ROM chips.
Interrupts must be turned off because the GEOS kernel in RAM gets 
hidden when the chips are banked in. Perhaps this could be done
much easier by storing the correct value in address $01, but then you
would also have to stop all interrupts. 

	I don't know if this will work, but maybe its worth a shot.

			-Greg Burrell