java - 何时在 2D 动画中使用 Thread.sleep 而不是 SwingTimer

Question

本例中的上下文是创建一个与模型集成并每帧更新一次 View 的游戏循环。监听器与 Controller 交互， Controller 更新模型，repaint() 处理来自模型的 View 更新(在 JPanel 上重写的 paintComponent() 上>).

适当的回答包括“从不”，哈哈。

这是一个我认为有更好答案的问题，所以不应该违反规则。

我问这个是因为主游戏循环是一个 Runnable 实例，我锁定到 60FPS(目前大致如此。几毫秒的差异，因为当前的渲染循环非常便宜并且 1000/60 每个周期损失一到两毫秒)。不通过 Thread.sleep() 锁定帧速率会导致大约每秒 2.3 十亿 帧(显然)，这可以理解我的 CPU。不是问题，更多的是为什么需要帧锁定的例子。

然而，在我遇到的每一个答案、每一条评论中，大多数人都说“你为什么要触摸 Thread.sleep() 你不想让 EDT hibernate ”。如果您的循环中存在导致无响应的缺陷，这是可以理解的，但在我放在一起的应用程序中情况并非如此。我已经阅读了所有相关的事件调度线程文档，如何使用 Swing Timers 等。我什至自己也使用过 Timers 和 SwingWorkers(在一种情况下将图标加载委托(delegate)给后台以防止 GUI 实例化时出现阻塞) .

这里甚至有首选方法吗？我还没有遇到很多/任何不依赖 libgdx 的 Java 独立游戏解决方案。

Answer 1

在以下情况下使用 Swing Timer:

您不想限制或控制更新之间的时间。 Swing Timer 仅保证“至少”持续时间(它将在给定延迟后触发)并且处理事件的时间长度可能会影响下一次更新之前的时间量。

所以，如果你有 16 毫秒的延迟(大约 60fps)，你的回调需要 20 毫秒来处理，第一次和第二次回调之间的时间实际上可能是 36 毫秒

当您想使用 Swing 提供的现有(被动)渲染系统时，您也可以使用 Swing Timer

Swing Timer 相对简单易用，它在 Event Dispatching Thread 中触发回调，使得修改游戏状态和安排 UI 更新变得容易，这减少了可能线程竞争条件(在绘画和更新之间)

在以下情况下使用Thread#sleep:

您希望更好地控制时间，从而产生可变延迟。为此，您需要管理自己的 Thread

这种方法更适合更复杂的动画，以及当您使用 BufferStrategy 来控制输出时。

这样做的原因是，使用 Thread 方法，您会冒着在线程更改状态和绘制周期绘制状态之间出现竞争条件的风险。相反，您需要自己控制绘制过程，这样您就知道在绘制某些东西时，状态不会在您进行时发生变化。

使用这种方法可以提供更大的灵 active 和控制力来决定何时完成(以及如何完成)，但会增加做事的复杂性和您的责任