使用Java Swing定时器的Java 2D游戏性能

我正在使用JavaSwing开发一款射击型视频游戏，我正在使用JavaSwing定时器来控制所有屏幕更新。主屏幕使用BorderLayout，我在BorderLayout中包含的面板上执行图形，并使用AWT图形调用进行绘制

现在随着游戏的进行，我想加快屏幕上物体（飞船）的移动速度，但我仍然希望它们能顺利地穿过屏幕。我想我可以通过将Java Swing计时器的超时值降低到5毫秒左右来加快速度。但是，我注意到，当我将它设置为小于15毫秒时，似乎没有太大的差异。一旦你跨过这个门槛，在性能上几乎没有明显的差别-为什么呢-

另一个选择是增加每艘飞船每次更新移动的像素数，但如果超过3或4像素，事情就会开始变得不稳定

有什么想法吗？如果你真的想保持游戏的正常运行，最好不要移植到第三方库

---

谢谢。

很可能，这不是软件问题，也不是软件可以解决的问题。您的屏幕可能每秒仅刷新约60次，这意味着帧每秒仅绘制60次，或者每（大约）16毫秒绘制一次。因为这是一个硬件障碍，所以没有办法让它用软件更新得更快。你也可以指望你的用户也只有60Hz的显示器，所以更值得研究其他的解决方案

---

一个突然出现在脑海中的解决方案是添加运动模糊，使它看起来像是船在更快地移动，而实际上它们并没有。它可以让你在看起来跳跃之前“跳跃”更远的距离，因为模糊会欺骗你的眼睛，让你认为它跑得真快，而不是在屏幕上跳跃。不幸的是，我所看到的唯一可以做运动模糊的东西是第三方库，尽管你可能在谷歌搜索时运气更好。

我建议你将你的Swing引擎改为JavaFX（至少），这是一种性能更好、工具更多的技术。如今的Swing被认为是一种过时的技术，之前的AWT也是如此。学习和启动JavaFX的好地方是：

开发游戏的理想方法是使用为其准备的库，如libGDX：

但是，如果你的愿望是创造一个挥杆游戏，我该评判谁呢？有时看到旧东西是件好事。我自己仍然喜欢秋千，即使与其他东西相比已经过时了

我认为你可能实现了一个错误的游戏循环。Swing Timer看起来并不是更新游戏逻辑的好方法。即使不同的计算机之间有不同的设置，实现gameloop正常工作通常也是实用且容易的，特别是对于角色的正确移动

你看，gameloop是游戏的核心，需要直接实现，否则游戏开发错误，并且存在一些限制。通常，在gameloop中，我们必须考虑所需的FPS。在游戏更新中，我们必须计算上次更新和当前更新之间经过的时间，许多开发人员称之为delta。你可以在互联网上找到许多关于它的资料，我推荐：

过去的链接肯定会对你有所帮助，但如果你想了解更多，我建议你看看这本书：

即使材料很旧（比如Swing），您也会发现如何使用键盘和鼠标输入系统、声音、Swing提供的最佳性能的使用以及其他一些很酷的东西来实现一个好的gameloop。还有一件事。。。为了让您在字符移动方面获得更好的结果，我建议您将位置变量（X和Y）与十进制类型（如float或double）一起使用

---

我希望你能做你想做的事。祝你好运

问题在于操作系统和时钟的准确度。你的屏幕刷新速度很快——因此，如果你有一个60Hz的屏幕，每次更新（因此仅每隔几次显示）开始绘制多个帧之前的最小延迟约为16ms。如果你愿意，我会把这个作为答案。课程即将结束，所以我现在发布答案。Swing计时器的最小分辨率为。。等等。。x86/x64 Windows上大约15毫秒（这可能因操作系统/实现而异）。唯一的保证是计时器将“至少”延迟指定的时间。参考，-Swing和它使用的渲染管道还有其他问题，这使得它不适合“快速2D”游戏。我建议看一看游戏库。无论如何，如果坚持使用Swing进行“快速2D游戏”，一个简单的方法是不断请求重新绘制，然后在重新绘制中根据增量时间计算处理运动（以及图形绘制）。这将以支持的“最大重新绘制速度”运行，增量时间计算将确保整体移动更加平滑/一致。虽然刷新率（和延迟）最终会影响用户体验，但Swing计时器与监视器刷新率无关。@user2864740这很有趣。尽管如此，我所说的仍然是正确的，考虑到两者几乎同时存在，它实际上是一个TOSSOP。虽然我同意JavaFX将取代Swing，而且每个人都同意Swing不是实现动作游戏的好选择，但将Swing称为“死技术”是非常不准确的Swing的功能仍然要完善得多。Swing有很多很酷的东西，但不幸的是，它被认为是过去的东西（参见第6项）。另请参见：开发人员最好迁移到JavaFX，它只提供了比Swing更好的东西。如果有疑问，请查看JavaFX集成演示并亲自查看：作为一名在市场上工作的人，我的建议是，人们可以按照