   EnumAdapterModes changes
  I''m looking into the changes made to enumadaptermodes in DX9, and I''m wondering wether I''m misunderstanding the SDK help, or if it''s just wrong.In the Converting to DX9 article, under "EnumAdapterModes Changes", it says the following:quote:The application specifies a pixel format and the enumeration is restricted to those display modes that exactly match the format. The following is a list of the allowed formats: D3DFMT_X8R8G8B8D3DFMT_A8R8G8B8D3DFMT_A2B10G10R10D3DFMT_X1R5G5B5D3DFMT_A1R5G5B5D3DFMT_R5G6B5Hang on.. Display modes that match Alpha formats? Surely that can''t be right? Shouldn''t the list consist solely of D3DFMT_X8R8G8B8, X1R5G5B5 and R5G6B5? After all, those are the only allowable display formats, right?But hang on, the sdk continues:quote:Enumeration is equivalent for alpha and nonalpha versions of the same format. The returned FORMAT member of D3DDISPLAYMODE will always be filled with the same format supplied by the application. Ah. So... If I supply the function with A8R8G8B8, it''ll return modes supporting X8R8G8B8? Let''s run a quick test.. No, it doesn''t. EnumAdapterModes fails when supplying it with A8R8G8B8, but it succeeds when supplying it X8R8G8B8.Oh yeah, another weird thing in that same article:quote:This method treats 565 and 555 as equivalent, and returns the correct version in the Format.Nope. Also not true. Enumerating with 565 works, but enumerating with x1R5G5B5 fails. So it does -not- treat them as equivalent. So... What is up with that? The Enumeration is apparently -not- equivalent for alpha and nonalpha versions of the same format, nor is 565 equivalent to 555. So why does the SDK claim it is? And why does it list alpha formats as possible display formats?Anyone? 
  Hmm.. So basically, everyone is just using this without really knowing what''s going on? 