ASM Community

Hi
This snippet gives you a good string identifier for each adapter

      mov edi, $ICall(.pID3D::IDirect3D9.GetAdapterCount)
      xor ebx, ebx
      .while ebx < edi
        ICall .pID3D::IDirect3D9.GetAdapterIdentifier, ebx, 0, addr AdapterInfo
        @invoke wsprintf, addr bBuffer, "%u - %s", ebx, addr AdapterInfo.Description
        invoke SendDlgItemMessage, .hWnd, IDC_DXS_ADAPTERS, CB_ADDSTRING, 0, addr bBuffer
        ...
        inc ebx
      .endw

Regards

Biterider

Tried prior to the DX update, nothing. After, nothing... methinks some error-handling is in order. ;)

AMD 4000+ Dual, WinXP Pro x64 SP2, GeForce 8600GTS, dual monitors.

You should. Majority of people don't have Vista and wait for Windows 7 (or don't plan to switch at all in the nearest furute). And even after Windows 7 is out there will still be many users using XP. D3D9 isn't going to die very soon :)

About monitor: I don't remember exactly (and for some strange reason I can't find my app where I do it -- Murphy doesn't like me) but from what I do remember is that you have to use D3D9->GetAdapterMonitor and Winapi's GetMonitorInfo and EnumDisplayMonitors. Then you have to play correctly with RECT structures, IIRC. The names you get aren't guaranteed to be real names of outputs but at least they give users some way to distinguish between the options they get.

It works in windowed mode but not in fullscreen. When in fullscreen mode, minimizing and then maximizing stops the rendering.

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

I have found the app. I have also attached the image showing how it looks like on my machine.

Here is the relevant code:

INT __cdecl _tmain(INT argc, _TCHAR* argv[]) {
  union {
    MONITORINFOEX mie;
    TCHAR dummy[(sizeof(MONITORINFOEX)+1)];
  };
  IDirect3D9 *d3d9;
  UINT adcnt, i;
  HMONITOR hm;

  if (!(d3d9 = Direct3DCreate9(D3D_SDK_VERSION))) {
    _tprintf(TEXT("Direct3DCreate9 failed!\n"));
    return 1;
  }

  if ((adcnt = d3d9->GetAdapterCount())) {
    for (i = 0; i < adcnt; i++) {
      _tprintf(TEXT("adapter %u: "), i);
      if ((hm = d3d9->GetAdapterMonitor(i))) {
        mie.cbSize = sizeof(mie);
        dummy = 0;
        if (GetMonitorInfo(hm, &mie)) {
          _tprintf(TEXT("%s"), &mie.szDevice);
          if (mie.dwFlags & MONITORINFOF_PRIMARY) {
            _tprintf(TEXT(" (PRIMARY)"));
          }
          _tprintf(TEXT("\n"));
        }
        else {
          _tprintf(TEXT("(GetMonitorInfo failed!)\n"));
        }
      }
      else {
        _tprintf(TEXT("<null>\n"));
      }
    }
  }

  d3d9->Release();
  d3d9 = NULL;

	return 0;
}

Note that the primary display doesn't have to be the first one.

I guess your only option is WMI but this is completely black magic to me. I've seen some examples on the Internet showing nice monitor names retrieved using WMI.

Thanks, but vendor-specific solutions are exactly what I want to avoid.
I think the answer lies somewhere in this part of the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY
That's where the known monitors are listed, with their descriptive names. Now I have to somehow relate that to the DX info.

Well, I often develop on my laptop, with an Intel graphics chip :)
If monitor drivers aren't installed, I guess it's fine to just have 'default monitor' or just '\\DISPLAY1' or such. But in most cases, drivers are installed, because lots of them are either bundled with Windows, or available on Update.

Intel has the biggest marketshare, and will get even bigger when Larrabee is out. And then there are S3 and Matrox. I want to support them all.

Well, I've found something...

With EnumDisplayDevices() you can get the monitor name. Normally you'd use it to enumerate by index. Then it will just give you all \\.\DISPLAYx device names and corresponding adapter names.
However, if you pass the device name, and pass index 0, it will instead give you more info about that device, including the actual monitor name in the DeviceString, rather than the adapter name.

So what I do now is simple: I first get the hMonitor, then use GetMonitorInfo() to get the \\.\DISPLAYx device name, then use EnumDisplayDevices() to resolve it to the actual monitor name.

Works for both D3D9 and D3D10/11, because with DXGI you also get the \\.\DISPLAYx name of the output, which you'll plug into EnumDisplayDevices().

It should return the exact same monitor names as what you see in the display properties in Control Panel (the regular Windows control panel that is).
My TV uses standard s-video, so I only get "Generic P&P monitor" or something.
I suppose if your TV has a VGA, DVI or HDMI connector, it can use the DDC protocol to identify itself, and have Windows automatically install the proper .inf file for the monitor, to give it a descriptive name.
So I don't think there's any way that a hardware-specific solution would get more info than standard Windows.

This is solved now, with the name that EnumDisplayDevices() displays.



I've had a small look at this problem, and it seems to be specifically related to DX9 and multiple displays.
In DX10, the rendering stops when the window loses focus. This is by design (originally I wrote the code for a single display, and losing focus meant that you alt-tabbed away from the application, at which point I didn't want my application to hog the CPU. Alt-tabbing back into the application would bring it back to life). If the window regains focus, it continues rendering again.

In DX9 however, it seems that there's more going on. If I so much as click on the desktop on the other monitor, the window loses its fullscreen state and goes back to windowed mode. It doesn't know how to recover from this situation, because it should never happen (it doesn't, on a single display. The window is still 'fullscreen', even though it's not visible).
In short, I don't know what causes it, or how to fix it. There is code in my application to automatically reset the device when required. This is why resizing and alt-enter to switch between fullscreen and windowed mode just works. But somehow it doesn't recover from this situation.

I don't feel like wasting more time on it, because it only happens in DX9. I want to concentrate on DX11 from now on, DX9 is only there for legacy support and for that it's 'good enough' right now, the problem can easily be avoided. But if someone knows a fix, I might implement it.



Solved, the aspect-ratio fields in the initialization dialog are now used to create a perspective matrix.