   Pixel Manipulation
  I wrote the following example in ActionScript 3 for Flash however it could be ported easily to C++, VB, C#, Java, etc...To get a crude very inefficient demo together I have done the following...- Draw 3 objects on screen (Circle, Rectangle, Ellipse)- Loop through every pixel starting from the bottom of the screen to the top- For each pixel check it's color-- If it's white do nothing-- If it's non-white then check the corresponding pixel below--- If the pixel below is white then "move" the pixel down 1--- If the pixel below is not-white then do nothing, there is something below the pixel and we should not move itThe end result is that all pixels move down the screen until they are settled. Pixels form shapes that move until the shape "collides" with something, at that point the pixels continue to move giving the effect that the shape conforms to whatever it is "falling" onDemo - http://games.reltru.com/PixelTest/play.htmlCode - http://games.reltru.com/PixelTest/PixelTest.asNow... I want to try and make the above more efficientI guess I'm struggling on the best place to start, I have a few ideas (some that may work and some that are new to me and I can't even figure out where to start)... I would imagine that there has to be an efficient way to accomplish my goalMethod 1- Identify the min/max left/right bounds of objects to update- Process all pixels with-in the left/right bounds from bottom of the screen to the topIf my screen is 400x400 and I have the following two rectangles on screenRect1 = {x: 50, y: 100, width: 50, height: 50}Rect2 = {x: 75, y: 150, width: 50, height: 50}With this method I would only have to process pixels in the following space{x: 50, y: 0, width: 75, height: 400}So instead of checking 160,000 (400x400) pixels per iteration I would only need to check 30,000 (75x400) pixels per iterationMethod 2I have no idea if this is possible... I haven't quite worked out my thought process regarding it either...- Get a copy of the screen- Process rows from bottom to top of screen- Get a copy of all pixels in the current row, stored in variable current_row- Get a copy of all pixels in the row 1 below the current row, stored in variable lower_row- Print to a new object what is stored in the "lower_row" object- Print to the new object what is stored in he "current_row" object, but only what is not overlapping the existing pixels- The new object would now store what the row below the current row would look like with the changes- Print this new object to the row below the current row, updating our screen- Extract out of the new object the changes and overwrite the current row (deleting the pixels that "moved" to the next row)Maybe the above is possible using some sort of "Blend Mode" like subtract/add...Anyone have suggestions? Ideas how to make the "concept" demo more efficient?   
  I made little progress on Method 2 using built-in AS3 methods...NOTE: Some of the following is specific to ActionScript 3, not just theoretical, so it may seem more confusingStart at the bottom of the screen and work towards the topFor each iteration through the loop:- Copy the pixels from the current row into a new DisplayObject (_CURRENT)- Copy the pixels from the row below into a new DisplayObject (_BELOW)- Copy _CURRENT into a new DisplayObject (_CONTAINER)- Copy _BELOW into _CONTAINER setting the BlendMode to ERASE (this will erase from what is in the _CONTAINER with anything that overlaps with _BELOW)In _CONTAINER I now have a copy of what should move down a row excluding any section where something exists that it would "go on top of"At this point I update the main image with what is in _CONTAINER at a position that would put the contents of _CONTAINER one pixel below the current row position, effectively moving what is "OK" to move downThe next step would be to erase from the current row anything that "moved" down 1 row, effectively leaving what didn't move because something was below it, and erasing what moved because we have already printed out the moved content 1 row belowI doubt I'll get this working... But it seems like it should be faster than iterating through 30,000 to 160,000 pixels individually   