So, It's caused by the screen updating too fast? Wow. I'd assume that, if that's true, the time for the pause probably decreases. Is that right?

did you get that to compile? i think you meant clrdraw and clrdraw^r, not clrhome. also, it does work, but since the whole screen is being drawn gray, you perceive it as if the contrast had been changed darker. try this:
.GRAY
ClrHome
ClrDraw
ClrDraw^R             //clear buffers
[FFFFFFFFFFFFFFFF->Pic1      //16 F's. a black square. which we will make.. gray (:
0->X->Y                            // coordinates
Repeat getKey(15)
Pt-Change(X,Y,Pic1           // draw the black square
Pt-Change(X+8,Y,Pic1)^r    // draw a black square on the back buffer 8 pixels to the right
DispGraph^r                     // draw buffer (with black square) and draw the square on the back buffer with a checkerboard pattern
Pt-Change(X,Y,Pic1           // to create grayscale
Pt-Change(X+8,Y,Pic1)^r
X+getKey(3)-getKey(2)->X
Y+getKey(1)-getKey(4)->Y        // Movement code
End
it just makes a rectangle, one half of it is black and the other half gray so you can see the difference. and, you can move it.

basically the second set of pt-change( 's turn off the sprites so there's no left over residue from movement. i'll try to show you visually.. pardon me if this fails spectacularly. i'm just going to do this in black/white so i can use paint to show you.
1 is a black pixel. 0 is a white pixel. pretend the screen is a grid 3x3 pixels
010
111
010
for example, this would be a cross.
pretend your sprite is:
11
11
or a black rectangle. now, let's jump to the code.
after the first two pt-change('s, your little black rectangle is on the buffer. then it's displayed:
110
110
000
now look what happens without the next two pt-change's. the movement code comes. let's say the user moved the black rectangle one to the right.
101
101
000
what just happened? think about it.
what should've happen was this:
011
011
000
however, since the buffer already has this painted onto it:
110
110
000
and it's inverting the pixels at the new position:
1|10|
1|10|
000
you get...
101
101
000
with the two pt-change's after the dispgraph, it prevents this from happening since the buffer doesn't have any sprite residue left over. hopefully this made sense. and sorry for the long post i tried to be as thorough as possible

Oh, I see. Thanks!

@nemo
Was my explanation correct?

Ok, ya. Couldn't you technically use a blank ([0000000000000000]) sprite to erase it on the buffer? Or not while doing grayscale?

yes, but a sprite is 8x8, right? so if you use a blank 8x8 sprite it'll also erase anything close to the sprite on the buffer. pt-change ONLY changes the black pixels of the sprite to white, which makes it perfect to use. also, if you wanted to, you could use pt-off, which would do the same thing. pt-off clears the 8x8 area.

Actually, pt-off is Replace logic, where the 8x8 sprite replaces whatever is under it.

Drawing Sprite A...

	Over White	Over Black	Over Sprite B
Pt-On	A	Black	A OR B
Pt-Change	A	A Invert	A XOR B
Pt-Off	A	A	A

Also, xoring twice is the same as removing since (A xor B) xor B = A