Hallelujah!

(Grab some popcorn, this is a long 'un, but I've provided enough pictures to keep you all entertained, I think..)

It works!  After a day and a half of coding blind (meaning I had absolutely NO idea what I was doing the past few days, basically just trying whatever ideas I could come up with and praying about them) I have succeeded in getting SOLID 2D OBJECTS.

This is mah Coding face.  There are many like it, but this one is mine.

Yes, that's the look I've had for about the past two days.  Disheveled hair and all.  Kids, this is what happens when you are away from home (and a nerd)
All of the stereotypes become true!  I guess that means I need to start watching my weight now or I'll never have another girlfriend...!

 Paralyzing self-doubt aside (loljk) I have made a breakthrough!  Well, okay, so this has been done before, by countless people for countless games and engines, but somehow I managed to meddle my way through the entire ordeal!

...and I may have gone a bit crazy in the process

Its not much to look at... but under the hood this this is... well a big huge mess, but it works

What I've miraculously managed to achieve is 2D solidarity (as in, being solid)  I had previously spent all my efforts on 2D pixel-based collisions, which you can see at the start of this puppy (I think I talked about it anyway) which means I know when a pixel of my bad guy, and a pixel of my good guy are on top of each other, then I know that they are touching!  (A pixel is just a single unit of color, your screen is made up of a LOT of pixels just in case nobody knew that)

Well that was all and dandy, but with things flying across the screen (Like bullets and robots n' stuff) knowing when my player was literally on top of a robot was great, but how to solve the question of keeping my players and robots FROM being on top of each other?  What if I wanted them to bounce?  Well, bouncing is easy enough, check for a collision, if there is one, adjust the two dude's velocities...

But here is where you have to think like the computer.  A program of any given type (unless someone's been lying to me here) is a linear processor.  It's just a ridiculously fast linear processor.  It computes everything, movement, drawing, creation, destruction, in one pass and then goes back and does it all again.  So following this logic, if the player is moving really fast, he could not be colliding in one frame, in one pass of the computer's logic, but in the next he could be halfway on top of the enemy I specifically DON'T want him to look like he's on top of!  Which means that, for one frame, the player of my game sees the intersection that I want to avoid.

Well this was a two-pronged approach, and I'll try to be brief  in description but...

First I found out exactly how many pixels in width and height the collision occurred at.  The original method I used for checking collisions stopped at the first collision, which is great, but I needed to know just how far away to put the player once he overlapped my bad guy so that they would be JUST BARELY touching, but not overlapping.

Pixel checks go row of pixels by row of pixels, from top to bottom, so...

So instead of stopping at the first overlapped pixel, I checked the rest of the row of pixels for more overlapping occurrences, and then for each occurrence in that row, I checked the y column of that row for pixel collisions too.  In the end I took the greatest of each number (the widest and tallest row/column of overlapping pixels) and used these numbers as an "offset" to move my player back, so they were just touching.

TOO MANY TECHNICAL DETAILS!! GET TO THE POINT!

So that ended up working (not yesterday when I put all that time into it... this morning, when I should have been studying for class!) which was sweet, but there was still that ONE MEASLY FRAME where my player would overlap, which didn't look very cool.

Computer's don't understand English, though...

This solution ended up being much easier than I thought.

I just took the velocity of each object, and then checked the collisions AS IF the images were one step ahead of where they actually were in code (I just used a temporary variable that had one extra boost of the velocity, but didn't change the actual position of the image)
And then I got the same pixel-offset method to STOP the velocity of the object by that certain offset.  The next frame, the image would still move, but it wouldn't move into or onto my enemy!

This is a picture of a Gnome flipping the bird. I just want to see if you guys are still with me at this point.

Now velocities change from frame to frame, but this solution, while not exact or precise, is good enough to prevent an obvious overlap from occurring, and essentially...
I now have solid sprites!
Huzzah!

I will now retreat into seclusion for the next few days, nursing my victory over machine before the next one hits me like a ton of bricks like I know it will!
Just kidding, I'ma study, and hopefully meet up with David at some point this weekend, and get to the fun, gameplay programming I so desperately long for! (Kidding again, that stuff can be hard!)

But, at this point, I can't think of any more technical details or kinks that need to be worked out, I just need to go through my code, comment, clean-up, and get started (FINALLY) on the stuff that makes this sucker fun!
(If this doesn't turn out to be fun, I will shoot myself)

Artist's Rendition

In the foot guys, geeze!

- Kev