I want to implement motion blur in my game, but its a 2d game on 2d hardware, most stuff I find is for 3d (perhaps the concepts are the same, im not sure thats why im asking). What are the algorithms that do this? I am assuming I can apply something akin to a blur filter (that id code up of course) to an offscreen surface before i blit it to the display surface. So its like (tell me if im wrong) Build to offscreen surface next frame image. Apply motion blur to every pixel or object or something *shrug* on that surface. Blit surface to the display surface...repeat. But of course the apply motion blur is what im not sure bout, any algorithms that im apparently not cool enough to find by googling anyone know of? Thanks, Shane

Hi, well for a 2D motion blur you could simulate it drawing a trail of sprites alpha blended for each moving object.

for example: if Sprite1 moves you draw Sprite1 5 times more(each one more transparent than the other) at different offsets (from its last pos to its new pos), maybe this could help you.

Regards,
Oscar

Wow way simpler than I was envisioning and really easy to implement...just the idea i needed.thanks! :)


Shane

2D motion blur like the filters in Photoshop or Paint Shop Pro is basically blurring pixels on a line. For each pixel, take X pixels on the left and X pixels on the right. Add the values together and divide by (X*2). You can easily speed-up this process, keep the sum in a temporary var. When you move to the next pixel, subtract the "first pixel" on left and add the new pixel :

a b(c) d e --> sum = (a+b+c+d+e) --> new value of c = sum/5
b c (d) e f --> d = sum - a + f --> new value of d = sum/5

and so on...

Okay,and can i skip pixels if they are my color key (say i want to just blur a sprite...not the magenta outside of it that is my colorkey anyway)

I take it id scan for these color key values and not add them up or add them into the sum right?

And are teh pixel colors added up on a per component basis?

(a.r + b.r+c.r, a.g + b.g + c.g, a.b + b.b + c.b) = (r`, b`, g`) = some other pixel's value;

The sprite trailing method is definitely the quickest and easiest, but I think the smooth averaging style would look really cool if you can get it fast enough.
You will have to add the components individually, but using anon's optimization of storing the sum and only adding/subtracting the end pixels, the component separatng shouldn't hurt you too bad.

The colorkey is a problem because the proper way to handle it would be to add in a transparency component, say, if 3 out of 4 of your pixels were the colorkey value, then make it 75% transparent. That complicates things even further though, because then you have to track how many of the pixels were non-transparent, and divide by that rather than a constant number, and dividing is slow. Not to mention a second divide involved in the alpha calculation, but with some math those could be combined into a single divide.
On today's computers you could probably get away with it even at pretty high resolution, and it's always fun to make really cool looking effects even if they do eat a lot of CPU anyway.

Then it's even more fun to go back and write them in assembly using MMX and stuff for the simple joy of writing overly-optimized code. It may not be the most productive thing to do, but dang it it's fun.