Is DirectDraw modifying lpitch distorting my graphics?
Author
I am writing a bitmap loader. I load the data into my buffer successfully. I create a DDraw surface using dimensions from the bitmap header. When I copy the data to the surface it is distorted in a fashion that suggests the destination lines are larger than the source.
DDraw modifies the lPtch so that its half is elevated to the nearest even number. If half the image and therefor lPitch width is even the image works correctly. Could someone please tell me why this happens and how to remedy it (compromising in my copying code does not work). thanx!!!
ps I am working in 32 bit colour
[edited by - BinaryOne on August 14, 2002 9:10:50 PM]
I always set my surfaces'' widths to the multiple of 8 that is closest to the bitmap''s width (of course the multiple of 8 must be greater than the bitmap''s width). For example if I am loading a bitmap with a width of 21 the engine width create a surface with a width of 24. I then blit the bitmap to the surface. When rendering, I set the source rect so that the 3 extra pixels on the right are not rendered.
Hope that helps!
[Edited by - JonW on February 18, 2009 10:25:45 PM]
Hope that helps!
[Edited by - JonW on February 18, 2009 10:25:45 PM]
when dealing with directdraw you always use the pitch when doing pixel position calculations. ie video[x+y*lpitch]. its not dx messing things up (assuming you are using lpitch instead of width) its your loader. bmps are stored using dword aligned scanlines (ie multiple of 8bytes) thus there is padding in at some widths. look at the bmp format specs and it will become clear.
[edited by - a person on August 14, 2002 11:09:17 PM]
[edited by - a person on August 14, 2002 11:09:17 PM]
You asked this exact question a few days ago, and my answer is still the same: debug your loader code.
If you pasted it in here, we might be better able to tell you what you did wrong.
Don''t listen to me. I''ve had too much coffee.
If you pasted it in here, we might be better able to tell you what you did wrong.
Don''t listen to me. I''ve had too much coffee.
Author
if( !PIE_CreateSurface( &ddsd, DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT, DDSCAPS_OFFSCREENPLAIN, &Work[workSurfaceNum], bitmap->BitmapInfoHeader.biWidth, bitmap->BitmapInfoHeader.biHeight, "work")) return(0); // Create surface for bitmap
PIE_SurfaceUtil(&Work[workSurfaceNum], workSurfaceNum,"lock", bitmap->BitmapInfoHeader.biWidth, bitmap->BitmapInfoHeader.biHeight); // Lock the offscreen surface
for( int y = 0; y <= bitmap->BitmapInfoHeader.biHeight; y++)
{
for( int x=0; x <= (bitmap->BitmapInfoHeader.biWidth * BPP); x++)
{
OffscreenBuffer[x + (bitmap->BitmapInfoHeader.biHeight - (y+1)) * ddsd.lPitch] = bitmap->buffer[x + y * bitmap->BitmapInfoHeader.biWidth * BPP];
}
}
PIE_SurfaceUtil(&Work[workSurfaceNum], workSurfaceNum,"unlock", bitmap->BitmapInfoHeader.biWidth, bitmap->BitmapInfoHeader.biHeight); // Lock backbuffer surface//////////////////////////////////////////////////////////
PIE_SurfaceUtil(&Work[workSurfaceNum], workSurfaceNum,"lock", bitmap->BitmapInfoHeader.biWidth, bitmap->BitmapInfoHeader.biHeight); // Lock the offscreen surface
for( int y = 0; y <= bitmap->BitmapInfoHeader.biHeight; y++)
{
for( int x=0; x <= (bitmap->BitmapInfoHeader.biWidth * BPP); x++)
{
OffscreenBuffer[x + (bitmap->BitmapInfoHeader.biHeight - (y+1)) * ddsd.lPitch] = bitmap->buffer[x + y * bitmap->BitmapInfoHeader.biWidth * BPP];
}
}
PIE_SurfaceUtil(&Work[workSurfaceNum], workSurfaceNum,"unlock", bitmap->BitmapInfoHeader.biWidth, bitmap->BitmapInfoHeader.biHeight); // Lock backbuffer surface//////////////////////////////////////////////////////////
"Could someone please tell me why this happens and how to remedy it "
Assuming you load a bitmap into the buffer correctly, this is happening because of the way direct draw creates surfaces: Not all videocards support allocating memory for textures of just any size, DirectX is nice enough to go ahead and take care of this for you with the pitch. It makes sure that when you request a certain size of texture memory from the video card you get that, however, extra memory may be added to keep memory aligned on the video card, eg
you request 6 pixels x 1 pixel texture,
Here is how it might look in actual memory:
RGB RGB RGB RGB RGB RGB [.] [.]
[.] [.] [.] [.] [.] [.] [.] [.]
The video card would require a word aligned texture, and thus extra bytes were allocated by dx to the sides and bottom.
To Remedy:
The width you can use is still 6, but the pitch would be 8.
Eh, i''m just blabbering now, but basically use pitch when modifying/reading memory on any texture in DX to make sure you modify the real usable data.
Freeware development:
http://www.ruinedsoft.com/
Assuming you load a bitmap into the buffer correctly, this is happening because of the way direct draw creates surfaces: Not all videocards support allocating memory for textures of just any size, DirectX is nice enough to go ahead and take care of this for you with the pitch. It makes sure that when you request a certain size of texture memory from the video card you get that, however, extra memory may be added to keep memory aligned on the video card, eg
you request 6 pixels x 1 pixel texture,
Here is how it might look in actual memory:
RGB RGB RGB RGB RGB RGB [.] [.]
[.] [.] [.] [.] [.] [.] [.] [.]
The video card would require a word aligned texture, and thus extra bytes were allocated by dx to the sides and bottom.
To Remedy:
The width you can use is still 6, but the pitch would be 8.
Eh, i''m just blabbering now, but basically use pitch when modifying/reading memory on any texture in DX to make sure you modify the real usable data.
Freeware development:
http://www.ruinedsoft.com/
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
