Pal Lockheart

In fact it can. After boot into the shell, just ``` mkdir -p /run/mnt/ventoy mount /dev/sd?1 /run/mnt/ventoy mount /run/mnt/ventoy/ISOPATH /run/archiso/bootmnt exit exit ``` works. like other arch installcd.

中午才发现最近电脑时不时过慢是macgesture的内存占用导致的。于是试图分析，结果自己编译了一个以后（完全没动代码）发现问题完全没了，不清楚是最近的提交解决了问题还是新编译器/运行时的功劳。官方版2.2.3的内存很快就能上1G，自编版三个多小时了还是44M。 编译环境：xcode 9.1，osx 10.13.1。git commit ac2b4dc 顺便发下当时观察官方版内存涨时的几个结果：在macgesture不生效的进程，怎么划都不涨。在生效的进程（过滤器里有，比如chrome），开不开手势轨迹预览/说明，都涨，幅度也一样，说明问题不是在显示部分；右击划动开始就涨，不需要松开也会。

@jiegec 这两个（tag 2.2.3和HEAD）表现接近。另外仔细测了下，下午我给的结论有问题。这两个版本还是随着识别的手势数量（不管是否实际识别到，只要有识别产生）内存不断上涨（不确定是不是泄漏——Instruments里完全找不到memory leak），但上涨幅度比起官方版低——官方版一个手势最低5MB，这两个版本则十几个未必有1MB。从Instruments看，每次手势识别后内存上涨的主要因素是-[NSPredicate evaluateWithObject:]，每个调用会产生一个无法释放的3kb malloc，而根据代码这个是随着用户配置的app数、手势数成二次项上涨的，而且显然没法简单去掉，更关键的是看起来MacGesture对其的使用方法完全符合ARC规范。搞不好这是个系统级别的bug。

@jiegec 暂时来说自己编译的还能用。只要短期内不涨太高，貌似长期下来（以分钟计）系统会回收那部分内存的，只是没有那么快。估计xcode9的clang做的就是这个优化。测时都是飞快的刷，官方版很快就刷到内存爆满了，估计可能是回收来不及。

@seagle0128 不太清楚这能不能归类为泄漏，这种地方按objc的规范应该是runtime自动回收的。。。而且Instruments一直表示Leaks Checks OK，只是我观察到随着多次刷过这部分是上升速度最快的。  刚刚回到instruments，发现这部分完全消失了，说明系统的确回收了这部分内存，但活动监视器里macgesture的内存占用量却并没有减少。这可能说明回收的内存并没有释放给系统？具体就需要写过malloc库的来解释了。

经确认是fight.c第4749行if (!gpGlobals->fAutoBattle)导致，实际原因是引擎没有处理好多个同一人物的状态变动（打A阿奴B阿奴同样显示掉血），有待今后实现。

Closing due to current code work well; and no enhancement saw on low-end platform.

One tester on psp SDL1 said that he see no noticeable different before/after this patch, and also myself on wii. Could you please provide the detail platform that require this...

Another question: this PR not only include the delay 1->0 patch, but also changes waiting time calculating by introducing dwFrameNumber variable, which ++ in every frame. Will it makes that...

> nobody would care about audio/video synchronization. This is not a good reason for code change. If the only needed patch is 1->0, please file a new PR that only...