Thanks for the help, I really appreciate it.
Ok, I understand now fez. That's logical.
I've tried your version burp, but I get one little problem on it. The colors is wrong. It's suppose to get darker, but all I get is some strange random colors. I have a 32bit surface and are using 32bit images. I suppose you meant to put (b << 0) and not g in the buffer. If I put pct to 1, I should get the original colors, but I don't. The green colors becomes orange..


Edited by - delbogun on October 31, 2001 10:45:20 AM

Just a question, doesn''t that sort of thing require the surface to be locked, for a measurably long time?

I don''t use DirectDraw much anymore (I''ve gone to OpenGL) but I thought you shouldn''t lock surfaces for any long amount of time...

Yes, I believe that code would be incredibly slow, but I don''t think locking a surface for a long time would do any harm.

As for the colors getting messed up, maybe you should use ULONGs for the r, g and b values. They might be getting shifted 8 and 16 digits, and since they''re 8-bit values, they''re getting shifted all to zeroes.

try this, it should be a lot faster (and hopefully work right):

  void Fade(DDSURFACEDESC ddsd, float pct){   DWORD *buf = (DWORD*)ddsd.lpSurface;   DWORD jump = (ddsd.lPitch - ddsd.dwWidth) >> 2; //you''re moving 4 bytes at a time, so divide by 4   DWORD color, percent = (DWORD)(256.0f * pct); //it''s much faster to use fixed point since you''re converting to/from float 3 times per pixel   for(int y = 0; y < ddsd.dwHeight; y++)   {      for(int x = 0; x < ddsd.dwWidth; x++)      {         color = *buf;         *buf++ = (((color >> 16 & 0xff) * percent >> 8) << 16)|             (((color >> 8 & 0xff) * percent >> 8) << 8) |             ((color & 0xff) * percent >> 8);      }      buf += jump;   }}  

Sorry if it''s not too clear what it''s doing, but if you do all the color calculations in one statement, you don''t have to declare the extra variables for r, g and b.
If you want, you can change it to do the colors like (color & 0x00ff0000 >> 16) like everyone else did instead of shift first and then AND with 0xff on every color, but I think it looks better that way cause it doesn''t take as much room^_^

Also, if you''ve never used fixed point math, try using a calculator to multiply 256 by some number between 0 and 1 (which would be pct in the program), then multiplying that by any number you want (this will be the color value), and dividing by 256. You should get the same result as if you multiplied the color value by pct directly. In computers, it''s faster to do a shift than a float/int conversion, so that gives it a big speed boost.

Hope this helps^^


-Deku-chan

DK Art (my site, which has little programming-related stuff on it, but you should go anyway^_^)

YES!!! It WORKS!! Many Thanks!!
DekuTree64, your code seems to be fastest, but this line: "(ddsd.lPitch - ddsd.dwWidth) >> 2" makes my computer hang up for a strange reason... but if i''m using "ddsd.lPitch - (resolution_x*sizeof(int))" like burp wrote, it works :D