I'm working on the "not-so-fun" part of my SlimDX/D3D11-based engine which is responsible for gathering information about the local machine/hardware/CAPs so that settings can be properly adjusted to run applications on different end-users' machines. But I end up scratching my head on some things, especially where the SlimDX Documentation is itself "slim". I'm hoping some of you good folks can shed some light on the things that are bothering me.

1) Refresh Rates -
I threw this question into a past post, but I guess it was overlooked. I can't seem to find the article I once read in the DirectX Doc where it says one should NOT assume any refresh rate because it can cause serious problems. But a lot of examples for SlimDX use "new Rational(60, 1)" when creating ModeDescriptions? Obviously, not all monitors will have a 60/1 refresh rate. But what concerns me is *what* harm can be done if the refresh rate is off like that? My laptop, in native resolution w/ 32bpp color, has a refresh rate of about 59,700/1000. So what could the consequences potentially be if 60/1 or just 59/1 is used? I noticed the DisplayMonitor class doesn't even return a Rational for refresh rate, just a rounded off int (which is why I don't use it). The code I'm currently using goes through a lot of complication to get the exact refresh rates and properly initialize the swapchain with a valid, supported display mode. And I'm bothered by the prospect of problems if, for instance, someone changes the refresh rate to something incorrect or if a not-so-exact value is used.

2) DisplayModeEnumerationFlags??? -
I've written some higher-level classes to abstract away DXGI's details. I have things like a "GraphicsCard" and "Display" class which internally manage Adapter/Output instances and provide an intuitive interface to client-code. GraphicsCard, when instantiated, can automatically find all of the Displays attached to it and give back lots of useful data. It also builds a Key,Value collection of all Formats it supports and the FormatSupport flags value for each one. I'm liking the way it all looks; it works great, it's fast and it's clean and easy to use. But I'm not really done with the Display class though. I intend for it to construct an inner list of all display modes it supports for each supported format. So I have to use Output.GetDisplayModeList(...) internally to do so. But I can't find any information about what this DisplayModeEnumerationFlags parameter means. The doc is relatively blank, just like the one my mind is drawing. It just says it has to do with scanline/scaling, but what does that mean in this context? Is there are particular flag value you'd suggest I use when constructing my valid display modes list? I just don't understand what this does and what's the use of it, though I do see it gives different results if the flags are different.

3) Native Resolution -
Every monitor has a "native resolution", which is the optimal resolution it was designed to run at. I've been wondering, what's the cheapest and fastest way to determine what it is? Should I just sift through the display mode list I described constructing above and find the best one (which sounds slow)? Or is there a simpler way?

4) CPU Info -
I'm working out how I can get some detailed data about both the processors and HD. I know exactly how to do it in C/C++ and Intel x86 assembly language. I don't exactly know how it's done in C# without interop getting involved. I've been googling it but haven't found any decent results on it that aren't too dirty and incomplete/inaccurate (maybe you can show me one). Does the .NET framework provide any such functionality? Or would I be better off writing a DLL in C & ASM to do it fast and just interop my way through this problem? I hesitate to do that and introduce a new dependency for deployments...

That'll do for now, and help me sleep a little better at night if I know more about these issues. As always, thank you for your time, and thank you even more if you are able to help or point me in the right direction!

To get the preferred mode use:

DISPLAYCONFIG_TARGET_PREFERRED_MODE with the function DisplayConfigGetDeviceInfo(). I believe that you can get the LUID for the adapter from DXGI as well as the source id.

There is no managed wrapper for this that I know of, so you'll have to wrap it yourself. It's only available for win7. Prior to that I don't know of an API that will provide you with the preferred mode.


You're game doesn't have to run at the same rate as the vsync. You should decouple these. See the blog GafferOnGames for an article on running game updates async vs the refresh rate of the graphics. Just enumerate the device modes and use whatever is closes to 60hz, if that is what you prefer.

Don't worry about scaling and rotation for the flag. By default the api just provides modes that will work with the default rotation/scaling. Using the others is probably more complicated than necessary and will hardly ever, if ever, be used by your games.

Oh, I hope it didn't sound like I was criticizing the SlimDX team for things being undocumented! No, no... I realize it's a massive and complex project plus there is a lot of pertinent (native) Microsoft DirectX doc/info to go around. So forgive me if it sounded like I was taking a swing at the SlimDX Group. I wouldn't use SlimDX if I didn't think it to be an excellent wrapper made by an excellent team. Too much is at stake for me to use something I don't feel is of professional quality, and SlimDX ain't failed me yet. :)

Dieter, thanks for the answer. I did find out a kinda goofy looking "hack". You can use GetClosestMatchingMode(...) and pass it a crazy ModeDescription with unrealistically high values. It seems to always return the optimal ModeDescription supported, I don't know if that could end up biting me where it hurts in release builds somehow (don't really see how though; and I'd be happy if a system could return me a *valid* 10000x10000-x1000mHz ModeDescription that's not even the best possible, because I'd buy that rig! :D).

I did notice what I believe to be a problem with Output.GetClosestMatchingMode(...), however. The "inline" documentation tells me the parameter "ComObject device" CAN be null, but only modes who's Format matches the given Format will be returned. However, if I pass it null, it throws an exception and says "Parameter can not be null". Is something wrong with that? Or might I not be using it right? EDIT :: Note that it works fine if I give it a valid Device; only when I pass it null does it fail.

Thank you as well, Mike. And I've saved your code to take a look at when I get home. Since some interop seems inevitable, I may as well expand my project directories to facilitate some native libraries. I think I'm going to take some of my old C/assembly language code from a past project, bring it up to date and add some new stuff (and get rid of some things) for this task. And I'm sure I'll learn some new stuff from your code! Btw, I'm checking out the SlimDX source from SVN. I've been wanting to look at some things to understand what's going on. Hopefully that can answer future questions before they come to me.

Couldn't I check it out and build some new binaries? Or will I get something that's not in a completely working state?