A final word about frame and refresh rates:
I have seen a recurring theme in questions about DirectX frame rates [fps = Frames Per Second]...
People trying to "free" themselves from the monitor refresh rate or trying to achieve higher frame rates beyond their monitor refresh rates.
It is understandable for those that do not understand the behind the scenes hidden processes in DirectX and hardware drivers to not realize it, so please do not take this personally, but do let me note that this is an absurd idea as the only usefulness of it might be to determine more exactly
how much time the rest of your code is eating up, and serves no real purpose in a final application. However, when you think about some basic things outside the realm of DirectX, video hardware, or programming, you can begin to understand.
The human eye/brain can only discern differences when the frame rate gets EXTREMELY
low. Please note that a lot of internet players only run at 15fps, most movies are displayed at 22fps to 24fps while newer digitally created ones still at only 32fps, and having a monitor refresh rate of 60Hz (60fps) or higher is much
more than enough.
Note that by trying to go outside your monitor refresh rate you incur artifacts like "tearing" or "flicker" (and slower
swap chain back buffer copy
effects) that can show up on some systems and not on others, while not achieving any useful end. This applies to using swap effects other than SwapDiscard (or SwapCopyVsync for windowed mode when scan lines cannot be read) and/or using an 'Immediate' presentation interval instead of a synchronized one.
If you can get the rest of your program to eat up enough processor time, it might jump down to 30fps (every other frame) or 20fps (every 3rd frame), which are really great frame rates. If even more is eaten up then it can go to 15fps or 12fps and it will still be good. Even more could make it 10fps, 8.6fps, 7.5fps, or less and depending on the type of monitor (like CRT, plasma, LCD, LED) different people will perceive these differently. However, this is NOT
a problem of being vsync'd by using SwapDiscard (or SwapCopyVsync for windowed mode), it is a problem with slow code
(like unneeded, unnecessarily accessed, or hidden code), and changing to another swap method will only slow things down even more due to frame copy effects and hidden additional swap chain back buffers you didn't create yourself.
The optimum swap effect to use is SwapDiscard as it avoids extra frame copies, hidden swap chain back buffers, and is synchronized with the refresh rate. WARNING:
On some video card and monitor combinations a condition can exist where in Windowed mode the scan line cannot be determined and this can cause SwapDiscard to not be synchronized for your applications window
. In this case, a setting of SwapCopyVsync can be used to overcome this as it copies the window when it gets the vertical synchronization signal. This condition can be tested for by checking the D3DCAPS8.Caps member for the D3DCAPS_READ_SCANLINE flag:
CanReadScanLine = CBool(D3DCAPS8.Caps And D3DCAPS_READ_SCANLINE)
If this is False
while in WINDOWED
mode then you should use SwapCopyVsync. However if you are using full screen mode
(as opposed to windowed) then still use SwapDiscard
as it will still synchronize because since it covers the entire screen the top line resides at the first scan line and it uses the vertical synchronization signal instead of trying to read the scan line for an application window and it still avoids extra swap chain back buffers and copy operations.
If your excuse is that you are trying to buy your program more time to work before the next frame or that it messes up your physics/AI/etc., then you either have your program physics/AI/etc. based on the frame rate instead of the actual time (and/or frame time
) like it should, or you can freely allow it to present frames with the refresh rate and allow your program to make its calculations as it would like to and the frame rate will come as it will while still allowing computation time for when you have to work with more complex environments instead of it being eaten by more complex hidden code because you made it "free" of the refresh rate. If you so desire you could make the presentation interval every other frame or every 3rd frame so the time used in presenting the extra frames can be used for calculations, but I myself never bother adding the extra code needed to handle that.
Again, trying to "free" yourself from the vsync would only make your frame rates be able to go between
the already mentioned frame rates, or pointlessly
above it, and would only be more accurate in telling more exactly
how much time it takes your program to present a frame while incurring slow downs and artifacts that you may or may not see but others certainly will.
Thank you for listening...
P.S. A single copy operation eats time: Width * Height * ColorBitDepth \ 8 = bytes to copy for a frame, and there can be additional copies, or additional swap chain back buffers which multiplies this when using Copy or Flip swap effects.
P.S.S. I would request that this be added to the 'Frequently asked DirectX 7/8 Questions' at
Frequently asked DirectX 7/8 Questions
, so that questions about this subject can be reduced.