alternative to directx blit...help!

Started by
4 comments, last by Angeroa 24 years, 1 month ago
I read this article at the directx developers page (or whatever it''s called now) and I followed the code to an alternative blitting function code for code. The problem is that the function only blits half the given width. For example, I passed a 64x64 rect to blit but only recieve a 32x64 rect. I believe it''s how I access the surface but not sure what to do. void Blit(LPDIRECTDRAWSURFACE7 dest, LPDIRECTDRAWSURFACE7 src, int xpos, int ypos, RECT area) { int nHeight = area.bottom - area.top, nWidth = area.right - area.left; DDSURFACEDESC2 ddsd_dest, ddsd_src; // LOCK BACKBUFFER ZeroMemory(&ddsd_dest, sizeof(ddsd_dest)); ddsd_dest.dwSize = sizeof(ddsd_dest); dest->Lock(NULL, &ddsd_dest, DDLOCK_WAIT, NULL); //LOCK MAINGFX ZeroMemory(&ddsd_src, sizeof(ddsd_src)); ddsd_src.dwSize = sizeof(ddsd_src); src->Lock(NULL, &ddsd_src, DDLOCK_WAIT, NULL); BYTE *lp_dest = (BYTE *)ddsd_dest.lpSurface; BYTE *lp_src = (BYTE *)ddsd_src.lpSurface; //Move down to the correct line lp_src += area.top * ddsd_src.lPitch; //Move over to correct pixel lp_src += area.left; //Move down to the correct block frame //Don''t multiply this value by 2! lp_src += area.left * ddsd_src.lPitch; //Move over to correct block //(Times 2 cause we are in 16 bit color) lp_src += area.left * 2; //Move down to correct y co-ord lp_dest += ypos * ddsd_dest.lPitch; //Move over to correct x co-ord lp_dest += xpos * 2; for (int CurrentLine = 0; CurrentLine < nHeight; CurrentLine++) { memcpy(lp_dest, lp_src, nWidth); //Move to next line.. lp_src += ddsd_src.lPitch; //Move the destination to the next line.. lp_dest += ddsd_dest.lPitch; } dest->Unlock(NULL); src->Unlock(NULL); } Again, I think it''s when I access the surface by using a BYTE. Using a WORD or DWORD in replacement has given me errors and such. Please help.
Advertisement
This function will copy only half of width becouse of "BYTE".

When you are calculating width you must do *4 not *2 becouse you are in 32bpp (32bit=4 bytes, 16bit=2 bytes,...)
Good GOD!
Who put multiplications in a time critical routine?????
NEVER use a multiplication in a time critical routine! It''ll DESTROY your speed!

Use bit shifts instead... for instance, saying

18*2

is done in a SINGLE CYCLE (sometimes less) by saying:

18<<1

And 18*4 would be 18<<2.


Holy crow, I wouldn''t trust that routine. You''re already talking about a 64 cycle speedup (maybe more) on that one notion alone!! It doesn''t seem like much, but I''ve found that those 64 cycles are better used ANYWHERE else but in a main rendering loop!
Of course, most compilers these days will spot a multiplication by a constant and optimise it out into a shift if applicable, maybe into a few additions if not. Of course, the principle is correct though - if you change it to a shift yourself, you''re leaving nothing to chance.
The function is for 16 bit mode so the times 2 is correct.
I think what might be causing the problem is

nWidth = area.right - area.left;

because when you call your memcpy like this:

memcpy(lp_dest, lp_src, nWidth);

you are copying nWidth 8-bit bytes, instead of nWidth 16-bit pixels... So I think if you change the nWidth line to

nWidth = (area.right - area.left) << 1;

you should get the full width of the src getting copied. Thats all that I could notice, of course I might be wrong cause I''ve been working in 8-bit mode a lot more than 16-bit...

Hope that helps.

Where's my Golden Fleece?

This topic is closed to new replies.

Advertisement