Wow, that's pretty intense. It's like Pixel Purge (also on armorgames) but IMO Pixel Purge is a little better.

I got a 500 Internal Server error...

well that's relatively easy to write a subroutine yourself, just Logically XOR every byte of the sprite with 255.

I don't know, if I were you I'd end up ripping or Portal Prelude's button sprites.

Well, the thing about tilemap collisions is that it's harder to support things like slopes and really small tiles. In a tilemap based system, you collide with tiles regardless of whether or not you chose to display them.

That's exactly what I tried! However it always detected a pixel as tragically failed. I thought I was using the wrong strategy. I guess I was right!

I still have that code commented out in grappler, so I'll tweak untill I give up or fix it.

In other news, this has been my 1000th post!

Haha this is my first ever working attempt at accurate collision detection. I have seriously tried >9001 times.

Parser's right ^

Can you explain how that works?

So I have two subroutines, MoveX and MoveY. Each of these moves the character as far as the [velocity variables] dictate, stopping the character and zeroing the [velocity variables] if there's a pixel in the way.

Basically, I have a loop set up that loops from 1 to however large the [velocity variable] is (negative values of the [velocity variable] made things a little complicated, but it wasn't too bad). Inside this loop is another loop that goes from [zero] to the [height of the sprite] minus one, doing a buttload of pxl-test commands to see if there's anything in the way. If there's anything in the way, stop the MoveX or MoveY routine, and move the character position as far as they can (up to a point) without hitting something.

It looks kinda like this: assuming X is the X_COORDINATE and D is the X_VELOCITY. Pretend that X_VELOCITY is positive (so the character moves down). Assume there's no inflation, and X_VELOCITY (D) is 3, so the character can potentially move 3 pixels in the downward direction, and this is written out in non-loop form (which is highly impractical but demonstrates the concept fairly well).

1. Look to see if there's any filled in pixels in the 8-pixel-wide row directly beneath the character (assume a rectangular character).
2. If there's none, move the character one pixel down, and repeat step 1 until you've already gone as far as you had the potential to go (You don't want to go fifteen pixels, you want to go three, because X_VELOCITY is three, and X_VELOCITY is the maximum number of pixels your character can move in a frame.
3. If there are any, stop moving the character. Return from the subroutine, get on with the rest of the game logic and whatnot.

That probably didn't make much sense. But hopefully that^^, coupled with studying the source code of my engine, will help you.