16 bit 色下的ADDITVE混合无法用到 MMX 优化.(如果使用真彩, MMX 的饱和处理 就有用武之地了) 当屏幕上有多个光源时, 多次混合就极大的影响了速度. 而且简单的将多个光源的光线相加, 得到的效果呵实际并不相同. 进几天仔细观看了 Diablo II 的演示, 深为其中的光影效果(尤其多个动态光源)叹服, 如果我的 Engine 的质量要达到这个级数, 必须找到一个优秀的算法实现.

问题的关键点集中在, 我们最常用的颜色格式是 RGB 的, 对它进行光线运算势必牵扯 到多个数值的处理, 而 16bit 色还牵扯到色素的拆分问题, 导致了对图象光照运算的复杂. 而将点描述成 HSL 这样的格式, 虽然亮度被单独出来, 其格式不利于处理(无法实现半透明等常用效果), 色彩格式间的转换牵扯到了浮点运算, 且公式复杂, 最后整屏幕转换成 16bit RGB 再显示严重的影响了速度. 云风在仔细考虑后, 放弃了这条路.

　思考再三, 比较合理的做法是再屏幕 Buffer 外另建一个亮度 Buffer, 再更新屏幕的同时, 将亮度Buffer 和 色彩 Buffer 的数据组合得出将显示数据显示. 游戏中得点光源配合一张事先做好的圆或椭圆光圈绘制到亮度图上. 环境光则相当于整屏的亮度 Buffer 的处理. 而绘制在屏幕上的物体则可以根据游戏中的远近 将其掩图按一定的亮度绘制在亮度图上. 以此类推, 利用这张亮度 Buffer, 可以派生出许多的巧妙作用, 而速度比起直接对 RGB 逐点运算要快的多 ;-)

对于光照图Buffer, 我不打算和色彩信息叠加, 那样很容易饱和, 采取衰减的方式更好点. Buffer 中一个点占 1 字节, 但只使用低 5 位. 0~31 的数值表示了从 0 ~ 31/32 的衰减度. 运算很简单, 将 RGB 分别乘上衰减值除以个 32 就 OK 了.

最后来谈谈光线的叠加, 衰减度为 10 的光线和衰减度为 20 的光线叠加起来是多少? 当然不是 30. 正确的算法是 32-10*20/32=26 (10 实际是 31.3% 的衰减, 20 是 62.5% 的衰减, 合成值是 1-(1-31.3%)(1-62.5%)) 推导过程略.