Are available pixel formats in wgl affected at all by the current screen resolution? Can screen resolution affect whether or not a particular format will be hardware accelerated?
j
I guess the general answer is “yes”,
although the answer for any particular
implementation may vary.
I could miss something in the spec, though,
in which case I’m looking forward to being
corrected 
The screen resolution affects the remaining size of offscreen memory on the board.
If you’re resolution gets too big you may not have enough space left for the back and depth buffers which can take the same amount of memory as the screen resolution each.
For example fullscreen 1600120032 bit double buffered and z-buffered on a 16 MB board will not be accelerated (needs 22 MB).
The color resolution or special modes like stereo or overlay affect the available features, too.
OK, so that means that if I want to enumerate some PFD’s for my program, I need to do it separately for every resolution, because the Pixel Formats that the driver reports it can handle will change with resolution? I guess I can handle that.
j
Yup. Pixelformat enumeration should always be done very carefully at start of program.
My recommendation is to avoid ChoosePixelFormat() for special requirements, because it ignores most of the good stuff.
Plus, some old video cards accelerate 16bit color only (for example, riva128, voodoo1/2/3, etc).
I dont know a single card that supports 8bit acceleration.
> I dont know a single card that supports 8bit acceleration.
Well, I know… 
at least - 3Dlabs GLINT MX based cards.
Well, as I said, I didn’t know about a color index accelerator. Now I know, but I would prefer to call the glint mx a “deccelerator” in the present times (thats an ooold card)…
Disclaimer:
I love 3dlabs, my first card was a permedia2 based one, and it had the most robust set of drivers I have seen on a consumer card yet.
> Well, as I said, I didn’t know about a color index accelerator.
Who said anything about color index mode?
It was RGB - 3:3:2
> I love 3dlabs, my first card was a permedia2 based one, and it had the most robust set of drivers I have seen on a consumer card yet.
Permedia2?
OpenGL drivers for it are just a crap - it don’t want to use software emulation for all unsupported in hw blending and tex. env. modes.
So, this chip was good - if you feel ok about using just simple additive and alpha blending with decal/modulate.
Serge K:
1: RGB 3:3:2
Ok, so that card is even weirder than what I thought. I guess quality is less than stellar with that!
2: About the permedia2:
Actually you are wrong. The drivers where excelent (stable and optimized) but the hardware lacked of some key blending modes. Some games like quake2, etc, did some hacking so lightmapping worked in the permedia2 (with monochromatic lightmaps). In fact, the same happened in Direct3D drivers.
[This message has been edited by coco (edited 01-11-2001).]