Project Status: Working Demo, and More!

The renderer support classes and the basic physics engine are up and running! Check it out!
Current Demo <-Download now!
Move the little block around with the arrow keys. It can hop around and run up and down slopes.
The larger block follows your mouse. This was just a proof-of-concept to test the inversion. The little block can’t phase through the big one yet, but he can climb on it.
As a side note here’s an early draft of the level editor. It still needs a bit of fleshing out, but so far it’s the design that I’m going to be aiming for.

So anyway, let’s talk a little about how the engine currently works:
First, the level contains chunks of data called Masses, which contain a list of points that form a polygon. These polygons represent the simplest form of objects in the level. Mostly, they just  form walls and floors, but all that changes with the use of Actions. Actions are operations that can be performed on a Mass, things like rotating, translating, etc. These Actions are spawned by triggers that you attach to different inputs. For example, when the DOWN_KEY is pressed, the translate action is invoked on the polygon that represents the player character (the little one, in this case). It moves, and life goes on.  Once the timeline is completed, Actions will be able to spawn based on time triggers.
The majority of movement is smoothed out by looping through large movements using little ones. This way, if I translate 70 pixels in one direction, the Action will use a series of small translations, and if it hits a wall at say, 20 pixels in that direction, the remaining translations are cancelled. This prevents the player from clipping through things, and it results in a smooth look if you repaint after every couple sub movements.
The inversion works by rendering every poly with an alpha of 99%. When two surfaces overlap, they form a color darker than the default surface. Our eyes really can’t see the difference, but when the pixels are scanned, the extra dark ones are replaced with white pixels. The process of scanning for pixels to invert is sped up by keeping a list of regions that are likely to feature overlapping Masses. The rest of the level is left alone as those regions are scanned. I’m currently scouting for a simpler/faster algorithm to handle this, as it is too slow to be used with larger screen regions.
The next feature to be implemented is per-pixel collisions (rather than the current polygon-bounds collision). This will allow the player to walk through inverted sections of screen. Arguably the most essential of all the features!