¶Interesting DirectX changes in Windows 8 Developer Preview
I've managed to install the Windows 8 Developer Preview into a VirtualBox session, after spending a few hours in frustration trying to find a way around not having a dual layer DVD-R handy, and all of the suggested workarounds either requiring a large USB flash drive or not working on a UEFI boot machine. I'll just start by saying, yeah, Metro gets in the way so far. I'll leave it at that since it's clearly unfinished and I'd like to talk about other things.
Specifically, DirectX changes.
I've only had a couple of hours to dig into it, and so far, VirtualDub and Altirra run fine. So far, so good, nothing catastrophic like the display panes totally breaking *cough*Vista*cough*. One issue I have found is that the display code refuses to switch into DirectDraw mode. Not a big deal, since DirectDraw is basically neutered under WDDM anyway. (Amusingly, over time many of the DirectX APIs seem to be faring worse than their base Win32 counterparts.) The reason is a bit strange, though: in Windows 7, DirectDrawEnumerateEx() returns an entries for the primary monitor with both NULL and non-NULL monitor handles, whereas in Windows 8 DP the callback is only getting called once with a NULL HMONITOR. This is causing the current tip display code to fail to find a matching monitor. Easily worked around, but strange nevertheless.
The other issue is more interesting, and has to do with this debug trace:
VideoDisplay/DX9: 3D device is lame -- reason: raster caps check failed
My first thought was, OK, I'm running this in VirtualBox without proper video drivers. Of course the 3D device caps check is going to fail. Wait... what 3D device?
The answer is awesome: the software WARP device has become a full-fledged display driver. In DXCapsViewer, it shows up as "Microsoft Basic Display Driver" with d3d10warp.dll as the driver name. If you don't otherwise have a 3D hardware display driver, the WARP driver emulates one -- which explains why you can now get animated tilty window effects even on a frame buffer. Also, unlike in Windows 7, it is exposed to Direct3D9 apps as well. This is cool, because it means we're finally getting to the point where you can write 3D code that isn't too performance critical and rely on a reasonably performing software fallback to be available.
Well... almost. DXCapsViewer reveals a couple of omissions or bugs in the DX9 support compared to traditional 3D hardware. First, the reason VirtualDub doesn't work with it is that I made the mistake of actually checking caps bits, and for some reason WARP doesn't support dithering (D3DPRASTERCAPS_DITHER). Interestingly, the software renderer (!D3DDEVCAPS_HWRASTERIZATION) check passed. Okay, fine, hack out the dither check and it actually works. The second is that it's missing a couple of texture formats. X4R4G4B4 isn't a big loss, but not having A8L8 is a bigger problem. It's a useful format for two-channel purposes like normal map encoding, and VirtualDub uses it to upload chroma for displaying NV12 format video. This means that if you try running something heavier like a 3D graphics tool or a game, it'll probably work, but you might see some objects turn black and some other miscellaneous problems.