One guy who tested a DirectX 9c game got "error, monitor not insync" I think the reason is that the default hz of the game is 200, so the monitor would have to be able to put it down to the maximum hz which most monitors seem to be able to do, and infact that monitor did it on the second try too, weird. But the game also has vsync off, so I'm wondering is it possible for any monitor not to support vsync off state at all?

The monitor doesn not support vsync on/off. Thats actually a matter of videocard driver and videocard. The monitor just displays images at its refresh rate. If you turn vsync off, what happens is that the videocard can render frames faster than the monitor displays them. This is good for benchmarking your application, but can result in visual tearing (a frame being displayed when it is not done rendering, so you get some kind of in-between two frames).

I suggest you do not enforce any vsync setting with your game. Let the user select that from his video driver. By the way, 200Hz is a very high refresh rate. My monitor does 100Hz in 1024x768, 85Hz in 1280x1024 and 75Hz in 1600x1200... And thats a good performing monitor.

I know that 200 hz is a very high refresh rate, but that was just so it would use the max hz of any monitor. My monitor's max hz is 100 aswell, but it seems to put it down to the max amount with most monitors. It seems that I'll put the vsync back on and put like 60 as the default hz.

Your friend needs up to date drivers for his *monitor*.

Unfortunately most people are unaware that monitor drivers even exist at all, and those who do don't bother installing them!!


A monitor driver will:

- tell Windows the maximum refresh rate handled by that monitor (i.e. most CRT desktop monitors aren't going to go above around 85-100Hz for vertical refresh).

- tell Windows the maximum screen dimensions handled by that monitor (i.e. 1280 as the horizontal resolution isn't going to be supported on a 10 year old 14" monitor).

- set the colour profiles (ICM) and gamma correctly.



When enumerating usable screen modes with Windows and/or DirectX, the list you get back from the graphics adapter driver is checked against the list from the monitor driver, and only modes which both support will be returned, i.e. it does the following (pseudocode):

if (thereIsAMonitorDriver){  // monitor driver present, check each mode the graphics  // card can do against the monitor driver  for (i=0; i<graphicsDriver.NumberOfModesSupportedByCard; ++i)  {    if (monitorDriver.CanYouDisplayThisMode( graphicsDriver.Mode ))    {       enumerationCallback( graphicsDriver.Mode );    }  }}else{  // no monitor driver so output every mode   // the graphics card can do and ignore the monitor  for (i=0; i<graphicsDriver.NumberOfModesSupportedByCard; ++i)  {     enumerationCallback( graphicsDriver.Mode );  }}

So what happens if you DON'T have a monitor driver installed and you try to set a screen mode from Windows or DirectX which it doesn't support ?

- on ancient monitors: the picture starts rolling/wobbling and/or comes out garbled in some way. In some cases, permanent physical damage can occur to the monitor hardware.

- on older monitors and newer "budget" monitors: the picture goes black/the monitor goes into standby mode/you get a NO SYNC type message from the monitor. This is done by the monitor controller hardware to protect it from broken applications.

- on some newer monitors: the monitor will step down to the next lowest screen mode it DOES support. Note that some monitors support higher refresh rates with lower resolution modes (sacrifice hclks per pixel to get more vclks), so some won't just lower the refresh rate but also the resolution; some monitors don't guarantee the aspect ratio in these cases either. Once again this stuff is done by the monitor controller to protect the hardware from stupid use.


So what SHOULD you do?:

- use Windows/DirectX enumeration to get maximum limits for your application - don't hard code 200Hz refresh rates and expect your application to work everywhere.

- choose a sensible DEFAULT refresh rate AND resolution for your application. What's a good default? easy:look at what screen mode the DESKTOP is in before you change mode - and don't go above that!

- let the USER choose/reconfigure which refresh rate they want to use. They own the hardware, not you; maybe they know something you don't (e.g. "I prefer 75Hz refresh because my monitor makes an annoying squealing noise above 80Hz")

- if you do let the user change the refresh rate and resolution used by your application, follow the example set by Windows: show a dialog UI with a timer, so if the user doesn't click "Yes" by the time limit, you can assume they can't see your UI because their monitor has blanked out so then change the mode back to what it was.

- encourage users of your software to install monitor drivers if at all possible (assuming they can find some - you can create your own if you have the hardware specs for the monitor)


Always remember: unless you're writing a virus, your aim should be to make life as easy as possible for the person using your software "out of the box". A secondary aim should be to allow more experienced users to reconfigure your software.

I tend to uninstall anything which makes assumptions about things like refresh rates - if it's broken enough to get that wrong, what else has it assumed wrongly...

Thanks a lot for the informative post, S1CA.
I have decided to use adapter default as the default refreshrate
and the default value as the default presentationinterval also.

I made advanced users able to change both values in options.ini, and I'll include a bit of info about those values in the manual. This way beginners won't do anything stupid. :)