Oh I just now saw that in the OP... I will definitely have to agree with you on the slime trail...

How did you get such good grayscale??

I am running the game at 15 MHz, which helps, and also use a total of two DispGraphrr commands (one was way to slow), but I had to slow it down with a Pause (about 10) to really get it good, as the double DispGraph made the greyscale update too fast.  Honestly, it would be even better if I used interrupts, but I will mess with those later.

So is this a tile-map or pixel-perfect? Would making it pixel-perfect slow it down a lot?

For the collision? It is a mixture.  It checks to see if the tiles in a 2x2 grid surrounding the character are solid, and if they are, only checks pixels in the direction the character is accelerating
If it was completely pixel-perfect and constantly checked collision in every direction, it would be a lot slower than it is, and the greyscale would mess up more (like it does when you run into walls)

Well I am making a game, and right now it is pixel perfect. Basically right now it checks if above, below, left, and right of the player are solid, and saves it to variables. Another task (thread) checks those variables to see if it can move (The player only collides with the bottom left corner which stinks ). Is there a better, more efficient way to do this? The grayscale is not as good as yours because of the time it takes to draw all the stuff and check pixels.

If you are using acceleration, you can improve it by only checking the ways your character is moving
Ex:
If you are going down and right, only check those two directions

That should speed it up some, if not a lot

If you also switched to a tilemap system, you can figure out whether or not to even check collision (if everything around you is transparent, no collision is needed, and therefore doesn't need to be tested for).  Also, I suggest throwing an extra display routine in your program. Try to place a fair ways away from the other, but make sure the picture is still the same (as in nothing has moved)

Sure, and I will explain further:
Extra display routine - update the screen more than once per loop of the engine
By a fair ways away, I mean make sure that there is lots of time between the updates, to better the effect
And by nothing moved, I mean no sprites have been erased from the screen

And here's my example:

Game loop start:

Update the screen with the current picture
Calculate movement
Calculate Collision
Update the screen again -- nothing has changed since the last screen update
Now change your sprites, and update the tilemap, etc.

Game loop end

But there are 2 threads, not one.
And also wouldn't it have to update the screen 3 times since it is 4 lvl grayscale?

Not necessarily - sometimes that will break the greyscale even further

Basically, the way to get it perfect is just to mess around with the number of screen updates and time between updates -- I spent an hour just playing with different places for the second screen update, how long the pause in between the updates should be, and just getting everything set up nicely

That doesn't make sense. Why would it only update twice if there are 4 colors? Shouldn't it update 3 times?? Because 4 level grayscale has 3 pictures.

True, but if you updated three times per loop, it could look like nothing is happening at all if there is not a delay between the third and first update:

1st update: 001001001

2nd update:010010010

3rd update:100100100
1st update: 001001001

With two updates per loop, even if the second update is close to the 1st, it will always change every loop of the engine:

1st update: 001001001
2nd update:010010010
1st update: 100100100

It really just depends on how fast/slow your engine is... If you are still having problems, I would suggest making a new thread so that other people can help you, because I've seen people make 4 scale even better than me