alpha混合听上去很神秘，实际非常简单，其作用就是要实现一种半透明效果。假设一种不透明东西的颜色是A，另一种透明的东西的颜色是B，那么透过B去看A，看上去的颜色C就是B和A的混合颜色，可以用这个式子来近似，设B物体的透明度为alpha(取值为0-1，0为完全透明，1为完全不透明)

R(C)=alpha*R(B)+(1-alpha)*R(A)
G(C)=alpha*G(B)+(1-alpha)*G(A)
B(C)=alpha*B(B)+(1-alpha)*B(A)

　　R(x)、G(x)、B(x)分别指颜色x的RGB分量。看起来这个东西这么简单，可是用它实现的效果绝对不简单，应用alpha混合技术，可以实现出最眩目的火光、烟雾、阴影、动态光源等等一切你可以想象的出来的半透明效果。

　　火光、烟雾的效果是事先做好一个火或雾的图和一个alpha通道图(用过Photoshop的人都该知道什么是alpha通道)，画上去的时候每点每点计算，得到的就是火光掩映的效果。雾化效果在3D里还需要模糊一下，在这里就免了，本来alpha混合就有不小的计算量了，算法再不优化再加上模糊或其它的一些什么原因，那么你就是在看幻灯片了。(关于优化，网上见仁见智，我再找时候再讲)。

　　动态光源，听起来高深的一塌。那我先讲一下阴影，这个就简单了，以往的游戏也有阴影(象《仙剑》)，不过我们把它升一下级，从不透明变成半透明而已。就是把一个影子图放在地表上面作alpha混合(而且可以简化，因为影子的alpha值可以是一定的，这样就可以大幅提高计算速度)就OK了。

　　该讲动态光源了。我们把没有光源的地方想象成一张黑幕蒙在屏幕上，没光也就什么都看不到。那么我们就加上一个光源，相当于在黑幕上挖了一个洞，这个洞的大小就是被照亮的范围，现在我们可以看到下面的东西了。但现在这个效果说是光源，倒不如说是个窗户，要显得象光源，就要让光源的中心最亮，逐渐向四周暗下去，最后到什么都看不见，这才象个光源。具体实现就是alpha混合啦，蒙版的颜色是黑，中心alpha值为0，完全透明，到光源的尽头alpha值为1，完全不透明，成果就是这个样子，象这么回事吧！光源做好了，动态的光源就是实时生成一个动态的alpha蒙版，然后盖上去就行了。

　　不难吧！游戏里(其实也不只游戏，好多算法也是这样)的一些技术听起来很玄，说通了也就是那么回事，只不过不是一下子就能想到就是了。

　　Diablo里面就大量应用了alpha混合技术(至少我看上去象)，那些眩目的魔法产生出来的半透明效果，还有乱飞的火球照亮迷宫，每个火球也就是个小的光源，一堆光源产生出来的蒙版(就是对应的alpha相加，超过255就截断)再蒙上去。(真正的光源应该是这样的：当alpha值超过255时，alpha=alpha-255，alpha是一个Byte时也就是回绕，同时该点蒙版的色彩变为白色，这才是对的，不过简单起见，还是原来那样就可以了)。

欧拉角是瑞士数学家莱昂哈德·欧拉（Leonhard Euler）用来描述刚体在三维空间中取向的方法。简单来说，就是任何一个物体的取向，都可以用3个有次序的旋转角度来表示。

欧拉在三维空间中定义了一个静止不动的参考系，即惯性系。还定义了一个运动的坐标系，即物体坐标系。惯性系与物体坐标系的区别在于，当物体取向发生改变之后，物体坐标系也随之改变，而惯性系却不变。

例如，我们认为北极星的位置对于地球上的任意观察点都是不变的，因此可以看作一个静止的参考系。而基于公路上一辆行驶的汽车的坐标系，因为汽车的转弯而不断改变，是一个物体坐标系。

欧拉角的三个旋转是绕物体坐标系的三个轴复合形成。为何不使用惯性系？因为物体坐标系在数学处理上是简单的。为了描述一架飞机的取向，定义航偏角为yaw, 俯仰为pitch, 横滚为roll。假如分别使用矩阵I1, I2, I3来表示这三个角度，那么飞机绕自身先转yaw角，再绕pitch角，最后绕roll角的结果可用I3*I2*I1来表示。 有关矩阵，看这里 。

通常来说，一个物体的取向用欧拉角来表示是简单有效的。但是在某种特殊的情况下，欧拉角将失效，形成所谓的“万向节死锁”。

一个简单直观的例子是炮塔模型。假设地面上的一个炮塔有两个旋转轴：Y垂直于地面，使炮塔可以平行地面360度旋转（正北设为0度）；X平行于地面，使炮口可以绕着它上下90度旋转（平行地面使设为0度）。现在，天空中的任意一点就可以使用两个坐标的度数来表示了！

这时，一架敌机从正东面飞来，我们转动炮塔对准它，目前的坐标是（10,90）。因为飞机飞行方向不变，所以Y固定为90，而X由于飞机距离的接近而增大。当飞机恰好飞到炮塔顶端时，即X的角度也达到90度时，飞机忽然向南飞行！我们必须立即改变炮塔朝向，否则即将都丢失目标。但是我们发现，无论是转动X轴还是Y轴，我们都无法让炮塔转向南方了，即炮塔在此时丢失了一个自由度！

为什么不把Y转动到180度的位置继续跟踪呢？注意此时炮塔的状态: 炮口已经对准炮台的正上方, 平行于Y轴，无论Y轴怎样转动，炮口都改变不了朝向的, 即炮台的物体坐标系不会变化了。能转动的只有X轴，但是这样一来，炮口又回到东面了。

欧拉角的万向节死锁就是这样：我们依次绕物体坐标系的X轴、Y轴、Z轴旋转，当Y轴旋转了90度之后，Z就会指向原来的X轴。这样一来，我们事实上只绕了X轴和Y轴两个轴旋转，第三根轴的自由度就丢失了！(值得指出的是，我们在描述的时候使用的是世界坐标系的x, y, z轴，但是旋转的时候却是使用绕物体的)

万向锁的一个有趣实验是当先把飞机Yaw 45度，再Pitch 90度，与先Pitch 90度，再Roll 45度的结果完全相同。 这个现象也叫欧拉角的别名现象（同一个惯性系下同一个值有不同的表示方法），这也是很糟糕的。

正因为欧拉角在三维空间中有死锁的问题，所以科学家寻找了新的表示空间取向的方法。以后再详细说明。

理解：万向节死锁是由于旋转后产生自由度丢失而产生的问题。解决办法是通过四元数

像素格式解析

　　像素格式描述了像素数据存储所用的格式。定义了像素在内存中的编码方式。下面的像素格式 (PF_*) 类型定义了：
 

　　本地格式 (PF_A8R8G8B8 以及其他大量的不同的类型)

　　这意味着在内存中使用了本地储存方式（big endian或者little endian，包括16，24，，32位）的整形数据。同时意味着可以把PF_A8R8G8B8格式的图片看作一个32位的整形数组，在16进制表现为0xAARRGGBB。这些字母的意义我们在稍后会提供
      （由于CPU的不同，整形的存储形式不同。直接写内存的时候需要注意）。

　　位组格式Byte formats(PF_BYTE_*)

　　在这种格式下每个通道对应一个byte，通道在内存理的组织方式和格式名称定义的相同。例如PF_BYTE_RGBA格式的像素包含了四个byte，一个对应红色，一个绿色，一个蓝色，以及一个alpha通道。

　　Short格式(PF_SHORT_*)

　　在这种格式下每个通道对应一个unsigned short数据(16 bit整形)，通道在内存理的组织方式和格式名称定义的相同。例如PF_BYTE_RGBA格式的像素包含了四个unsigned short数据，一个对应红色，一个绿色，一个蓝色，以及一个alpha通道。

　　Float16 格式(PF_FLOAT16_*)

　　在这种格式下每个通道对应一个16 bit浮点数，通道在内存理的组织方式和格式名称定义的相同。例如PF_BYTE_RGBA格式的像素包含了四个16 bit浮点数数据，一个对应红色，一个绿色，一个蓝色，以及一个alpha通道。16 bit浮点数也被称为半浮点（half float），非常类似于IEEE 对32bit单精度浮点数标准，只不过它只有5个exponent位和10个mantissa位而已。值得注意，这并不是一个标准的C++数据，CPU对其支持也不够好，不过GPU却能如同处理32bit浮点数一样高效的处理它。

　　Float32格式(PF_FLOAT32_*)

　　在这种格式下每个通道对应一个32 bit浮点数，通道在内存理的组织方式和格式名称定义的相同。例如PF_BYTE_RGBA格式的像素包含了四个32 bit浮点数数据，一个对应红色，一个绿色，一个蓝色，以及一个alpha通道。再C++中，这个数据就是普通的float。just “float”。

压缩格式formats (PF_DXT[1-5])

S3TC压缩纹理格式。

颜色通道介绍

　　颜色通道中R,G,B,A,L 以及 X 的意义是：

　　R

　　红色成分，通常范围从0.0（没有红色）到1.0（全部的红色）。

　　G

　　绿色成分，通常范围从0.0（没有绿色）到1.0（全部的绿色）。

　　B

　　蓝色成分，通常范围从0.0（没有蓝色）到1.0（全部的蓝色）。

　　A

　　alpha（不透明度）成分，通常范围从0.0（完全透明）到1.0（不透明）。

　　L

　　亮度成分，通常范围从0.0（黑暗）到1.0（全白）。最终这个成分会被分散到RGB每个中完成最终的图像效果。

　　X

　　这个是被系统忽略的成分。

　　对于RGBL通道来说，默认的情况下设置为0。而Alpha通道却不同，在默认的情况下被设定为1，代表不透明。

******************************************************************************************

全部像素格式

　　当前版本的Ogre支持下列像素格式：

　　位组格式

　　PF_BYTE_RGB, PF_BYTE_BGR, PF_BYTE_BGRA, PF_BYTE_RGBA, PF_BYTE_L, PF_BYTE_LA, PF_BYTE_A

　　Short格式

　　PF_SHORT_RGBA

　　Float16 格式

　　PF_FLOAT16_R, PF_FLOAT16_RGB, PF_FLOAT16_RGBA

　　Float32 格式

　　PF_FLOAT32_R, PF_FLOAT32_RGB, PF_FLOAT32_RGBA

　　8 bit 本地格式

　　PF_L8, PF_A8, PF_A4L4, PF_R3G3B2

　　16 bit 本地格式 '

　　PF_L16, PF_R5G6B5, PF_B5G6R5, PF_A4R4G4B4, PF_A1R5G5B5

　　24 bit 本地格式

　　PF_R8G8B8, PF_B8G8R8

　　32 bit 本地格式

　　PF_A8R8G8B8, PF_A8B8G8R8, PF_B8G8R8A8, PF_R8G8B8A8, PF_X8R8G8B8, PF_X8B8G8R8, PF_A2R10G10B10 PF_A2B10G10R10

　　压缩格式

　　PF_DXT1, PF_DXT2, PF_DXT3, PF_DXT4, PF_DXT5

******************************************************************************************

像素格式管理

　　1、Windows下的调色板

　　OpenGL可以使用16色、256色、64K和16M真彩色。真彩模式下不需要调色板，而在16色模式下根本不可能得到较为满意的效果，因此对OpenGL而言，调色板只有在256色模式下才有意义。

　　我们知道，Windows把调色板分为系统调色板和逻辑调色板。每个应用程序都拥有一套自己的逻辑调色板（或使用缺省调色板），当该应用程序拥有键盘输入焦点时可以最多使用从16M种色彩中选取的256种颜色（20种系统保留颜色和236种自由选取的颜色），而失去焦点的应用程序可能会有某些颜色显示不正常。系统调色板由Windows内核来管理，它是由系统保留的20种颜色和经仲裁后各个应用程序设置的颜色组成，并与硬件的256个调色板相对应。应用程序的逻辑调色板与硬件的调色板没有直接的对应关系，而是按照最小误差的原则映射到系统调色板中，因此即使应用程序自由选取256种不同颜色构成自己的逻辑调色板，也有可能某些颜色显示到屏幕上时是一样的。

　　当应用程序的窗口接收到键盘输入焦点时，Windows会向它发送一条WM_QUERYNEWPALETTE消息，让它设置自己的逻辑调色板，此时Windows会在系统调色板中尽量多地加入该应用程序需要的颜色，并生成相应的映射关系。接着Windows会向系统中所有的覆盖型窗口和顶级窗口（包括拥有键盘输入焦点的窗口）发送一条WM_PALETTECHANGED消息，让它们设置逻辑调色板和重绘客户区，以便能更充分地利用系统调色板，已拥有键盘输入焦点的窗口不应再处理这条消息，以避免出现死循环。

　　2、OpenGL的颜色表示与转换

　　OpenGL内部用浮点数来表示和处理颜色，红绿蓝和Alpha值这四种成份每种的最大值为1.0，最小值为0.0。在256色模式下，OpenGL把一个像素颜色的内部值按线性关系转换为8比特（Bit）来输出到屏幕上，其中红色占最低位的3比特，绿色占中间的3比特，蓝色占最高位的2比特，Windows将这个8比特值看作逻辑调色板的索引值。例如OpenGL的颜色值（1.0，0.14，0.6667）经过转换后二进制值为10001111（红色为111，绿色为001，蓝色为10），即第143号调色板，该调色板指定的颜色的RGB值应与（1.0，0.14，0.6667）有相同的比率，为（255，36，170），如果不是该值，那么显示出来的颜色就会有误差。

　　3、调色板的生成算法

　　很明显，OpenGL输出的8比特值中直接表明了颜色的组成，为了使图形显示正常，我们应以线性关系来设置逻辑调色板，使其索引值直接表明颜色的组成。因此生成调色板时，把索引值从低位到高位分成3-3-2共三个部分，将每一部分映射到0-255中去，这样3比特映射为｛0，36，73，109，146，182，219，255｝，2比特映射为｛0，85，170，255｝，最后把三部分组合起来成为一种颜色。

　　经过上面的处理后，256种颜色均匀分布在颜色空间中，并没有完全包含系统保留的20种颜色（只包含了7种），这意味着将会有数种颜色显示成一样，从而影响效果。一个较好的解决办法是按照最小均方误差的原则把13种系统颜色纳入到逻辑调色板中。

　　从原理上来说，并非一定要使用线性映射，还可以用其它一些映射关系，如加入Gamma校正以便更能符合人眼的视觉特性，不过这些映射关系应用得并不广泛，在此不再讨论。

　　像素格式设置

　　像素格式是OpenGL窗口的重要属性，它包括是否使用双缓冲，颜色位数和类型以及深度位数等。像素格式可由Windows系统定义的所谓像素格式描述子结构来定义（PIXELFORMATDESCRIPTOR），该结构定义在windows.h中。

　　在该结构中包含有26个属性信息，其形式为：

　　typedef struct tagPIXELFORMATDESCRIPTOR

　　{

　　WORD nSize;

　　WORD nVersion;

　　DWORD dwFlags;

　　BYTE iPixelType;

　　BYTE cColorBits;

　　BYTE cRedBits;

　　BYTE cRedShift;

　　BYTE cGreenBits;

　　BYTE cGreenShift;

　　BYTE cBlueBits;

　　BYTE cBlueShift;

　　BYTE cAlphaBits;

　　BYTE cAlphaShift;

　　BYTE cAccumBits;

　　BYTE cAccumRedBits;

　　BYTE cAccumGreenBits;

　　BYTE cAccumBlueBits;

　　BYTE cAccumAlphaBits;

　　BYTE cDepthBits;

　　BYTE cStencilBits;

　　BYTE cAuxBuffers;

　　BYTE iLayerType;

　　BYTE bReserved;

　　DWORD dwLayerMask;

　　DWORD dwVisibleMask;

　　DWORD dwDamageMask;

　　} PIXELFORMATDESCRIPTOR;

　　各变量的含义如下：

　　nSize：该结构所占内存空间。

　　nVersion：版本号，当前为1。

　　dwFlags：指定像素格式属性，可选参量如表1.1所示。

　　 像素格式属性

　　标识符 解释

　　PFD_DRAW_TO_BITMAP 支持内存中绘制位图

　　PFD_DRAW_TO_WINDOW 支持屏幕绘图

　　PFD_DOUBLEBUFFER 支持双缓冲

　　PFD_CENERIC_FORMAT 指定选择GDI支持的像素格式

　　PFD_NEED_PALETTE 指定需要逻辑调色板

　　PFD_NEED_SYSTEM_PALETTE 指定需要硬件调色板

　　PFD_STEREO NT不支持

　　PFD_SUPPORT_OPENGL 支持OpenGL

　　PFD_SUPPORT_GDI 支持GDI，此时不可使用PFD_DOUBLEBUFFER

　　iPixelType：像素颜色模式，可选项为PFD_TYPE_RGBA或PFD_TYPE_INDEX，分别对应于RGBA模式和颜色索引模式。

　　cColorBits：指定颜色的位数。

　　cRedBits：采用RGBA模式时，红色组分占用位数。

　　cRedShift：采用RGBA模式时，红色组分偏移量。

　　cGreenBits：采用RGBA模式时，绿色组分占用位数。

　　cGreenShift：采用RGBA模式时，绿色组分偏移量。

　　cBlueBits：采用RGBA模式时，蓝色组分占用位数。

　　cBlueShift: 采用RGBA模式时，蓝色组分偏移量。

　　cAlphaBits：采用RGBA模式时，Alpha组分占用位数。

　　cAlphaShift：采用RGBA模式时，Alpha组分偏移量。

　　cAccumBits：指定累积缓冲区表示一个像素所用位数。

　　cAccumRedBits：指定累积缓冲区表示红色组分占用位数。

　　cAccumGreenBits：指定累积缓冲区表示绿色组分占用位数。

　　cAccumBlueBits：指定累积缓冲区表示蓝色组分占用位数。

　　cAccumAlphaBits：指定累积缓冲区表示Alpha组分占用位数。

　　cDepthBits：指定深度缓冲区表示一个像素所用位数。

　　cStencilBits：指定模板缓冲区表示一个像素所用位数。

　　cAuxBuffers：指定辅助缓冲区，Windows9x、NT不支持。

　　iLayerType：Windows9x、NT下只能是PFD_MAIN_PLANE。

　　bReserved：＝0。

　　dwLayerMask：指定覆盖层的屏蔽，Windows9x、NT不支持。

　　dwVisibleMask：Windows9x、NT不支持。

　　dwDamageMask：Windows9x、NT不支持。

　　Windows提供了四个像素格式管理函数，分别介绍如下：

　　（1） int ChoosePixelFormat(HDC hdc,

　　PIXELFORMATDESCRIPTOR *ppdf)

　　该函数比较传过来的像素格式描述和OpenGL支持的像素格式，返回一个最佳匹配的像素格式索引。该索引值可传给SetPixelFormat为DC设置像素格式。返回值为0表示失败。

　　在比较像素格式时，匹配优先级顺序为像素格式描述子结构中的下述各域：

　　dwFlags－>cColorBits－>cAlphaBits－>cAccumBits

　　－>cDepthBits－>cStencilBits－>cAuxBuffers－>iLayerType

　　硬件支持的像素格式优先。

　　（2） int DescribePixelFormat(HDC hdc, int iPixelFormat, UINT nBytes,

　　LPPIXELFORMATDESCRIPTOR *ppfd)

　　该函数用格式索引iPixelFormat说明的像素格式来填写由ppfd所指向的像素格式描述子结构，利用该函数可以枚举像素格式。

　　（3） int GetPixelFormat(HDC hdc)

　　该函数用于获取hdc的格式索引。

　　（4） BOOL SetPixelFormat(HDC hdc, int iPixelFormat,

　　LPPIXELFORMATDESCRIPTOR *ppfd)

　　该函数用格式索引iPixelFormat来设置hdc的像素格式。在使用该函数之前应该调用ChoosePixelFormat来获取像素格式索引。另外，OpenGL窗口风格必须包含WS_CLIPCHILDREN和WS_CLIPSIBLINGS类型，否则设置失败。

　　应该注意的是ChoosePixelFormat函数并不一定返回一个最佳的像素格式值，可以利用DescribePixelFormat来枚举系统所支持的所有像素格式。OpenGL的通常支持24种不同的像素格式，如果系统安装了OpenGL硬件加速器，它可能会支持其它的像素格式。

像素格式笔记

　　NUKE:

　　nuke的图像数据保存在channel中，我们只需要用到其中的r,g,b三个channel。这三个channel是相互独立的，可以分别从中读取数据，每一次可以读取图像的一行像素。这样看来，最合理的线性存储方式就是每个channel的数据作为一组来保存，即：RRRR...RRRRGGGG...GGGGBBBB...BBBB的形似。

　　FFMPEG:

　　ffmpeg支持的编码比较多，如果按照像素格式来分，主要有两类，一类是是RGB，另一类是YUV。对于影像类编码，比如xvid/mpeg4之类，颜色模式只能是YUV，甚至仅仅支持yuv420p这一种。因为要考虑到与nuke相结合，这里只看rgb像素格式中的rgb24。rgb24的线性格式为:RRRR...RRRRGGGG...GGGGBBBB...BBBB，可以很方便的和nuke中的channel数据结合。

　　ffmpeg提供了一个函数可以在各种像素格式之间转换。yuv420p的Cr和Cb分量只有Y分量大小的一半，因此需要的空间只有rgb24的2/3。

　　libquicktime:

　　libquicktime中没有与上面RGB24一致的原始rgb格式，有一种rgb888格式。其线性格式为:RGBRGBRGB...。libquicktime在保存帧的时候也要先将rgb转换为yuv，不过这个过程是自动完成的。

　　从rgb24到rgb888的转换：

　　pFrameBufferLinear[y*w*3+3*x] = pFrameRGB_r[Y*w+i]; //R

　　pFrameBufferLinear[y*w*3+3*x+1] = pFrameRGB_g[Y*w+i]; //G

　　pFrameBufferLinear[y*w*3+3*x+2] = pFrameRGB_b[Y*w+i]; //B

WPF图像像素格式

　　在WPF中，图像的像素格式较之于GDI+中有不少变化。比如新增了CMYK印刷通道的支持，对灰度图片的灰阶支持也有长足的进步，在颜色空间方面，新增了scRGB颜色空间，使图像的色彩处理能力有很大的提高。

　　为了方便加深了解，我将它们按格式性质和色彩空间大致进行了分类。比如将Gray类的放在一起，将Index类的又放在一起....

　　(1) BlackWhite：

　　用于显示黑白两种色值的像素格式（非黑即白）。

　　(2) Gray2：

　　2BPP（Bits Per Pixel，位/像素）的灰色通道。允许四种灰阶。

　　(3) Gray4：

　　4BPP的灰度通道，允许16种灰阶值表示灰色。

　　(4) Gray8：

　　显示8BPP的灰度通道，允许256种灰阶值表示灰色。

　　(5) Gray16：

　　16BPP的灰色通道，最多允许65536种灰阶值表示灰色。这种格式的Gamma是1.0。

　　(6) Gray32Float：

　　32BPP的灰度通道，允许超过40亿灰阶。此格式的Gamma值是1.0。

　　(7) Indexed1：

　　指定2种颜色作为调色板的像素格式。

　　(8) Indexed2：

　　指定4种颜色作为调色板的像素格式。

　　(9) Indexed4：

　　指定16种颜色作为调色板的像素格式。

　　(10) Indexed8：

　　指定256种颜色作为调色板的像素格式。

　　(11) Bgr24：

　　Bgr24像素格式是一种采用24BPP的sRGB格式。每个颜色通道（蓝色blue, 绿色green, 红色red)各占8BPP（位/像素）。

　　(12) Bgra32：

　　Bgra32像素格式是一种32BPP的sRGB格式。每个颜色通道（蓝色blue, 绿色green, 红色red)各占8BPP（位/像素），与Bgr24不同的是，它还有用于表现不透明度的alpha通道（8BPP）。

　　(13) Bgr101010：

　　Bgr101010像素格式是一种采用32BPP（位/像素）的sRGB格式。每个颜色通道（蓝色blue, 绿色green, 红色red)各占10BPP（位/像素）。

　　(14) Bgr32：

　　Bgr32像素格式是一种采用32BPP（位/像素）的sRGB格式。与Bgr101010格式不同的是，它的每个颜色通道（蓝色blue, 绿色green, 红色red)各占8BPP（位/像素）。

　　(15) Bgr555：

　　Bgr555也是一种sRGB格式，它采用16BPP（位/像素）. 它的每个颜色通道（蓝色blue, 绿色green, 红色red)各占5BPP（位/像素）。

　　(16) Bgr565：

　　Bgr565像素格式是一种16BPP（位/像素）的sRGB格式。它的每个颜色通道（蓝色blue, 绿色green, 红色red)分别占5BPP，6BPP，5BPP（位/像素）。

　　(17) Pbgra32：

　　采用32BPP的一种基于sRGB的像素格式。每个颜色通道(蓝色blue, 绿色green, 红色red，Alpha通道)各占8BPP（位/像素）。每种颜色通道是经过与Alpha值预处理之后的。

　　(18) Prgba64：

　　是一种基于sRGB格式，采用64BPP。每个颜色通道(蓝色blue, 绿色green, 红色red，Alpha通道)各占32BPP（位/像素）。每种颜色通道是经过与Alpha值预处理之后的。这种格式的Gamma是1.0。

　　(19) Rgb24：

　　是一种基于sRGB格式，采用24BPP。每个颜色通道(蓝色blue, 绿色green, 红色red)各占8BPP（位/像素）。

　　(20) Rgb48：

　　是一种基于sRGB格式，采用48BPP。每个颜色通道(蓝色blue, 绿色green, 红色red)各占16BPP（位/像素）。这种格式的Gamma是1.0。

　　(21) Rgba64：

　　是一种基于sRGB格式，采用64BPP。每个颜色通道(蓝色blue, 绿色green, 红色red，Alpha通道)各占16BPP（位/像素）。这种格式的Gamma是1.0。

　　(22) Rgb128Float：

　　是一种基于ScRGB格式，采用128BPP。每个颜色通道各占32BPP（位/像素）。这种格式的Gamma是1.0。

　　(23) Rgba128Float：

　　是一种基于ScRGB格式，采用128BPP。每个颜色通道(蓝色blue, 绿色green, 红色red，Alpha通道)各占32BPP（位/像素）。这种格式的Gamma是1.0。

　　(24) Prgba128Float：

　　是一种基于ScRGB格式，采用128BPP。每个颜色通道(蓝色blue, 绿色green, 红色red，Alpha通道)各占32BPP（位/像素）。每种颜色通道是经过与Alpha值预处理之后的。这种格式的Gamma是1.0。

　　(25) Cmyk32：

　　用于表现印刷色格式，采用32BPP，共四个颜色通道即C、M、Y、K（青色Cyan, 品红Magenta, 黄色Yellow和黑色blacK)，各占8PP。

OpenGL窗口渲染

　　表述像素格式：PIXELFORMATDESCRIPTOR

　　在OpenGL对窗口渲染之前，必须根据渲染需要对窗口进行配置。

　　需要硬件渲染还是软件渲染？

　　渲染使用单缓冲还是双缓冲？

　　是否需要深度缓冲区？

　　是否需要模板、目标Alpha或积累缓冲区？

　　当为窗口设置这些参数之后，就无法对它们进行修改。为了从一个只有深度缓冲和颜色缓冲区的窗口切换到一个带有模板缓冲区的窗口，必须首先销毁第一个窗口，然后根据需要重新创建一个窗口。

　　说明：

　　在OpenGL对窗口渲染之前，必须根据渲染需要对窗口进行配置。

　　需要硬件渲染还是软件渲染？

　　渲染使用单缓冲还是双缓冲？

　　是否需要深度缓冲区？

　　是否需要模板、目标Alpha或积累缓冲区？

　　当为窗口设置这些参数之后，就无法对它们进行修改。为了从一个只有深度缓冲和颜色缓冲区的窗口切换到一个带有模板缓冲区的窗口，必须首先销毁第一个窗口，然后根据需要重新创建一个窗口。

　　[ OpenGL]

　　PIXELFORMATDESCRIPTOR

　　The PIXELFORMATDESCRIPTOR structure describes the pixel format of a drawing surface.

　　typedef struct tagPIXELFORMATDESCRIPTOR

　　{ // pfd

　　WORD nSize; //结构大小： sizeof(PIXELFORMATDISCRIPTOR)

　　WORD nVersion; //版本：总设置为1

　　DWORD dwFlags; //像素缓冲区的属性标记

　　BYTE iPixelType; //像素数据的类型

　　BYTE cColorBits; //颜色缓冲区中位平面的数量

　　BYTE cRedBits; //用多少位表示红色

　　BYTE cRedShift; //红色位的移位计数

　　BYTE cGreenBits; //

　　BYTE cGreenShift; //

　　BYTE cBlueBits; //

　　BYTE cBlueShift; //

　　BYTE cAlphaBits; //

　　BYTE cAlphaShift; //

　　BYTE cAccumBits; //积累缓冲区位数

　　BYTE cAccumRedBits; //积累缓冲区中红色的位数

　　BYTE cAccumGreenBits;

　　BYTE cAccumBlueBits;

　　BYTE cAccumAlphaBits;

　　BYTE cDepthBits; //深度缓冲区位数

　　BYTE cStencilBits; //模板缓冲区位数

　　BYTE cAuxBuffers; //多少个辅助缓冲区

　　BYTE iLayerType; //过时或忽略

　　BYTE bReserved; //上层或下层平面的数量

　　DWORD dwLayerMask; //过时或忽略

　　DWORD dwVisibleMask; //下平面的透明颜色

　　DWORD dwDamageMask; //过时或忽略

　　} PIXELFORMATDESCRIPTOR;

　　//************************************************************************

　　//设置窗口像素格式

　　//************************************************************************

　　GLuint PixelFormat; // Holds The Results After Searching For A Match

　　static PIXELFORMATDESCRIPTOR pfd= // pfd Tells Windows How We Want Things To Be

　　{

　　sizeof(PIXELFORMATDESCRIPTOR), // Size Of This Pixel Format Descriptor

　　1, // Version Number

　　PFD_DRAW_TO_WINDOW | // Format Must Support Window

　　PFD_SUPPORT_OPENGL | // Format Must Support OpenGL

　　PFD_DOUBLEBUFFER, // Must Support Double Buffering

　　PFD_TYPE_RGBA, // Request An RGBA Format

　　32, // Select Our Color Depth

　　0, 0, 0, 0, 0, 0, // Color Bits Ignored

　　0, // No Alpha Buffer

　　0, // Shift Bit Ignored

　　0, // No Accumulation Buffer

　　0, 0, 0, 0, // Accumulation Bits Ignored

　　16, // 16Bit Z-Buffer (Depth Buffer)

　　1, // No Stencil Buffer

　　0, // No Auxiliary Buffer

　　PFD_MAIN_PLANE, // Main Drawing Layer

　　0, // Reserved

　　0, 0, 0 // Layer Masks Ignored

　　};

　　if (!PixelFormat=ChoosePixelFormat(m_hDC,&pfd))) // Did Windows Find A Matching Pixel Format?

　　{

　　MessageBox("Can't Find A Suitable PixelFormat.","ERROR",MB_OK|MB_ICONEXCLAMATION);

　　return FALSE; // Return FALSE

　　}

　　if(!SetPixelFormat(m_hDC,PixelFormat,&pfd)) // Are We Able To Set The Pixel Format?

　　{

　　MessageBox("Can't Set The PixelFormat.","ERROR",MB_OK|MB_ICONEXCLAMATION);

　　return FALSE; // Return FALSE

　　}