Métricas do repositório
- Stars
- (1.807 estrelas)
- Métricas de merge de PR
- (Métricas PR pendentes)
Description
Is your feature request related to a problem?
No response
Describe the feature
依照我从结果上的验证,我推测(不一定准确),当前的判定方式是点判定+距离判定,这种判定方式对于一款移动端音游来说这是没问题的,但放在街机上就会出现一些问题,如果你把手指放在B3和A3的中间,或者B3上,但是手的接触覆盖过A3,实际判定也只会判定B3,解决这个问题的方式可能是一味的扩大判定范围,但这样会导致某些情况下引入交互变双押的问题. 从Unity自己角度来看这个问题无法解决,因为unity确实只会返回一个点,但把视角扩展到Linux,我们也许有更好的解决方案 拿我自己的Zte Z70 Ultra来说,它采用了Goodix中低端驱动实现,因此实际上它的event只有ABS_MT_TOUCH_MAJOR,也就是说我们能获得到的只有一个圆形,但这个圆形经过我的测试,在手指大小的范围相对是比较准确的,我通过ADB写了一个小小的绘制程序用于检验绘制的效果(参见下图
)以当前的判定方式,只有B3会被判定,A3是没有判定反馈的,但如果改用通过Linux MT协议事件,通过接触面圆或者椭圆对落到的区域实行重叠计算,那么这两个区域都可以被正确的判定,可以更好的实现街机原有的行为,对于越好的触控方案这个更改的效果越明显 同时,针对于区域大小,也可以把判定区域的大小修改为对触摸区域扩展的大小,提供一个ui,让玩家通过自己的手触摸大小,和设备上的红圈做比较,来选择一个合适的扩展/缩小范围 附参考文献: Linux MT 协议将手指与屏幕的接触区域建模为一个椭圆： ABS_MT_TOUCH_MAJOR：接触面（皮肤真正按在屏幕上的区域）椭圆的长轴 ABS_MT_TOUCH_MINOR：接触面椭圆的短轴 ABS_MT_WIDTH_MAJOR：接近工具（整个手指，包含悬浮部分）椭圆的长轴 ABS_MT_WIDTH_MINOR：接近工具椭圆的短轴
Reason for adding
单纯的对触摸逻辑的优化
Example(s)
No response
Additional context
Based on the verification of my results, I infer (not necessarily accurately) that the current judging method is point-based + distance-based. This approach is fine for a mobile rhythm game, but it can cause issues on an arcade cabinet. For example, if you place your finger between B3 and A3, or directly on B3 but your touch contact area also covers A3, the actual judgment will still only register B3. A possible way to address this is to simply expand the judgment range, but doing so can introduce problems in some situations—such as turning interactions into unintended “double hits” (simultaneous presses).
From Unity’s perspective, this problem cannot be solved, because Unity indeed only returns a single point. However, if we broaden our perspective to Linux, we may have better solutions.
Take my ZTE Z70 Ultra as an example. It uses a Goodix mid-to-low-end driver implementation, so in practice its events only include ABS_MT_TOUCH_MAJOR. In other words, what we can obtain is only a circle. But based on my tests, this circle is relatively accurate within the range of typical finger sizes. Using ADB, I wrote a small drawing program to verify the rendering effect (see the figure below). With the current judging method, only B3 is judged, and A3 receives no judgment feedback. However, if we instead use Linux MT protocol events—using the contact area circle or ellipse to compute overlap with the target regions—then both regions can be judged correctly. This better reproduces the original arcade behavior, and the better the touchscreen solution, the more noticeable the improvement from this change.
At the same time, regarding region size, the judgment region size can also be changed to an expanded size based on the touch area. We could provide a UI that lets players compare their own finger touch size with the red circle on the device, so they can choose an appropriate expansion/shrink range.
References: The Linux MT protocol models the contact area between the finger and the screen as an ellipse:
ABS_MT_TOUCH_MAJOR: major axis of the contact area ellipse (the area where the skin actually presses on the screen) ABS_MT_TOUCH_MINOR: minor axis of the contact area ellipse ABS_MT_WIDTH_MAJOR: major axis of the approaching tool ellipse (the entire finger, including the hovering part) ABS_MT_WIDTH_MINOR: minor axis of the approaching tool ellipse