[S.TECH]《S.TEST》灯光底层原理的选择

六百木

S.TECH系列是《S.TEST》中值得独立出来分享的技术，抛砖引玉，以此共勉

从最初的设计概念开始，《S.TEST》的两个核心分别是声音和灯光：玩家必须利用这两种手段之一来探索游戏世界。声音方面使用的是苏小脉的SEAL「焦尾」3D音頻渲染庫，不需要太多功夫就可以直接使用；灯光方面由于RMVA默认没有这方面的支持，就需要额外制作了。

首先要确认的是，在RMVA的2D俯视世界中，何谓灯光？要达到S.TEST中灯光作为游戏性一部分的要求，最低限度的效果是没有光的时候屏幕一片漆黑，有光的时候根据光源的强度照亮一部分地方。一般RM游戏对黑夜常见的处理是改变地图色调，使之偏蓝偏暗，然后在需要灯光的地方用加法显示一个灯光的事件或图片。但S.TEST的游戏性要求黑暗的地方要伸手不见五指，而改变地图色调直到暗到看不到的程度的话，加法叠加的灯光也只会是一片灰白。这是因为色调变暗会让图像丢失阴影部分的细节，再用加法加回来也只会是无差别的灰白。

改变色调不行的话，那就只能用一张黑色的图片覆盖来达到没有光照的情况下漆黑的效果了。这时要实现灯光，最直接的方法是在这张黑色遮罩图上挖洞，使下面的内容能显示出来。这个方法最大的问题是RGSS中没有在bitmap中挖洞的函数。RGSS的Bitmap#blt是正常叠加，无法减少操作目标的像素alpha值，也就是无法挖洞。Bitmap#fill_rect倒是可以设定alpha值，但fill_rect的结果全是长方形，要实现圆形的灯光范围比较困难。这样一来，要使用挖洞的方法的话，就需要把挖洞函数写进一个dll让Win32API调用，因为用Ruby的get_pixel/set_pixel过于缓慢。

那究竟有没方法只用RM提供的函数来实现灯光呢？研究了一下Khas Awesome Light Effects，发现可以用一张全白的图片作为遮罩图，这张Sprite的blend_type为减法。减法混合的遮罩图的优点是可以直接把灯光图片blt上去，blt之前只需要把灯光图片反色一下就行。但直接blt也有一个缺点：灯光之间的叠加可能会出现问题，因为它们之间是正常叠加，也就是说后来的灯光会覆盖前面的灯光，而不是理想中的各种灯光混合在一起。

各种灯光混合，意思即是灯光图片之间是加法叠加（或者其他减淡算法）。使用RM默认函数的话，有一个比较特别的方法：使用多层blend_type为减法的遮罩图和多层blend_type为加法的灯光图。前面说过，色调变暗会让图像丢失阴影部分的细节，所以如果只用一张减法遮罩图和一张加法灯光图的话，效果跟前面说的改变地图色调一样是一片灰白。但如果使用多层遮罩图，每张只有较小的不透明度，每层的遮罩图只会让图片变暗一部分，然后灯光图把需要照明的部分用加法加回来。这样经过多次减法叠加和加法叠加，实际损失的的阴影细节只有一小部分，最终效果仍然可以接受。当然叠加的顺序可以相反，先叠加灯光层再叠加遮罩层，这样损失的会是高光细节，对于偏阴暗的画面来说这是更好的选择。多层混合还有一个重要的优点是不需要每帧重新blt遮罩和灯光，从而提升了速度，因为遮罩层和灯光层都是固定的sprite。虽然多层混合从速度到效果的表现都不错，不过它有一个不容忽视的缺点：灯光之间是加法，所以多个光源混合会使图像亮到晃眼（颜色：255，255，255），完全看不到图像的细节了。虽然可以把所有灯光都blt到一张图上面，但这样一来就跟上一个方法没有区别了，仍然存在灯光正常叠加下互相覆盖的问题。

回到把灯光blt在遮罩图上的方法，既然正常叠加不行，那就改用乘算叠加吧（因为遮罩图是减法混合，所以灯光之间用乘算叠加这类加深算法）。R界已经有不少自制dll提供bitmap乘算叠加函数，并且已经有这样实现的灯光系统了：http://www.tktkgame.com/或http://rpg.blue/thread-224000-1-1.html。经过试用，发现这些dll中的乘算叠加函数对于alpha通道处理都有问题。从photoshop的乘算叠加效果来看，乘算叠加应该只应用于RGB通道，alpha通道仍然是正常叠加。但这些dll的乘算叠加连alpha通道也乘算了，出来的结果非常诡异，使得alpha通道几乎不可用，所有的灯光图必须使用白色背景而不是透明背景。算法不正确也就罢了，这些dll都没有开源，于是只能重新发明一个轮子，写了一个乘算叠加算法的dll。

到这里为止，S.TEST的灯光底层原理终于确定了：减法混合遮罩图+乘算叠加灯光。灯光系统速度优化、实现各种特殊效果诸如烛光跳动，这些就留待以后总结得比较好的时候再说吧。