Im not quite sure on this because i myself dont use windowed mode,but i dont belive you can use flipping in windowed mode. So what you do is just blit from the backsurface to the primary. Of course theres alot more than that because your in windowed mode. Also Locking is differnt.

i have actually SUCCESSFULLY made a windowed DD app.

some pointers and pitfalls:

A) no flipping, unless you are using overlays. support for overlays isnt common.

B) you need a clipper. use the SetHWnd() function to make it update with a window automatically

C) the primary surface represents the ENTIRE area of the surface, clipped by your clipper. the coordinates are NOT based off of the client coordinates of the window. ergo, if the window moves, is resized, etc, you have to change to where you blit on the primary surface (use of ClientToScreen() works here)

D) you have to accomodate ALL possible pixel formats. easy enough to do with using GDI to load your bitmaps onto your surfaces. beware that your user may change the display mode while your app is running.

Thanks for the advice!

Wow, sounds like a lot of work to use DD in Window mode. I was a fool and thought maybe it was as easy as setting the cooperation level.

I'm almost done with the full screen version of the game and maybe I'll just leave at that.

Thanks again..

Anyone else hate the screeching pop your monitor makes when switching video modes?

I think you should still make it in windowed mode. I agree with your original theory on the window look/feel. Making it windowed isn't all that complicated, it is only a bit more work. You should support both modes and while you are at it, let the user pick the resolution in full screen mode. This would make your program worth playing...not just another card game.

Another word of advice. I read that TNT based cards don't work well with clippers, so you could either force fullscreen mode if you find that a card isn't working well in windowed mode, or you could write your own clipper. Also to achieve smooth animation, you just draw to an offscreen surface surface, and blt that to the screen.

As for my two cents, I'm currently working on a project using DirectDraw in windowed mode as well as fullscreen. This allows for easier debugging. Anyway, I've got it set up where you can switch between the two using Alt+Enter. It is true that you can't flip in windowed mode, so you do have to do a blit from the backbuffer. Here's a bit on how to set it up:

First of all, you need to do some special initialization. I have three functions that do the work. The first is the initialization of my LPDIRECTDRAW. You need to do this differently based on whether it's windowed mode or not, so therefore you have a flag. If it's fullscreen, you go exclusive, set up your screen mode, bit depth, etc. Windowed mode, you have to just take what windows gives you, and therefore you need to set up some flags that will tell the rest of your app what the bit depth is, what the resolution is, etc. Anyway, the second function sets up my two main surfaces the way I like them. My primary is initialized based upon what my window mode is (once again, a flag passed to the functinon). After that, if I'm in windowed mode, I set up a clipper for it. Now, if I'm in windowed mode, I create a separate surface that is my backbuffere that is the same size as the window. Otherwise, I get an attached surface for my primary that will be called with flip in fullscreen. Now that I have all this, my last function loads all my other surfaces with bitmaps, etc.

Now, to actually do all the work, you need to do a special check only when you're ready to draw everything to the primary. The rest of your program should be fine just drawing to the backbuffer, since it can't tell whether or not that backbuffer's going to be blit'd or flipped onto the primary. Therefore, the last place you need to check you're window mode is just before you put it onto the screen Here's a snippet:

if ( WindowMode == 1 ) // We're in a window
{
RECT
DestRect = {0, 0, 640, 480}; // Set up our destination rect for the window

lpDDSPrimary->Blt( &DestRect, lpDDSBackbuffer, NULL, DDBLT_WAIT, NULL ); // Do the blit from the backbuffer to the primary
}
else
{
lpDDSPrimary->Flip( NULL, DDFLIP_WAIT ); // Flip our surfaces
}

Granted, it's better to flip since that only involves switching a pointer around, but the blit isn't too bad. One bit of advices is to load all of your surfaces except your primary into system memory at initialization, since blits from system memory to system memory are going to be quicker than a blit across the PCI or AGP bus into video memory. This way, you're guaranteed of similar performance on different systems with more/less video memory, and the only blit that ever goes across the bus is the final blit to the primary. Anyway, that's all the time I've got for now. Thanks for listening.

I know it's easier to work in Full Screen mode without having to worry about Client area clipping. However, full screen mode takes away from the "window app" look. I'm developing a Windows Card Game and would like to run it in windowed mode instead of full screen.

From my limited readings, I got the impression that page flipping from primary to back surface is not efficient in windowed mode? Is this true? If so, is there anyway to achieve smooth animations by just using primary surface drawing? Or if it is not true, then I assume I just have to use GetWindowRect() before DD_Flip? Any documentation suggestions would be great!

Thanks in advance!

I think I need a break and go play Quake3Arena :P

Awesome tips everyone! After reading more about flip and blt, I guess there isn't much of a difference btw them except blt, you need to worry about coords. So the main challenge is to handle events such as user moving the window or changing video modes. Being updated on the window/client position is not too bad with the GDI's GetClientRect() & GetWindowRect(). I guess I'll dig though the SDK on how to handle changing video modes.

Thanks again guys!

All this stuff is a lot easier then trying to choose a purdy background that won't annoy the heck out of your general targetted audience. :P