🚀 go-pugleaf

Greetings,

	I personally believe that the both the sparse array approach & quad
	tree method for programming collision detection in arcade type
	games is inappropriate - mainly because there are much faster
	methods
        available. While its always a speed/memory tradeoff in
	arcade type games, you really should endeavour to
	get everything running around 50 frames a second thereby
	allowing smooth animation etc. I really hate jerky scrolls and
	jerky character movement. Having said that this is the way I
	would approach the collision detection problem.

	(1)	For aliens on the screen - say in a shoot em up - unless
	your'e lucky enough to be programming a machine with powerful
	hardware sprites and collision detection, create rectangular 
	boundaries around the aliens and just test for overlap. Even
	the the boundaries around the aliens are square during the heat
	of action (and depending on the size and shape of aliens) most
	players won't notice that a rectangular boundary, rather than a
	pixel perfect collision has occurred.

	(2) Background are a little more complex. Every one
	whose created a scrolling or large playfield for a game will know
	that you don't store a contiguous huge bitmap for the playfield.
	Rather the playfield is built up from a set of , say , 16*16 blocks
	that can be reused over and over. Under this method one ends up with
	two main files:

		(a)	The bitmap graphic data describing the 16*16 blocks

		(b)	A gamefield data file describing which block are
		placed where on the screen. The gamefield file contains
		numbers that reference particular blocks.

		One could now have a third file that contains tag info
		on each block in the gamefield data file. Each number in
		this file references the block numbers in the gamefield data
		file. However these numbers may be constructed as follows:

			If bit 0 of this byte is set then the player
			can't walk through this block.

			if bit 1 of this block is set the player loses
			energy, etc, etc.

			Now when the player is on the screen you convert
			his position to a block position equivalent and
			offset this position into the third file just
			discussed, test the bits and then take the
			appropriate action, e.g. stop moving or decrement
			energy. Of course there are various variations on
			this setup, but it is fast. You may also which to
			increase the resolution on the blocks in the third
			file, i.e. down to each fourth pixel set. Have you
			ever noticed in some games, e.g. Turrican that when
			you move your player to the edge of a platform he
			can at the edge be standing on thin air. This is
			because the tag information is only accurate to
			a 16*16 block or what ever. This process may also
			sound
			painstaking for large playfields but if you write a
			map editor or something the process is easily
			(fairly) automated.


			See ya,

					Cully