I can't see any reason why blitting should be faster. All flip() does is to exchange a few HW registers - What might be fooling you is that flip will lock if a blit is in progress, and wait for that blit to complete (Thus making flip() seem slow).

It might be that the DDraw implemenation of flip() actually copies memory on videocards that doesn't support flip or have insufficient memory - But in either case, you should use flip() to get the best (average) performance and avoid tearing...

/Niels

(Obviously, if you copy to the backbuffer and then flip, it would be faster to simply copy to the front buffer, but in this case, the difference should be next to nothing)...

Flipping is always faster than blitting when surfaces are in video memory. If for some reason your surfaces are in system memory then on all video cards (except ones with dma ram to vram coping) blitting is faster than flipping and a simple mmx copy loop is the fastest method (only if you have no hardware support for sysmem surfaces).

I believe the reason why Flip is slower than BltFast is that on some hardware Flip waits for the monitor refresh. This limits your fps to the refresh rate of the monitor.

BltFast doesn't wait for the refresh, therefore it would be faster on some machines.

Someone correct me if I'm mistaken.

Josh

In an ideal world, flip should always be faster, up to the refresh rate anyway since it does wait for the VRT. (Does anyone know if there is any hack to avoid the wait for VRT when flipping?).

But I do think that both methods should be supported, because often (possibly translated rarely ) the driver's flip method is buggy. I've seen cards that will NOT flip faster than 45 frames per sec. The flip call will wait an entire extra frame every third frame for no reason. Using a wait VRT/blit method, this problem doesn't arise. (Actually the waitvrt function is a little screwy too, but it misses about 1 in 20 frames only. Too bad many video drivers just plain suck).

Rock

To do a Flip without waiting for VSYNC, just use the flag DDFLIP_NOVSYNC. You also have to make sure the surface actually supports the DDCAPS2_FLIPNOVSYNC flag in the DDCAPS structure for the surface.

------------------

-Kentamanos

I am not anything of a guru of this but anyway...

As Niels says, the flip() waits for any blt to finish first and that makes the program slow, but then a little solution would be with two buffers instead of one, thus the flip() can always flip one buffer while you are blting to anotherone. And used with the DDFLIP_NOVSYNC flag, this could be brought to pretty good speeds. Never tried it myself though...

Christoffer Sandberg
todderod@algonet.se

Rats, is DDFLIP_NOVSYNC part of DX6? I'm using DX5, and it isn't available. Which brings up another question that I'll try to squeeze into this discussion. If I program for DX5, and the user has DX6 runtime, is the DX code that is used still DX5? I know I still can't use the flip_novsync flag and what not, but if DX6 is faster or whatever, do I get any benefit for that, or would I have to use the DX6/7 interfaces to benefit?

And are video drivers somehow hooked to a DX version? If the card in question flips at 45FPS with DX5, as I mentioned above, might the problem not exist if I used DX6 interfaces? Do card manufacturers support the latest DX and that's all, or is this not an issue?

Rock

There's no simple answer to all those questions , but I'll give it a shot:

You will benefit from DirectX improvements ONLY if these improvements are made on the interfaces you are using. As you've probably noticed, MS frequently adds new interfaces with names like xxxSurface2, xxxSurface3 etc. - Obviously, if all the improvements from one version of DX to the next is in new intefaces, your old code won't benefit from it.

DirectX as such is not tied directly to the hardware - it use a HW specific driver. I.e. a bug such as the one mentioned in flip() can be fixed with a new driver (regardless of the version of DX). IF, one is available, that is.

/Niels

(BTW. Interresting about the slow flip() when out of VMem - I figured it might work like that, but I've never seen it happen, or read about it for that matter. (Yep, I got a TNT2 so it's unlikely to happen in the 640x480 16-bit color mode I'm using )

When updating the screen, is flipping using ->flip(), or a fullscreen BlitFst better/safer???

I have tried it on various machines, and some are actually faster when using blitfst instead of flip!

Maybe its a good idea to pre-test the performance of both techniques on load up of my game/app, and use the faster one to ensure I am delivering maximum performance?!

OK, DX is not tied to the hardware, but is a hardware driver tied to a DX version? If I wrote DX drivers, would I need a new driver for each version of DX? I would think SOMETHING needs to be added to the driver for any extra features that DX added. But it seems like a large burden on the driver coders too if this is the case. (Well, better them than us ).

And if drivers are written for DX7, would they perform differently than their DX5 versions if I as the end developer still used the DX5 interface instead of the new DX7 interface? Am I basically using an old driver if I use an old DX interface?

I'm just wondering if this flip bug I've seen (for a card that unfortunately doesn't have any new drivers that work correctly for me) might be a bug only in the driver for the DX5 interface, and if I went up to supporting DX6 or 7, maybe the driver written for DX6 won't have that bug? Are there different sections of the driver code that are used depending on what DX interface I use? If so, I guess it is VERY unwise to write a program for anything but the latest DX version, since card manufacturers aren't going to be as diligent about old driver code as they are about new code.

Am I making any sense anymore? I should probably start a new thread for this.