Well, think of it this way-- If I can do over 1000 pxl-tests in a second, then checking if I am in the kill zone will not be a problem at all.

[15:41:26]      calc84maniac    otherwise you'll have to settle with pi approximation day
[15:41:29]      hellninjas      oh yeah, i keep forgetting other countries do it different
[15:41:29]      calc84maniac    22/7
[15:41:33]      Xeda112358      22/7
[15:41:39]      BlakPilar       So my pre-calc teacher went on a whole rant today about how since pi is an arbitrary number, it should be celebrated on an arbitrary day if it is to be celebrated at all...
[15:41:41]      hellninjas      NINJA'D!!!
[15:41:41]      Xeda112358      Ninja'd >.>
[15:41:59]      calc84maniac    how is pi an arbitrary number
[15:41:59]      Xeda112358      !_! Ninja'd again
[15:42:01]      hellninjas      ninja'd again!!!
[15:42:05]      hellninjas      damnit
[15:42:07]      Xeda112358      yesssss
[15:42:13]      hellninjas      lol



I'm only part ninja

In a similar vein, you can do some soft-core SMC to speed up a routine such as pixel-testing or even turning the pixel on or off:
;===============================================================
PlotPixel:
;===============================================================
;Inputs:
;     B is the x-coordinate
;     C is the y-coordinate
;     D=Method
;        1=Test
;        2=Off
;        3=On
;     (BufPtr) points to the buffer to draw to
;Outputs:
;     BC is equal to (BufPtr)
;     DE not modified
;     HL points to the byte the pixel is drawn to
;     When using the pixel test method:
;       z means pixel off
;       nz means pixel on
;Destroys:
;     A
;===============================================================
     ld a,3Fh            ;7
     srl b \ rra         ;12    19
     srl b \ rra         ;12    31
     srl b \ rra         ;12    43
     cpl                 ;4     47
     or d                ;4     51
     rrca \ rrca         ;8     59
     ld (Method),a       ;13    72
     ld a,b              ;4     76
     ld b,0              ;7     83
     ld h,b \ ld l,c     ;4     87
     add hl,bc           ;11    98
     add hl,bc           ;11   109
     add hl,hl           ;11   120
     add hl,hl           ;11   131
     ld c,a              ;4    135
     add hl,bc           ;11   146
     ld bc,(BufPtr)      ;20   166    BufPtr points to the buffer
     add hl,bc           ;11   177
     .db $CB             ;15   192    First byte of BIT
Method:
     .db 46h             ;            second byte of the BIT instruction
     ret                 ;10   202  37 bytes


Okay, I am trying to think of what could be wrong
As for grayscale, here is what you can try:

Store pi9872 to a pointer-- this is where a 768-byte buffer is located. I'll call the pointer G, for Gray.
Now do this: Disp ^oG to set the gray buffer.

Now when you draw, you draw the gray stuff to buffer G and black to the normal buffer. To make white, you need to erase on both buffers.

You also need to be constantly updating with DispGraph for it to appear gray. To draw to the gray buffer, most drawing instructions will let you use an extra argument to point to the buffer. For example, to draw a rectangle to the gray buffer:

Lined(0,0,8,8,1,G

I hope that helps!

I also wrote the code in assembly and for things like this, the process can be really sped up. I am not sure how other languages compare.

Wow 48Hz is 8 times faster than the calc. Okay, some pseudo code...
Make a finite array of, say, 12 elements. This is the data for 6 particles. The elements are:
{X₁,Y₁,X₂,Y₂,X₃,Y₃,X₄,Y₄,X₅,Y₅,X₆,Y₆}

So loop through the particles like this:
For the first particle, get (X₁,Y₁). Test the pixel below that coordinate. If it is empty, do Pxl-Off on the original, Pxl-On to the new location and change Y₁. If it is not empty, randomly select left or right to test first. If it is empty, move there, adjusting pixel states and updating X₁. If that is not available, check the other left/right and do the same. Finally, if that isn't empty, either, do nothing.

Since the particle should not be starting on any already made pixels, it never occupies an already occupied space and so it does not delete any original contents. It only deletes itself from frame to frame. In BASIC, I did this:

{3,3,3,3,3,3→L1    ;Y-coordinates
Ans→L2              ;X-coordinates
Repeat getKey=45
For(A,1,6
L2(A→X
L1(A→Y
If pxl-Test(Ans+1,X
Then                     ;This checks left/right
2randInt(0,1)-1→B   ;B becomes 1 or -1
If pxl-Test(Y,X+B
-B→B
If not(pxl-Test(Y,X+B
Then
Pxl-Off(Y,X
X+B→L2(A
Pxl-On(Y,Ans
End
Else
Y+1→L1(A
Pxl-Off(Y,X
Pxl-On(Ans,X
End
End
End

You will see it doesn't go nearly as fast in BASIC which is why I did it in ASM >.>

The array is stored elsewhere. As long as you have a pointer to the array, you are fine The location is generally a fixed location for the duration of the program, though.