Lua 吉他英雄般的计时机械师

我目前正致力于制作一款受《吉他英雄》和《火上的烦恼》启发的游戏，到目前为止一切都进行得很顺利——我已经编写了一个脚本，可以将由生成的.chart文件解析为可用数据

我关心的是如何确保计时正确（我必须将这些节拍值转换为毫秒）ux？我正在解析的文件包含如下值：

0 = N 1 120
120 = N 2 120
240 = N 3 576

其中第一个整数是音符应出现的节拍，N是音符是否为锤击，然后是Fret ID（绿色或红色等）和音符的长度，同样以节拍为单位

我担心如果突然出现FPS延迟峰值，歌曲会很容易失去同步，有什么方法可以防止它失去同步

---

我试图找到一些来源，以确定它们如何确保笔记上的计时正确，但我似乎找不到任何有用的东西。

这是一个难题，因为它取决于音频播放器API。要使其正常工作，您需要在播放机中具有一个返回当前播放位置的函数。假设您的播放器API有一个以毫秒为单位获取位置的方法

---

我会在本机代码中进行同步，因为如果在lua中使用该值，GC可能会启动并使您失去同步。只需使用lua解析计时，并为本机代码设置结构数组（或类似的东西）。

我想我当时可能有点不知所措：p问题是我正在做这个。。。“游戏”在另一个游戏中。我正在编写的游戏确实使用BASS库，所以我可以获取和设置声音位置-但它使用秒，而不是毫秒-因此它恐怕不会非常准确…@Dennis它使用秒，但使用浮点，所以分数是毫秒，不是吗？@rpattiso:你确实是对的，它返回一个包含大量小数的浮点-7.5110430839002。有人知道像《火上烦恼》和《吉他英雄》这样的游戏是如何确保开头的音符正确计时的吗？我找不到关于这件事的任何有用的信息，我确实相信《火上的烦恼》的翻拍，叫做FoFix或其他东西是开源的-我想我可能会寻找，也许我能找到一些线索：）编辑：澄清一点，我不完全确定如何使用与BPM以某种方式相关的第一个值。大多数歌曲不符合严格的节奏，因此像.chart这样的摘要太简单，无法与录音保持同步。选择节奏更严格的歌曲并使用量化对音乐进行预处理将有所帮助。看起来你也不知道第一拍是什么时候，所以我也建议在那里进行预处理。否则，您将不知道不同步的原因。我建议调试一个简单的电子节拍器录音。