Commodore‎ > ‎BASIC‎ > ‎Keywords‎ > ‎


Abbreviation Token (hex) Version(s) Classification
BUMP B{Shift+U} CE 03 7.0 Function

BUMP ( videoType )
Parameters Type Legal Value(s) Default Value Note(s)
videoType Numeric
  1. Sprite-sprite collision
  2. Sprite-foreground collison
Returns Type Value(s) Note(s)
collisions Integer*
0 to 255
Each bit corresponds to one of eight sprites.
Return the sprite(s) (as bit values) involved in a videoType "collision".
The BUMP function returns a value which is the bit-wise OR of all sprites involved in all "collsions" of the specified videoType that have occured since the last (identical) BUMP command/statemet.  It is used to check for sprite "collisions"; there are two types:
  1. Type 1 (sprite-sprite collision), is hopefully obvious: when any of the "visible" (non-transparent) pixels of a sprite occupy the same screen location (coordinate) as any "visible" pixels of another sprite.  Note however that sprite-sprite collisions may occur off-screen ("under" the border).
  2. Type 2 (sprite-foreground collision) is also pretty obvious in text mode: whenever a "visible" sprite pixel appears at a screen location that has a non-background (foreground) pixel (any of the "lit" pixels that make a character).  In high-res bitmap mode, any pixel with a 1 bit value is considered foreground; this is pretty obvious if you use the same colors on the whole bitmap, but if you start switching foreground and background colors it might be hard to tell by looking if a pixel is 1 or 0; you can use the RDOT function if you need to check a pixel at a specific location.  In multi-color bitmap mode, the background is pretty obvious because it is shared over the full screen.  However, of the other 3 bitmap color sources, only source 2 and 3 are considered foreground; color source 1 in multi-color bitmap is considered background by sprites; thus pixels set to 0 or 1 are ignored, and pixels set to 2 or 3 will trigger a collision with a sprite (again, you can use RDOT if you want to check a pixel).
The value returned, collisions, is a bit-wise OR of all sprites involved.  Note that multiplie "collisions" may be recorded by BASIC before your program has the chance to read the BUMP value.  So, a "collsion" involving sprite 1 will have bit 0 (1-1) set; a "collision" involving sprite 2 will have bit 1 (2-1) set; a "collision" involving sprite 3 will have bit 2 (3-1) set, and so on...  BUMP will return all collisions that have occured since the last call to BUMP (of the same videoType).  So for example, if sprites 1 and 2 "collide" in one frame of video, then BUMP(1) will have a value of 21-1 + 22-1 = 20 + 21 = 1 + 2 = 3.  If another collision occurs before you read BUMP, the bit values of the involved sprites will be OR'ed with the previous BUMP value.  So (to continue the previous example), a "collision" of sprites 2 and 3, will OR the BUMP(1) value with sprite 3 ( 2); thus reading BUMP(1) would return 21-1 + 22-1 (previous bits) + 23-1 (new value) = 20 + 21 + 22 = 1 + 2 + 3 = 7 in this compound example
It is important to realize that BUMP does not tell you which pixel in a sprite(s) caused the "collision".  Also important is that BUMP will report all "collisions" that have occured (since the last read of the corresponding vType)... so if sprites 1 and 2 have collided, and also sprite 2 and 3 have collided, then BUMP will return 7 (1 + 2 + 3), but this does not neccessarily mean that sprites 1 and 3 have collided.  Sorry if that doesn't make much; I guess you need to play with BASIC in order to understand what I'm talking about...
BUMP may be used any time, but it is often used in COLLISION routines (so-called interrupt routines).
If vType is ommited, or is an invalid expression, SYNTAX ERROR is generated.  If vType is not numeric, TYPE MISMATCH ERROR occurs.  If vType is floating-point, it will (effectively) be converted with INT.  If the (converted) vType is not legal (see table above), then ILLEGAL QUANTITY ERROR is generated.

0 REM setup -- create sprite 1
10 GRAPHIC 1,1           : REM clear hi-res bitmap
20 CHAR 1,0,0,"*"        : REM draw a * at the top-left of screen
30 SSHAPE S$,0,0,23,50   : REM save sprite-sized area of bitmap (includes *)
40 SPRSAV S$,1           : REM copy the shape (S$) into sprite #1
45 REM main program
50 GRAPHIC 0,1: PRINT"!" : REM clear text screen, write character at top-left
60 MOVSPR 1,24,50        : REM position sprite over character
70 SPRITE 1,1            : REM display sprite 1
80 COLLISION 2,100       : REM set interrupt routine for sprite-foreground
90 DO: SLEEP 1: LOOP     : REM wait forever...
95 REM sprite-foreground interrupt routine
100 PRINT BUMP(2)        : REM display BUMP sprite-foreground value
110 MOVSPR 1,200,50      : REM re-position sprite to negate future interrupts
120 RETURN               : REM resume main program
!                        note a delay of 1 second
1                        note a delay of 1 second
1                        note a delay of 1 second
0                        the program now waits forever...

  Compare With  
  See Also  


© H2Obsession, 2014