flipCode - Tech File - Mike Hommel [an error occurred while processing this directive]
Mike Hommel
(aka Jamül)
Click the name for some bio info

E-Mail: jamul@hamumu.com

   07/30/1999, Taking It Slow

In my current project, I was trying to come up with a way to antialias and fade the entire screen during gameplay, in 16-bit color. As you can imagine, it was slow. So hey, here's the algorithm for everybody who wants to do something to every pixel on the screen that's just too CPU-eating to be done at the rate you want:
  1. keep a variable, X, of the current pixel to be worked on. Start it at something small, whatever you like.
  2. Do what you want to the pixel at X.
  3. Add a large number to X. The large number should be larger than the screen pitch, preferably a lot larger. Always use the same large number.
  4. If X gets past the bottom of the screen, subtract the entire size of the screen from it (pitch*scanlines). Now X is back up near the top, and assuming your large number was a good one (something odd is recommended), it's not in the same place it was in the first place.
  5. Repeat steps 2-4 as many times as you want to do per frame.
  6. Next time you update, do it all again.
In case you don't get it, I'm saying you do only a subset of all the pixels onscreen, but you do them in such a way that the ones being done appear to be semi- random. Obviously, your number has to be such that it will hit every single pixel and then repeat. If what you are trying to do to the pixels takes so long that you can only do 10 or so each frame, you're screwed, so don't bother. I do 640*20 pixels per frame (20 lines worth, the screen is 640x480), so it takes 24 frames for it to do the whole screen once. Pretty bad if you think about it, but you know, it looks really good. Except one thing- it really bogs the game down. A lot less than it would if I did the whole screen though!

I'm sure all those people who know junk about cache optimizations and all that crap scoff at this, but they're just not artist`es. Hmph.

P.S. the number I used was 640*280+1, which ensured the pixels being updated were nowhere near each other generally, so you don't get much of a banding effect.

  • 07/30/1999 - Taking It Slow
  • 07/28/1999 - Pixel Collision Detection Between RLE Sprites

  • This document may not be reproduced in any way without explicit permission from the author and flipCode. All Rights Reserved. Best viewed at a high resolution. The views expressed in this document are the views of the author and NOT neccesarily of anyone else associated with flipCode.

    [an error occurred while processing this directive]