(DirectDraw) - How to Blt (stretched) and clip to window when not supported by hardware

[Slien]

I have a bitmap (fairly large) in an offscreen surface, and when trying to
Blt this to my primary surface so that the image is stretched (to zoom in on
the image), DirectDraw draws the stretched image outside my window, in the
top left of the screen, even though I have a clipper attached with the
window handle set. I have since found that I am missing the hardware
capability DDCAPS_CANCLIPSTRETCHED, which sort of explains that behaviour,
although I would have expected the emulation layer to have attempted it. And
yes, it does clip to the window when blitting without stretching. I am using
DirectX SDK version 9 with DirectDraw 7 interfaces.

Does anyone know how to do this? I've tried instead to create my offscreen
surface as big as I want the image stretched (instead of the same size as
the bitmap), and used StretchBlt to stretch my device independent bitmap in
the surface, and then tried to Blt this to my primary surface (so that Blt
shouldn't need to stretch), with strange results. The palette information in
the BITMAPINFO structure of the DIB is ignored and so the colours come out
looking strange, although the image is scaled and clipped correctly in my
window.

Can anyone help?
Thanks, Serena.

[Phil Taylor]

so does the debug runtime output provide any debug info that indicates a
problem with the Blt?

all methods return S_OK?

did you set the palette on the device, or the src and dst DCs if using GDI?
its not enough to have it in the BITMAPINFO, iirc.

if you've done all of this, have you tried initializing DDRAW with the
emulation flag, DDCREATE_EMULATIONONLY, and seeing if the HEL will provide
this functionality when the CAPS dont have DDCAPS_CANCLIPSTRETCHED?

if the HEL works, and there is no debug output its possible its a driver
bug. I would doubt this would get priority though.

if the HEL works, then given speed isnt an issue in the no hw support case,
you could write 2 code paths. you could notify the user that the hw didnt
support this feature, so it would be emulated and slow rather than failing.

if speed is an issue, you could try to write your own Blter for this case.

thats about the extent of the choices.

Post by Slien
I have a bitmap (fairly large) in an offscreen surface, and when trying to
Blt this to my primary surface so that the image is stretched (to zoom in on
the image), DirectDraw draws the stretched image outside my window, in the
top left of the screen, even though I have a clipper attached with the
window handle set. I have since found that I am missing the hardware
capability DDCAPS_CANCLIPSTRETCHED, which sort of explains that behaviour,
although I would have expected the emulation layer to have attempted it. And
yes, it does clip to the window when blitting without stretching. I am using
DirectX SDK version 9 with DirectDraw 7 interfaces.
Does anyone know how to do this? I've tried instead to create my offscreen
surface as big as I want the image stretched (instead of the same size as
the bitmap), and used StretchBlt to stretch my device independent bitmap in
the surface, and then tried to Blt this to my primary surface (so that Blt
shouldn't need to stretch), with strange results. The palette information in
the BITMAPINFO structure of the DIB is ignored and so the colours come out
looking strange, although the image is scaled and clipped correctly in my
window.
Can anyone help?
Thanks, Serena.

[Slien]

Thanks for your reply, your comments have been incredibly useful!
I set up DirectDraw in emulation only mode as you suggested and clipping
while stretched works perfectly! Unfortunately I didn't know how to use the
debug runtime, as I wasn't given an option on installing the SDK (using the
latest summer update edition Oct 2003) and the control panel seems to say
that debugging info is only available for interfaces > 7 and I am only using
directdraw7 interfaces). There were never any errors before, all methods
returned S_OK. Does this mean that there is a bug in the driver? I thought
if DirectDraw couldn't find the capability in hardware it would
automatically use the emulator, so if the HEL works shouldn't it have called
on it to clip the image?

I have since changed my code to use a source rectangle so that I didn't have
to rely on clipping (I was previously using the entire source and just
blitting into the destination and expecting clipping to work for me). This
has solved my palette problem for me. I only had a problem with the palette
when I was trying to create my offscreen surface smaller than the size of my
bitmap, at surface sizes greater or equal to the size of the bitmap, the
colours came out fine). Note I only used the BITMAPINFO to set the DIB
colours, letting GDI perform the colour conversion for me, realizing a
palette wasn't necessary). Anyway, the palette issue no longer bothers me
and now I always create my offscreen surface as big as my DIB..

After I wrote the code to blit without clipping, I noticed that if I moved
the application window off the sides of the desktop, suddenly the image
would again be drawn outside the window. This was because the destination
rectangle, once converted to screen coordinates, might have negative values
or values outside the size of the screen. Once again DirectDraw didn't
return an error, it just failed to clip to my window. I'm sure I can fix
this myself by modifying my rectangles so that they fit within the screen
though.

Thanks again,
Serena.

Post by Phil Taylor
so does the debug runtime output provide any debug info that indicates a
problem with the Blt?
all methods return S_OK?
did you set the palette on the device, or the src and dst DCs if using GDI?
its not enough to have it in the BITMAPINFO, iirc.
if you've done all of this, have you tried initializing DDRAW with the
emulation flag, DDCREATE_EMULATIONONLY, and seeing if the HEL will provide
this functionality when the CAPS dont have DDCAPS_CANCLIPSTRETCHED?
if the HEL works, and there is no debug output its possible its a driver
bug. I would doubt this would get priority though.
if the HEL works, then given speed isnt an issue in the no hw support case,
you could write 2 code paths. you could notify the user that the hw didnt
support this feature, so it would be emulated and slow rather than failing.
if speed is an issue, you could try to write your own Blter for this case.
thats about the extent of the choices.

Post by Slien
I have a bitmap (fairly large) in an offscreen surface, and when trying to
Blt this to my primary surface so that the image is stretched (to zoom

in

Post by Phil Taylor
on

Post by Slien
the image), DirectDraw draws the stretched image outside my window, in the
top left of the screen, even though I have a clipper attached with the
window handle set. I have since found that I am missing the hardware
capability DDCAPS_CANCLIPSTRETCHED, which sort of explains that behaviour,
although I would have expected the emulation layer to have attempted it.

And

Post by Slien
yes, it does clip to the window when blitting without stretching. I am

using

Post by Slien
DirectX SDK version 9 with DirectDraw 7 interfaces.
Does anyone know how to do this? I've tried instead to create my offscreen
surface as big as I want the image stretched (instead of the same size as
the bitmap), and used StretchBlt to stretch my device independent bitmap

in

Post by Slien
the surface, and then tried to Blt this to my primary surface (so that Blt
shouldn't need to stretch), with strange results. The palette

information

Post by Phil Taylor
in

Post by Slien
the BITMAPINFO structure of the DIB is ignored and so the colours come out
looking strange, although the image is scaled and clipped correctly in my
window.
Can anyone help?
Thanks, Serena.