This system has a 'sprite' engine that paints pixel information into a bit mapped screen. While the hardware does not actually manipulate individual sprites, the software 'sees' the hardware as a sprite system. The software may also directly read or write the bit mapped screen. While sprites are being painted, each pixel can be checked for collision with a previously painted sprite.
The 'E' error will cause the pen number 'E' to be non-collideable and therefore not clear the collision buffer. If you use a background sprite to clear the collision buffer, be aware that 'E' will not clear its respective pixel.
The 'E' error will cause the pen number 'E' to be non-collideable and therefore not react with the collision buffer. If you use an exclusive or sprite, be aware that 'E' will not collide with its respective pixel.
|Shadow||Boundary Shadow||Normal||Boundary||Background-Shadow||Background-No Collision||Non-Collideable||Exclusive-or-shadow|
|F is opaque||1||0||1||0||1||1||1||1|
|E is collideable||0||0||1||1||0||0||0||0|
|0 is opaque and collideable||0||0||1||1||0||0||0||0|
|allow collision detect||1||1||1||1||0||0||0||1|
|allow coll. buffer access||1||1||1||1||1||0||0||1|
|exclusive-or the data||0||0||0||0||0||0||0||1|
The hardware is missing an inverter in the 'shadow' generator. This causes sprite types that did not invoke shadow to now invoke it and vice versa. The only actual functionality loss is that 'exclusive or' sprites and 'background' sprites will have shadow enabled. The above table shows the NEW truth.
When using specific sizes to achieve specific effects, these offsets must be taken into account. You may also program them to any 16 bit value you desire. They are common to all sprites, so remember to set them back if you want the usual offset correction.
There is a collision buffer that is topographically identical to the video buffer. The number in each 'cell' of the collision buffer is the collision number of the sprite whose video pixel is in the corresponding 'cell' of the video buffer. A value of '0' means that there is no collideable object in this pixel (although there may be a visible image). Any other number is the collision number of the last object that was painted into that pixel. This buffer is written to by the sprite painting process. All hardware collision detection is done with the data in the collision buffer, not the data in the video buffer. This has obvious advantages and will be explained at seminars and in newsletters forever.
At the completion of the processing of each collideable sprite, the hardware writes a byte into the 'collision depository' of that sprites SCB. The contents of that byte are the result of the collision process described below. After all of the sprites are painted, each of them will have a relevant number in their collision depository. These numbers can later be read by the CPU for sprite collision detection.
In addition, the software can either do its own collision detection, or use the contents of the collision buffer for some weird collision detection algorithm. In either event, l will be mortally offended.
At the start of painting a particular sprite, a hardware register called fred is cleared to 0. In the course of painting this particular sprite, as each pixel is painted, the corresponding 'cell' in the collision buffer is read (actually done in bursts of 8 pixels). If the number read from the collision buffer cell is larger than the number currently in fred, then this larger number will be stored in fred. At the end of the processing of this particular sprite, the number in fred will be written out to the collision depository. If more than one collideable object was hit, the number in fred will be the HIGHEST of all of the collision numbers detected.
If a particular sprites collision depository value is zero, then this particular sprite did not collide with any other collideable object while it was being painted to the video buffer. This does not mean that this sprite will not be in collision with some other object that is painted later, or that it is not in visual collision with any object, it only means that the collideable pixels of this sprite did not overlay any collideable pixels ALREADY in the collision buffer. If, later on, a sprite is painted that collides with this sprite, then that later sprite will register the collision.
If a particular sprites collision depository value is non-zero, then this particular sprite collided with a collideable object that ALREADY existed in the collision buffer. The number found in the collision depository is the collision number of the object that was hit. It is hoped that the software will assign collision numbers in a meaningful fashion. My guess at a meaningful assignment is that the numbers will be assigned in visual depth order so that hardware detected collisions will be representative of visually noticed collisions.
These bits override all other collision settings, and will disable all collision activity for either the current sprite (when set in 'SPRCOLL') or for all sprites (when set in 'SPRSYS').
Number of bytes -| |------ First Element in list | | V V (1) 8 bits of control (SPRCTLO) (1) 8 bits of control (SCBCTL1) (1) 4 bits of control (SPRCOLL) (2) 16 bits of pointer to next sprite SCB (0 last SCB) (2) 16 bits of address of start of Sprite Data (2) 16 bits of starting H Pos (2) 16 bits of starting V Pos (2) 16 bits of H size bits (2) 16 bits of V size bits (2) 16 bits of stretch value (2) 16 bits of tilt value (8) 64 bits of pen palette The position of this element is arbitrary (1) 4 bits of collision depository but must be fixed in any particular game These are some (1) 8 bits of Identification Number possible additional (1) 8 bits of Z depth elements in the SCB. (2) 16 bits of pointer to previous sprite SCB (0 = first SCB) These and any others will be ignored by the hardware.
The 8 bytes of pen palette are treated by the hardware as a separate block of data from the previous group of bytes in the SCB. This means that the reloadability of some of the previous bytes does not affect the reusability of the pen palette. In addition, this means that when some of the bytes are not reloaded, the length of the SCB will be smaller by the number of bytes not used. If I have said this in a confusing manner, then I have.
Well, I finally found the bug that required a pad byte of 0 at the end of each scan line of data. But, It is actually 2 bugs. I have fixed one of them, but the other requires an extensive change. Too bad, I am out of time. Therefore:
There is a bug in the hardware that requires that the last meaningful bit of the data packet at the end of a scan line does not occur in the last bit of a byte (bit 0). This means that the data packet creation process must check for this case, and if found, must pad this data packet with a byte of all 0s. Don't forget to adjust the offset to include this pad byte. Since this will only happen in 1/8 of the scan lines, it is not enough overhead to force me to try to fix the bug. Sorry.
A data Packet header of '00000' is used as an additional detector of the end of the line of sprite data. This is normally used as the tiller in the last byte of a line of data, but it can be located anywhere in the data line, not just the last byte. Note that this would ordinarily decode to a packed packet of 1 pixel. Please use a literal packet of 1 pixel when the imagery calls for such an event. In addition, this special header is used when a scan line with no pixels is desired. You must use an offset of 2 with a data byte of all 0, since an offset of 1 will cause a change of painting direction.
oops, may have a bug, more later on the truth of '00000'
In a totally literal sprite, there is no pixel count. Source data is converted to pixels until it runs out of bytes in that line of sprite data. The odd bits that may be left over at the end of the last byte will be painted. The special data packet of '00000' is not recognized in a totally literal sprite.
The picture is:
LEFT RIGHT address 0 address 1 address 2 pix0 pix1 pix2 pix3 pix4 pix5 Bits 7654 3210 7654 3210 7654 3210
This order also applies to the pen index palette in the SCB. The pen number referenced by PIN 0 (Pen index Number) is in the UPPER nybble of the '01' byte.
All of the operations are pipe-tlined and operate in an interleaved fashion that reduces bottlenecks and results in almost the highest system performance possible.
The initialization for the purpose of painting sprites is listed below. The order that the registers are initialized is not important as long as ALL of them are initialized to a legitimate value before the sprite engine is turned on.
All of these values can be changed during the course of operation as long as all of them remain legitimate.
Initialization steps for sprite painting:
When you are ready to start the sprite engine, the following steps are required:
Writing a 01 or 05 to SPRGO sets the 'SPRITESEN' flip flop which causes the sprite engine to start its operation. When the engine finishes processing the sprite list, or if it has been requested to stop at the end of the current sprite, or if it has been forced off by writing a 00 to SPRGO, the SPRITESEN flip flop will be reset. This engine starts only from its beginning. It can not be stopped and restarted from its stopped point. Stopping the engine does not affect the contents of any of the other registers.
SUZYBUSEN contains the bit that allows Suzys access to the bus. It does not affect the internal operation of the sprite engine until such time that the sprite engine needs the RAM bus. Then the engine will wait until it gets the bus before continuing its processing. It is suspected that in ordinary sprite engine use, this bit will be set once and then left on. This bit can be used to pause the sprite engine. The 'unsafe' condition of the internal registers is not directly affected by this bit.
I need to think about how to use it.