这种情况的双向数据结构

时间:2012-04-16 14:12:45

标签: c++ data-structures

我正在研究我的游戏引擎的一小部分,并想知道如何优化某些部分。

情况非常简单,如下:

  • 我有Tile s的地图(存储在二维数组中)(~260k的瓷砖,但假设更多)
  • 我有一个Item的列表,它总是至少是一个瓷砖
  • Tile逻辑上可以包含无限量的Item s
  • 在游戏执行期间,会不断创建许多Item个,并从他们自己的Tile
  • 开始
  • 每个Item不断将其Tile更改为其中一个邻居(向上,向右,向下,向左)

到目前为止,每个Item都有对其实际Tile的引用,我只保留一个项目列表。 每当Item移动到相邻的磁贴时,我只需更新item->tile = ..,我就没事了。这很好但是它是单向的。

在扩展引擎时,我意识到我必须多次找到瓷砖中包含的所有物品,这实际上会降低性能(特别是在某些情况下,我必须找到一系列瓷砖的所有物品,一个一个)。

这意味着我想找到一个适合查找特定Tile的所有项目的数据结构,而不是 O(n),但我希望避免太多开销在“从一个瓷砖移动到另一个瓷砖”阶段(现在它只是指定一个指针,我想避免在那里做很多操作,因为它很频繁)。

我正在考虑使用自定义数据结构来利用项目总是移动到相邻单元格但我正在黑暗中摸索的事实!任何建议都会受到赞赏,甚至是棘手的或神秘的方法。不幸的是,我不能浪费内存,因此需要进行良好的权衡。

我正在使用STL在C ++中开发它,但没有Boost。 (是的,我确实知道multimap,它不满足我,但如果我找不到更好的东西,我会试试)

3 个答案:

答案 0 :(得分:2)

struct Coordinate { int x, y; };
map<Coordinate, set<Item*>> tile_items;

这会将图块地图上的坐标映射到项目指针的集合,以指示该图块上的项目。您不需要每个坐标的条目,只需要实际上有项目的条目。现在,我知道你这么说:

  

但我想避免在“从一块瓷砖移动”中花费太多开销   到另一个“阶段

此方法将涉及在该阶段增加更多开销。但你真的尝试过这样的事情,并确定这是一个问题吗?

答案 1 :(得分:0)

对我来说,我会将std::vector包装成矩阵类型(IE在1d数组上强加2d访问),这样您就可以快速随机访问任何瓷砖(实现矩阵是微不足道的)。

使用

 vector_index=y_pos*y_size+x_pos;

索引大小为

的向量
 vector_size=y_size*x_size;

然后每个项目都可以有std :: vector项目(如果tile具有的项目数量非常动态可能是deque),这些随机访问包含的开销非常小。

我会远离你的用例的间接容器。

PS:如果你想要,你可以拥有我的矩阵模板。

答案 2 :(得分:0)

如果您真的认为每个瓷砖商店的商品都会花费您太多空间,请考虑使用四叉树存储商品。这样您就可以有效地获取图块上的所有项目,但可以将Tile网格留在原位以便项目移动。