基于图块的 cocos2D-iPhone 游戏的最佳 Z 排序方法？
我想用 cocos2D 制作等距的、基于图块的 iPhone 游戏。
精灵需要绘制在其“后面”的其他精灵之上。我正在寻找最好的方法来做到这一点。
我想避免画家的算法，因为它涉及对每帧的所有精灵进行排序，这是昂贵的。
GPU和cocos2D都支持Z缓冲区算法，所以这就是我想使用的，但有一个问题。有些精灵（例如建筑物）会占用多个图块。为此类精灵分配 Z 值很困难。
这些是我想到的选项：
- 比较两座建筑物并确定哪一栋是“前面的” 简单的。因此可以对建筑物进行排序，然后根据以下条件分配 Z 值 排序顺序。这和画家画的没什么区别 算法。 OpenGL ES Z 缓冲区不是必需的。
- 纯粹根据每个建筑物的位置为其分配 Z 值 地图（不知道其他建筑物在哪里）。我是 发现这很困难。我认为这是可能的，但我没有经历过 还能够想出一个公式。
- 对占用多个图块的图像使用多个精灵，因此 所有精灵的大小都完全相同。 Z 阶可以是 根据精灵占据的图块轻松分配。这 这个解决方案的问题在于它使游戏逻辑变得更加复杂 复杂的。单个建筑物上的所有操作都必须 对组成建筑物的每个精灵重复此操作。我想 将每个对象视为单个实体。
- 修改cocos2D代码，允许精灵有多个Z值 在不同的点。如果一个精灵可以有多个 Z 值 精灵的特定部分落在哪个图块上，然后计算 该部分的 Z 值很容易。我不需要比较 精灵到任何其他精灵。我相信这可以通过使用 每个精灵有多个四边形。问题在于它是 对我来说有点复杂，因为我是 OpenGL ES 和 cocos2D 的新手。我 不完全理解所有内部数据结构如何 工作。尽管如果公式看起来是最优雅的解决方案 找不到。
我会对任何有用资源的建议或参考投赞成票。
I want to make isometric, tile-based, iPhone games with cocos2D.
Sprites need to be drawn on-top of other sprites that are "behind" it. I'm looking for the best way to do this.
I'd like to avoid the painter's algorithm because it involves sorting all the sprites every frame which is expensive.
The Z buffer algorithm is supported by the GPU and cocos2D so this is what I'd like to use, but there is a problem. Some sprites, like buildings for example, occupy multiple tiles. Assigning a Z value to such sprites is difficult.
These are the options I've thought of:
- Comparing two buildings and determining which one is "in-front" is
easy. So buildings can be sorted then assigned a Z value based on
the sort order. This wouldn't be any different from the painter's
algorithm. The OpenGl ES Z buffer wouldn't be necessary. - Assign a Z value to each building based purely on its location on
the map (without knowledge of where other buildings are). I'm
finding this difficult. I think it is possible, but I haven't been
able to come up with a formula yet. - Use multiple sprites for images that occupy more than one tile, so
all sprites will be exactly the same size. Z orders can then be
easily assigned based on what tile the sprite is occupying. The
problem with this solution is that it makes the game logic much more
complicated. All operations on a single building will have to be
repeated for each sprite the building is made-up of. I'd like to
treat each object as a single entity. - Modify the cocos2D code to allow sprites to have multiple Z values
at different points. If a sprite can have multiple Z values based on
what tile a particular part of the sprite falls on, then calculating
a Z value for that section is easy. I won't need to compare the
sprite to any other sprites. I believe this is possible by using
multiple quads for each sprite. The problem with this is that it is
a bit complicated for me since I am new to OpenGL ES and cocos2D. I
don't completely understand how all of the internal data structures
work. Although it seems like the most elegant solution if a formula
cannot be found.
I will up-vote any suggestions or references to helpful resources.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
对于 #2，您可以计算对象中心的曼哈顿距离，并使用该值作为该对象的 z 值。只要您避免地图中很长的物体（例如 5x1 物体或更糟），它就会起作用。但是，如果您确实需要将一个长对象放置在平铺地图中，则通过使用公式设置 z 值来管理地图中对象的 z 顺序是不可能的。
证明这一点：
1.) 将两个 2x2 对象水平放置在地图中，并在它们之间留下一个单位图块。
2.) 在它们之间放置一个 3x1 物体。我们将 2x2 对象命名为 A 和 B，将 3x1 对象命名为 C。
3.) 如果你只是旋转C（不改变它的位置），A和B的z顺序互换。
-如果B现在在前面，B后面的一些物体将因为旋转而在A前面并且要知道 C 旋转后哪些先前位于 A 和 B 后面的物体将变为 A 前面的成本很高。
For #2, you can compute the Manhattan distance of the center of the object and use this value as the z-value of that object. It will work as long as you avoid very long objects in your map like 5x1 object or worse. But if you really need a long object to be placed in a tiled map, managing the z-order of objects in the map by setting a z-value using a formula is impossible.
To prove this:
1.) Place two 2x2 objects in a map horizontally and leave a unit tile between them.
2.) Place a 3x1 object between them. Let's name the 2x2 objects to A and B, and the 3x1 object to C.
3.) If you just rotate C(not changing its position), z-order of A and B interchange.
-If B is now in front, some objects behind B will be in front of A because of just the rotation of C. And it's costly to know which objects in back of both A and B previously will become in front of A after C's rotation.