[抛个砖头] 关于现在版本，枪发射间隔的实际帧数(已补充视频验证)

只谈正事

总结

目前的射击间隔应为——c#逻辑 (int)(50/射速/0.03333334) 帧，
通常情况下可以用 向下取整(1500/射速)来代替，但是在返回值为整数的情况下，需要额外再-1，比如50射速的情况下，返回帧数不是30帧，而是29帧，60射速的情况下，返回帧数不是25帧，而是24帧。

因为最近在做一些事情，讨论到了实际发射间隔。

按照原先的帖子和原先的运行逻辑，发射间隔应为

30*50/射速

。

然而取整方式不明，所以本人做了以下测试。

50射速与25射速

按照理论，向上取整，那么可以得到50射速的帧数为31帧，而25射速的帧数为61帧，可知，25射速发射一次略快于50射速发射2次

然而实测情况下，25射速却略慢于50射速发射2次。

这个时候我注意到一个问题——就是float的取整。

我们知道，少前的运行速度被限定在30帧，无论实际运行速度如何，内部时钟会尝试每过1/30 s进行一次数据刷新。而从(50/射速)秒 变成一个按帧计数的，则使用以下逻辑 (int)(50/射速/Time.fixedDeltaTime)

这个间隔是Time.fixedDeltaTime 固定增量时间，也就是unity引擎控制的一个理论上每一帧的更新时间，查询unity库可以得知fixedDeltaTime返回为float形。

学过计算机的朋友都清楚一件事情，float形返回1/30，并不等于0.03333333……通过vs2015 c# print(1f/30f)，可以获得float(1/30)=0.03333334，而0.03333334大于0.0333333333……

这里文章就来了，如果当 (int)(50/射速/Time.fixedDeltaTime)运行完毕，那么返回的数值是否会因为这个误差而造成影响。

那么我们来print一下在25射速和50射速的情况下，到底返回值是多少。

可以看到，在返回值强行转换为int的时候，有1帧被

续掉

了。然而如果返回值用float来直接显示，是不会丢失这一帧的，这也就是0.03333334造成的实际误差，也就是说，当50/射速是0.0333……的倍数的时候，会有一帧因为取整而被

续掉

。

在这种情况下，我们重新获得50射速的帧数为29帧，而25射速的帧数为59帧，符合我们所观察到的情况。

为了证明我的说法是正确的，我重新挑选了3种情况。以下视频验证补充。

• 1.50射速和51射速，因为这两种情况下，都会返回29。
  视频验证：可以看出视频中2人形保持同步射击。这是旧公式无法解释的，但是符合新公式。
  
  http://v.youku.com/v_show/id_XMjcxOTY0ODAzMg==.html
  如在以上内容中出现任何广告性信息并不代表本站支持其立场 (播放视频需版主设置
• 2.31射速和60射速，31射速返回值为48，而60射速的时候返回值为24(没错因为是0.0333……的倍数，所以丢失1帧)
  视频验证：视频中2人形保持1:2的射击频率。别问我为啥带negev和ksg 因为不带扛不住1分钟。
  
  http://v.youku.com/v_show/id_XMjcxOTY0OTEzMg==.html
  如在以上内容中出现任何广告性信息并不代表本站支持其立场 (播放视频需版主设置
• 3..29射速和59射速，按照原来的算法应该正好是相差1倍帧数，实测已经错误，59射速返回值为25，29射速返回值为51,。
  视频验证：视频中2人形的射速频率很快岔开，无法如旧版本测试一样始终保持1:2的射击频率。
  
  http://v.youku.com/v_show/id_XMjcxOTY0OTEzMg==.html
  如在以上内容中出现任何广告性信息并不代表本站支持其立场 (播放视频需版主设置
  

由于本人暂时无法录屏，所以无法放上视频。不过实验证明我的说法是正确的。

视频可以验证，以上理论是正确的。各位客官有异议的可以提出，我们继续讨论。