I was trying to blit my back surface onto my front buffer. blt() would work, but not bltfast(). I looked for an answer on the board but I couldnt really find it. At some point I read a post about clippers and it gave me the idea to remove mine, just to see how things would work. Once I removed it, bltfast() started to work. The only problem with it is that I have to convert my destination coordinates to match my client area. You can blit any surface anywhere on the screen with bltfast(). I was wondering: why woudlnt bltfast work when I had a clipper? I am also wondering: has the debate on blt() vs bltfast() settled? Which is faster? What are each function advantages/inconveniences? I tend to use bltfast() all the time, because I remember seeing somewhere that it wasnt'' possible to to transparency blits with blt() (for those who dream to do 3d3 one day, but arent yet). Is this information right? Thanks for any advice, insights and suggestions.

You can do transparency blits with either.

Blt does a few things that bltfast cannot do - work with the clipper is an important one, but lots of other doodads like full control of the source and dest rect co-ords, which means clipping without using the clipper, if you wanted, and resizing things, rotations, mirror images and the like.

El Duderino

Since the documentation says that bltfast is only faster if using software blit (and as far as I know about all cards by now support hardware blitting) I don't think there is any reason to use bltfast. Blt is just so much more flexible...

Edited by - Wuntvor on March 19, 2001 12:20:44 PM

Thank you everyone for this instructive information.

While we are on the windowed mode topic, I would like to ask you a few additionnal questions regarding clippers.

Since I did not put a clipper back in my application yet, I am experiencing all sorts of problems, when dragging other windows over my DX application and such. How would you propose to solve this kind of issue? Is there any alternative to clippers? What makes a clipper slow or fast? Is a clipper only use is to garantee a proper refresh of our DX app on the desktop?

Actually, I have no problems in my app and I am not using a clipper. What seems to be your problem is that you probably don''t handle the WM_PAINT-message correctly. At the end of it you should call ValidateRect(NULL) to validate your window, otherwise you will get a WM_PAINT-message again and again => it will overlap with other windows.
Still, using a clipper is a good idea as you should not draw outside of your window anyway. (it is not a good idea, at least)

Please let me make sure that we're understanding each other. If you drag some window over your application over and over, you won't have any refresh problems? You are not setting any direct draw clipper when initializing your DX window?

I have found that my application would behave as expected when I create a clipper for it. However, when there is no clipper for my window, dragging other windows over it will obscure those windows with my apps contents.

I believe I am handling the WM_PAINT message correctly. What I am doing is pretty simple (I didn't care to optimize yet).
{
CPaintDC dc(this);
ddraw_FrontBufferPtr->Blt( &myClientRect, ddraw_BackBufferPtr, NULL, DDBLT_WAIT, NULL );
}

I understand that my front buffer is in fact my whole screen. It seems fairly normal that this blit operation just overwrites anything that's over my window's client rect. However, I do not want this to happen and the only way so far seem to be using a clipper.

Thanks for your support.

Edited by - devious on March 31, 2001 9:25:07 PM