Ya, I've noticed that too. I just always thought it was the emulator trying to mimic the screen bounds.

Yeah and its looking very nice!  I'm really eager to see the movement code you have come up with ^^

Mmmm yeah i didnt mean code, i just wanted some eye candy Cant wait!

Wow, boayancy?  Thats going to be epic ^^ Its like an entire physics library

Compression uses BuilderBoy's method, which compresses tilemaps down to half their size, only with some added features.  For example, in order to keep with compressed tilemaps and to still support a large number of tiles, I have a tile set system.  For example, you shouldn't need more than 16 tiles per screen, but you may want more than that in general, so I have it set up so that each map can use a different set of 16 tiles, if you so wished.  His method is also quite complex, I added several helper methods that take care of common tasks that involve complex math.
The engine also uses 64 times the precision (also stolen from BuilderBoy, sorry), so that movement can be signifigantly smoother.  It uses inertia based movement, where you can request to move an object.  What this means is that the physics engine works its magic in the background, updating objects smoothly with all the calculations, and you can request a change.  This lets the physics engine remain streamlined in the background and gives the programmer the ability to change a little bit, while letting the engine apply the change how it sees fit.  That way, you (as a programmer) don't have to worry about the differences in friction and such between different situations.
The graphics and the physics are closely tied together.  The engine uses a list of objects that it is keeping track of, and the graphics engine reads from this list and uses it to draw objects as well.
Another amazing thing about the game engine is its efficiency.  The game engine actually runs way too fast, and it is forced to pace itself.  The good thing is, however, that it does so dynamically to avoid getting too slow.  What this means is that if it starts to get stressed, and has a lot of object being updated at the same time, it reduces the amount it inhibits itself to allow the updates to be seamless, regardless of the number of on-screen objects.  It also speeds itself up on older hardware, such as the 83+ vs the 84+.

Also, I promise you this project exists, I just don't want to post half-baked screenshots just yet.  As you can tell from the above, there is some pretty complex stuff going on, I want to get it all nailed down before I show off before.  To be completely honest, I didn't really want to show the last screenshot for this very reason, I just saw a lot thirst for more from the community.

Wow, this sounds awesome!  Good luck on it!