关于Drill移动镜头插件 解决事件抖动问题的尝试

开关关

曾用标题：关于Drill移动镜头插件 解决事件贴图出现像素偏移的常试

标题：关于Drill移动镜头插件 解决事件抖动问题的尝试

　@Drill_up 大佬你好，我想请你看一眼这个帖子。这是关于你写的移动镜头插件插件的讨论。

原插件连接：https://rpg.blue/thread-409713-1-2.html

---

　　最近听说Drill大佬的移动镜头插件更新了，赶紧在自己的游戏里装上了最新版（v1.6）。

　　以前的版本有事件贴图出现像素偏移的问题，像我这种建筑物元件不够事件来凑的，就会十分不爽。玩家移动时，NPC都会发抖抽搐，充当建筑物的事件也会开始地震似的摇晃，观感十分差。不知道大家用这款插件时有没有遇到这个问题？

　　看代码，新版本似乎解决了一些问题。上面有注释的这行代码规定，当镜头与目的地距离不足1像素时，瞬间补齐剩余距离；下面这行有注释的代码规定，镜头移动速度不足1/4像素时补足到1/4。

此处有折叠的代码1

　　现在已经比原来好多了。但是，还是有轻微的事件贴图出现像素偏移的问题。可以看到，不论是移动的过程中，还是移动的最后，都有轻微的卡顿。

此处有折叠的动图1

　　由于低分辨率的限制，镜头移动有卡顿是无法避免的。我现在想要做的，是仅通过修改这个插件，使事件贴图尽量与地图贴图同步移动。

　　我假设不同步的原因是镜头在移动的时候，地图贴图和事件贴图对于位置为小数的显示的理解有所不同。其中一个认为不足1像素就忽略小数，另一个认为要四舍五入（还可能是不足1像素补加到1），这样在不同时刻地图和事件的贴图就产生了最多1像素的位移差。我称呼会引起这个问题的小数为“歧义小数”。未安装移动镜头插件时，镜头的移动时匀速的，只会有整数的位移，因此不会呈现出这个问题。可以说，最大的问题其实在于自带的代码不合理。但是我看了自带的代码，发现里面各种对象互相引用，错综复杂，我不太懂代码，怕改了自带代码会炸，所以决定只改插件。

　　我的第一个打算是把最小速度（1/4像素）改成最小速度为1像素，这样可以保证避免四舍五入不同导致的移动像素数不一致造成的事件贴图抖动问题。

此处有折叠的代码2

此处有折叠的动图2

　　这时我注意到，即将停下的镜头移动末端确实没有问题了，但是在移动的过程中依然有问题。我猜测是移动过程中产生了“歧义小数”。所以应该把平时的移动也给它附加上最小移动1像素的限制。

　　我以前也在v1.4上干过这件事，当时是用的土法，直接对speed先/48然后向上取整再*48，也能解决这个问题。但是那样由于每次刷新时，只要移动，都会移动至少1像素，这就导致原来有的丝滑感没了。因此，我需要换个思路。

　　丝滑感的来源是经过算法算出的每次刷新移动距离，也就是随丝滑函数变化而变化的速度。我的修改应该仅降低speed的精度，而不应该影响speed的整体变化曲线。用声波来类比形容的话就是变成方波但不要变调。

　　我的思路是，定义两个全局变量“镜头移动助手”，代表镜头移动量的计算过程值。这个值存储起来，以后一直使用。每当镜头需要移动，移动的量就加（右下加，左上减）在偏移缓存上，然后取镜头移动助手四舍五入后的值作为speed，最后对镜头移动助手减去speed。镜头移动助手剩下没有给speed的量会加到下次的移动中。

　　开始。

　　我在359行的初始化中加入三个变量，其中两个是镜头移动助手，还有一个是最小速度。

此处有折叠的代码3

　　然后改一改镜头移动相关的代码……

此处有折叠的代码4

　　测试，确实丝滑，但是发现镜头左移或上移后会差一个像素，于是对它作了一些修改。我回过头看尚未修改的代码，发现每次移动至少1像素是原作者故意为之，于是又给加了回去。下面是目前确定的样子。

此处有折叠的代码5

　　然后在原本的632行，“容器 - 切换地图时”中加入两行。我的理解是场景移动时执行这些代码，于是在这里插入了镜头移动助手的初始化。

此处有折叠的代码6

　　运行！

此处有折叠的动图3

　　感觉还行，事件贴图出现像素偏移的问题不明显了。如果这个图看不出来，可以再看下面这张图。

此处有折叠的动图6、7

　　效果是不是比原来好一些？尽管测试中还是会时不时发生事件贴图出现像素偏移，但是已经在我个人的接受范围内了。

　　总结一下，我的方法核心思路是把移动小数个像素的镜头改成移动整数个像素。其中有两个细节，一个是为了保持原有速度曲线，加了个“镜头移动助手”来记录原本的移动；另一个是为了避免精度产生的误差，人为制造了更大的差。

---

　　谢谢大家耐心看完。我这代码逻辑挺乱的，但愿没有提升你们的血压。我希望能抛转引玉，请问各位大佬有什么解决方法吗？


补充：做gif的时候发现，从gif上根本看不出多大差别。把源码放上来就可以方便体验交流，但是源码是Drill大佬原创的，我修改后放出来，有二次发布的嫌疑。如果Drill大佬真的看到这个帖子，我就向他询问能不能在这里放修改后的源码。

开关关

Drill_up 发表于 2020-3-11 12:11
首先，感谢你提供的思路。

大佬回复我了啊啊！谢谢你愿意深究这个问题。优化的代码太棒了，解决了很多问题。

我猜问题2并不是不能解决，如果精度丢失会导致显示有偏移，那就说明自带的Game_Map一定有问题。Game_Map里面记录坐标的变量的基本单位都是1格，而不是1像素，没办法避免精度问题。假如能重写Game_Map类，以1像素作为基本单位，就可以解决问题，还能实现一些其他效果。但是又怕牵扯到其他的类，不太敢动Game_Map。

总之谢谢大佬，我会使用大佬的代码并继续寻找更好的解决之道。

我还有一个疑问，请问为什么像素最小速度是1/4像素？

开关关

kuaile412 发表于 2020-3-11 10:38
tql！是大佬~两位都是大佬
似乎移动量还是会部分出现1像素的偏移.....
感觉...还是有哪里没同步上，似乎是 ...

这个1像素的偏移看来是赖在这里不走了。_(:з」∠)_

除了改Game_Map类，我想不到还有什么办法能彻底解决这个问题......

开关关

Drill_up 发表于 2020-3-11 12:11
首先，感谢你提供的思路。

　　几天前拜读了Drill_up大佬的代码，认为大佬的代码比我的逻辑通顺了很多，也更加合理。于是我套用了大佬的代码，但是发现抖动现象反而又出现了。

此处有直接套用的大佬的代码

此处有三张动图

　　总觉得大佬的代码缺了什么东西。_(:з」∠)_

　　抖动和移动时偏移的现象出现频率较高。因为除法必然出现的误差可能偏大可能偏小，我在之前修改的代码中加入了“允许误差”（叫做“手动增加误差”更合适），让计算结果必然偏大。具体实现就是每次移动时加入一个不影响整体的小值，但是这个小值会使整体不容易出现歧义。这个步骤让镜头移动的像素更加可控，有可能消除歧义。加入以后，抖动的问题得到很大缓解，几乎不出现了，而且移动时偏移的出现频率也得到降低。

　　移动结束后还会偏移一个像素现象的出现频率比较中等。我猜测大佬设计每次最少移动1/4像素，就是为了既能避免镜头移动多了偏移一整个像素，又能在镜头移动少半个像素时给予补齐。但是测试表明，有时出现一个像素的偏移时，y2和this.centerY()的值竟然是相等的，这样这个错误就十分狡猾地绕过了大佬设置的矫正程序。于是我加了个镜头移动停止后的矫正程序，一旦x2,y2分别与this.centerX(),this.centerY()相等，就对$gameMap._displayX,$gameMap._displayY取四舍五入的整数，对坐标进行矫正。

此处有再次修改的代码

　　最终运行的效果终于跟此楼引用的楼层（4楼）里面那个效果图一样了。经测试这些改动与镜头墙功能不冲突，与看向事件功能未知。但是测试过程中一直没离开出生点太远，如果有积少成多的错误，暂时还看不出来。

　　最后再次感谢Drill_up大佬的指引。

开关关

Drill_up 发表于 2020-3-18 11:08
(´⊙ω⊙`) 镜头bug是我的代码造成的问题，我给你代码的时候，提供了分段的思路，
但是我没有注意到分段的 ...

恍然大悟！pixel_speed在参与判断之后又被round了，所以镜头每次移动才都有偏移！

谢谢大佬，我下载脚本试试看。

开关关

Drill_up 发表于 2020-3-18 11:08
(´⊙ω⊙`) 镜头bug是我的代码造成的问题，我给你代码的时候，提供了分段的思路，
但是我没有注意到分段的 ...

左图：1.7版    右图：1.6版改版



　　上图是在我的电脑上（i7-8750H核显 16G内存 Win10_1903）的效果。我尝试了大佬的新版本（9楼的V1.7），但是事件抖动还在。

　　之前修改的V1.6几乎毫无问题。

V1.6 Drill改版Kgg再改版.zip (12.69 KB, 下载次数: 53)

2020-3-24 04:21 上传

点击文件名下载附件
有点慌，这样会不会涉嫌二次发布？

---

　　另外在测试中，我发现镜头墙有一个bug，不论是V1.6改版还是V1.7都有这个bug。



　　图为V1.7的现象。如图所示，左下角是一个有注释“=>地图镜头 : 设置镜头墙 : 上”的事件，它不论以什么速度向下移动时，都会出现整个画面震动的现象。重复测试时，我使用事件执行“设置事件位置...”时，让镜头墙事件远离玩家，同时仍保持在6格距离内（必然会影响玩家视野的距离），也出现了这个现象。这个bug的现象即使玩家离镜头墙事件很远也挺明显。

　　初步猜测，事件中心坐标变更的时候镜头墙失效，因此镜头迅速向下移动，移过了头；一段较短的时间后，镜头墙又生效，于是镜头又开始向上回弹。