我应该对 2D 滚动地图使用什么缓冲策略？
因此，我正在用 Java 创建一个 2d 自上而下的游戏。
我正在遵循 Java 2D：硬件加速 - 第 2 部分 - 缓冲区策略 利用硬件加速。
基本上，我的想法是这样的：
我希望能够轻松地向地图添加更多部分。因此，我宁愿不走我看过的一些教程中建议的路线（每个地图图块都有一个周围图块的邻接列表；从中心图块开始，使用广度优先搜索填充屏幕）。
相反，我的想法是拥有屏幕大小的图块集合（为简单起见，假设为 32x32），并且每个屏幕“块”都有一个引用每个相邻集合的列表。然后，我将为当前屏幕和 8 个相邻屏幕创建一个缓冲区，并在 VRAM 缓冲区中绘制可见部分。
我的问题是，这是解决这个问题的正确方法，还是有更好的选择？我已经浏览了相当多的教程，但它们似乎都提供相同的（看似高维护）选项。
这似乎是一个更好的选择，因为在图块级别执行操作将需要 1024 倍的邻接列表。另外，我考虑只将可见部分放入 VRAM 中，同时将“当前”屏幕及其相邻屏幕保留在标准缓冲区中的原因是因为我对硬件加速不熟悉，并且不完全确定可以接受多少空间可用。因为 Java 无论如何都会尝试加速标准缓冲区，所以理论上它应该与将每个缓冲区放入 VRAM 一样快？
欢迎任何和所有建议！
So, I'm creating a 2d top-down game in Java.
I'm following instructions from Java 2D: Hardware Accelerating - Part 2 - Buffer Strategies to take advantage of hardware acceleration.
Basically, what I'm thinking is this:
I'd like to be able to easily add more sections to the map. So I'd rather not go the route suggested in a few of the tutorials I've seen (each map tile has an adjacency list of surrounding tiles; beginning with a center tile, populate the screen with a breadth-first search).
Instead, my idea would be to have screen-sized collections of tiles (say 32x32 for simplicity), and each of these screen "chunks" would have an list referencing each adjacent collection. Then, I would create a buffer for the current screen and the 8 adjacent screens and draw the visible portion in the VRAM buffer.
My question is, would this be a correct way to go about this, or is there a better option? I've looked through quite a few tutorials, but they all seem to offer the same (seemingly high maintenance) options.
It would seem this would be a better choice, as doing things at the tile level would require 1024 times as many adjacency lists. Also, the reason I was considering putting only the visible portion in VRAM, while leaving the "current" screen and its adjacent screens in standard buffers was because I'm new to hardware acceleration and am not entirely sure how much space is acceptable to assume to be available. Because Java attempts to accelerate standard buffers anyways, it should theoretically be as fast as putting each in VRAM?
Any and all suggestions are welcome!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我还没有看过任何流行的基于图块的游戏引擎< /a>，但我会考虑使用 fly-weight 模式 仅渲染图块可见于
JScrollPane的视口。JTable既是一个示例，也是一个可用的实现。附录：
JTable方法是视图模型分离，这允许人们将与图块相关的资源的获取归咎于模型。这使得优化变得更加容易，而无需更改视图。即使没有滚动条，也可以利用
scrollRectToVisible()通过扩展JComponent或适当的子类。setDoubleBuffered( )方法也可能有帮助。I haven't looked at any of the popular tile-based game engines, but I'd consider using the fly-weight pattern to render only the tiles that are visible in the viewport of a
JScrollPane.JTableis both an example and a usable implementation.Addendum: One advantage of the
JTableapproach is view-model separation, which allows one to relegate the acquisition of tile-related resources to the model. This makes it easier to optimize without having to change the view.Even without scroll bars, one can leverage
scrollRectToVisible()by extendingJComponentor an appropriate subclass. ThesetDoubleBuffered()method may be helpful, too.