Resolution Question

Why the hell is that bad??? I nothing wrong with hard coding the screen res.

CEO Plunder Studios

Yeah, just look at Diablo 2

It''s been my experience that hardcoding important constants in general is a very bad idea. At the very least they should be read in from some sort of ini file, this way if you want to change just 1 variable, you wont have to re-compile to see the results.


As far as the directX code i''m using to get the possible resolutions; I''m calling GetAdapterModeCount(D3DADAPTER_DEFAULT) to get the number of modes possible, then looping from 0 to that number, checking the resolutions of each using the
EnumAdapterModes function and using that info to select the most proper resolution, or compile a list for the user to select from.

i was just wondering if it would be faster/better to use windows functions, because i remember doing something like that in Visual Basic, and it didnt seem as complicated using the windows functions.

In the old days not all videomodes were accelerated, ie you had to be running in 800x600x16 to get hardware acceleration. Thus, it was important to ask DX what it supported rather than asking Windows what your videocard could do. With today''s hardware, I suppose all "common" video modes are hardware accelerated; however, there''s the issue of backbuffer formats. Your card, for example, may support either X1R5G5B5 or R5G6B6, but it''s much easier to determine which one is supported using DX than to do so using Win32, at least in my opinion. Then you can check device caps during D3D device enumeration to see if you should ask for hardware/mixed/software vertexprocessing. So, unless you have a very good reason to not use it, you should go with DX enumeration.