#### Archived

This topic is now archived and is closed to further replies.

This topic is 6693 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

HI I want to know how many sort of Blur FX except motion blur... and I also wanted to know if blur effects are slow processus... because I''ve done one... and it runs at about 41 fps on a PIII 600!!! in 13h mode... here isthe code:
  void Blur(rgba palette[256]) { rgba a, u, l, r; int R, G, B; unsigned int p; for(int y = 1; y < 199; y++) { for(int x = 1; x < 319; x++) { p = x + (y << 6) + (y << 8); a.r = palette[buffer[p - 320]].r; u.r = palette[buffer[p + 320]].r; l.r = palette[buffer[p - 1]].r; r.r = palette[buffer[p + 1]].r; R = (a.r + u.r + l.r + r.r) >> 2; a.g = palette[buffer[p - 320]].g; u.g = palette[buffer[p + 320]].g; l.g = palette[buffer[p - 1]].g; r.g = palette[buffer[p + 1]].g; G = (a.g + u.g + l.g + r.g) >> 2; a.b = palette[buffer[p - 320]].b; u.b = palette[buffer[p + 320]].b; l.b = palette[buffer[p - 1]].b; r.b = palette[buffer[p + 1]].b; B = (a.b + u.b + l.b + r.b) >> 2; abuffer[p] = RGBMatch(palette, R, G, B); } } memcpy((void *)buffer, (void *)abuffer, 64000); } 

##### Share on other sites
If its mode 13h, you could probably get away with some sort of look up table instead of using the rgblook up function. Or try this in an rgb mode.

OneEyeLessThanNone

my keyboard would better serve as a wiffle bat

##### Share on other sites
also with the color lookup, for each pixel... well. a table is slow too if unsorted. i''d look into a presorted or hash table..
eg.. a table of say 512000 entries (hell we''ve all got 64 megs these days anyway) we could use a smaller one too of course depending on the hash function..
the simplest function would be

color = palette_table[r+(g>>7)+(b>>14)];
and you''d prematch every color in the palette to the table entry beforehand.

you can surely make a function for a smaller table, but if there are a lot of similar colors, you may get two colors who get the same entry, in which case you''ll have to devise a workaround.
hope this helps!

##### Share on other sites
that would be a damn big look-up table

JoeMont001@aol.com

##### Share on other sites
Hi!

Ermm. Things, which you should optimize:

Instead of using (x, y) variables, you should try to just use one offset (in your case p) and increment it, instead of recalculating for every pixel. I know that this messes up the borders a bit, but you could just make your buffer a bit larger, than needed (that way you don''t do any ''wild'' array accesses)and draw a black rectangle around your final image (to hide the messed up borders)

Then you just do:

}

The offset should be chosen, so that buffer[p - 320] is still within the array bound (otherwise possible general protection fault). Also buffer should be big enough for buffer[offset+64000+320] to be within bound.

Next up, calculation of R, G, B. Use a lookup table for that. The sum of the a, u, l, r components will always lie between 0 and 1020 (4*255), so already store the shifted return values there.

First you do just the r values, then g, then b. BUT, you always access buffer for every component. You should just do four buffer accesses at the beginning, store the rgba values from your palette and work with these values.

Next up RGBMatch():

This HAS to be a slow-down. I guess you can only get rid of it if you switch to RGB modes or use some look-up strategy.

Hope this is useful,

MK42

1. 1
Rutin
37
2. 2
3. 3
4. 4
5. 5

• 12
• 10
• 13
• 104
• 11
• ### Forum Statistics

• Total Topics
632982
• Total Posts
3009689
• ### Who's Online (See full list)

There are no registered users currently online

×