Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!web-2h.berkeley.edu!labc-4db
From: labc-4db@web-2h.berkeley.edu (Greg Burrell)
Newsgroups: comp.sys.cbm
Subject: Re: Sprite Collision detection in M/L on the Commodore 64. Or: HELP!
Message-ID: <21619@agate.BERKELEY.EDU>
Date: 14 Mar 89 20:33:02 GMT
References: <5103@garfield.MUN.EDU>
Sender: usenet@agate.BERKELEY.EDU
Distribution: na
Organization: University of California, Berkeley
Lines: 54

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