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