所以，我正在用Java创建一个自上而下的2D游戏。
我正在按照Java 2D: Hardware Accelerating - Part 2 - Buffer Strategies的说明来利用硬件加速。
基本上，我在想的是：
我希望能够轻松地向地图添加更多部分。所以我宁愿不去看我所看到的一些教程中建议的路线（每个地图图块都有一个周围图块的邻接列表;从中心图块开始，用广度优先搜索填充屏幕）。 / p>
相反，我的想法是拥有屏幕大小的图块集合（例如32x32以简化），并且每个屏幕“块”将具有引用每个相邻集合的列表。然后，我将为当前屏幕和8个相邻屏幕创建一个缓冲区，并在VRAM缓冲区中绘制可见部分。
我的问题是，这是一个正确的方法来解决这个问题，还是有更好的选择？我看了很多教程，但它们似乎都提供了相同的（看似很高的维护）选项。
这似乎是一个更好的选择，因为在磁贴级别进行操作需要1024倍的邻接列表。另外，我考虑在VRAM中只放置可见部分，同时将“当前”屏幕及其相邻屏幕留在标准缓冲区中的原因是因为我是硬件加速新手，并不完全确定假设有多少空间可以接受可用。因为Java无论如何都试图加速标准缓冲区，理论上它应该与将每个缓冲区放在VRAM中一样快吗？
欢迎提出任何建议！
答案 0 :(得分：3)
我没有查看任何热门的tile-based game engines，但我会考虑使用fly-weight pattern仅渲染JScrollPane视口中可见的切片。 JTable既是示例又是可用的实现。
附录：JTable方法的一个优点是view-model separation，它允许人们将与图块相关的资源的获取转移到模型中。这样可以更轻松地进行优化，而无需更改视图。
即使没有滚动条，也可以通过扩展JComponent或适当的子类来利用scrollRectToVisible()。 setDoubleBuffered()方法也可能有所帮助。