Priorities and Collision Detection ---------------------------------- Commodore doesn`t like to admit it, but the Amiga was designed as a games machine. It doesn`t go down to well with the business community that the Amiga`a custom chips were built to work out with great accuracy whether or not your tri-nucleon pulse meson beam has just knocked out another invading hoard of alien mutants. Custom hardware is the key to allowing the Amiga to multi-task, something which the competition in the business market still can`t get working efficiently. The Amiga`s custom chips contain special circuitry to detect collisions between objects on the screen. These objects can be either sprites or playfields. The Amiga has eight sprites - four in overscan mode - and either one playfield containing upto six bitplanes or two playfields in dual playfield mode containing upto three bitplanes each. If you have set up a display consisting of several playfields and sprites you have to tell the system in which order you want to display them - whether you want the sprites infront of the playfield, behind the playfield or in between two in dual playfield mode. This is done by setting the video priorities in the BPLCON2 register ($dff104). Sprites have a fixed priority relative to each other. If all eight sprites are set to overlap, you will see that sprite 0 appears to be on top and sprite seven at the bottom - that is, it has the lowest priority. You cannot change the priority of the sprites relative to each other. In dual playfield mode, playfiend one will appear above playfield two. This can be reversed by setting bit six of BPLCPON2. The playfield priorities are set relative to the sprites. Each playfield is allocated a number from one to four for one of the five possible settings. VALUE PRIORITY ----- -------- 000 Playfield above all sprites 001 Sprites 0 and 1 above playfield, others below 010 Sprites 0 to 3 abobe playfield, 4 to 7 below 011 Sprites 0 to 5 above playfield, 6 and 7 below 100 All sprites above playfield This value is put into the corresponding bits of BPLCON2. Bits 0 to 2 called PF1P0 to PF1P2, are set for the first playfield and bits 3 to 5, PF2P0 to PF2P2, are set for the second playfield. For example, if you wanted a dual playfield screen with sprites 0 and 1 on top, then playfield two, then sprites 2 and 3, then playfield 1 and finally sprites 4 to 7, you would set it up like this: Playfield 2 above playfield 1, so set bit 6, sprites 0 and 1 above playfield 2, so set PF2P0-2 to 001. Sprites 0, 1, 2 and 3 above playfield 1, so set PF1P0-2 to 010. Consequently the correct value to set BPLCON2 to would be - taking all the bits from the above to form a binary number - %1001010, or $4a in hex. However the playfield priority is taken from bit six and can look a little strange if, for example, in the above example we set it so playfield one appears above playfield two. This would mean that sprites 2 and 3 would appear above playfield one but below playfield two, but playfield one would appear above playfield two. Think about it. Sounds strange? Not as strange as it looks. Once you have your priorities right you can check for collisions betweem the sprites and playfields. When the co-processors try to display a bit from a sprite or a playfield and there is an overlap with another sprite or playfield a collsion bit is recorded in the collision register, CLXDAT. This is a read only register which is cleared to zero each time it is read. The make-up of the register is fairly complex and is further complicated by the control register CLXCON. The format of these registers is explained in the bit layouts below. All collisions between even numbered sprites and bitplanes are registered. However, the odd numbered sprites in the sprite pairs are by default not registered in collisions. for odd sprite collisions you have to set the relevant bits in CLXCON. BIT CLXDAT COMPONENTS --- ----------------- 15 Not used 14 Sprite 4/5 collision with sprite 6/7 13 Sprite 2/3 collision with sprite 6/7 12 Sprite 2/3 collision with sprite 4/5 11 Sprite 0/1 collision with sprite 6/7 10 Sprite 0/1 collision with sprite 4/5 9 Sprite 0/1 collision with sprite 2/3 8 Even bitplanes with sprite 6/7 7 Even bitplanes with sprite 4/5 6 Even bitplanes with sprite 2/3 5 Even bitplanes with sprite 0/1 4 Odd bitplanes with sprite 6/7 3 Odd bitplanes with sprite 4/5 2 Odd bitplanes with sprite 2/3 1 Odd bitplanes with sprite 9/1 0 Even bitplane to odd bitplane BIT CLXCON COMPONENTS --- ----------------- 15 Enable sprite 7 in collision tests 14 Enable sprite 5 in collision tests 13 Enable sprite 3 in collision tests 12 Enable sprite 1 in collision tests 11 Enable bitplane 6 in collision tests 10 Enable bitplane 5 in collision tests 9 Enable bitplane 4 in collision tests 8 Enable bitplane 3 in collision tests 7 Enable bitplane 2 in collision tests 6 Enable bitplane 1 in collision tests 5 Value to match for bitplane 6 4 Value to match for bitplane 5 3 Value to match for bitplane 4 2 Value to match for bitplane 3 1 Value to match for bitplane 2 0 Value to match for bitplane 1 There are two bits for each bitplane in CLXCON. One is to enable the bitplane in collision tests - so if, for example, you only to test for a collision between sprites and bitplane 2, you would only set bit seven and enable plane 2 in collision tests. This masks out unwanted bitplanes from the test. The second bit in CLXCON is for the match value. This is the bit that will actually generate a collision. For example, if you set up for only bitplane two as above, and then set the match value for bitplane 2 (bit 1) to zero, it will register a collision between sprites and gaps on the bitplane and no collision between sprites and solid areas on the the bitplanes. When several bitplanes are used you can set the match value to generate a collision with a particular colour on the screen. If you have a five bitplane, 32 colour screen you can enable the first five bitplanes and put in the match value (bits 1 to 5) of the number of the colour register you want to generate a collision with.