无需 GetData() 的 XNA 2D 变形地形碰撞检测

发布于 2024-10-31 06:38:45 字数 305 浏览 1 评论 0原文

我目前正在开发一款涉及地形变形的《百战天虫》游戏。我曾经使用 .GetData 来完成此操作,修改颜色数组,然后使用 .SetData,但我考虑更改它以使工作在 GPU 上完成(使用 RenderTargets)。

一切都很顺利,但我遇到了另一个问题。我对地形的整个碰撞检测都是基于代表地形的颜色数组,但我不再有那个颜色数组了。每次修改地形来更新我的颜色数组时,我都可以使用 .GetData,但这会破坏我最初更改的目的。

我可以接受的是在开始时使用 GetData 一次,然后根据我稍后通过其他方式对地形所做的更改来修改该数组。我不知道该怎么做,有人可以帮忙吗?

I'm currently working on a Worms game which involves terrain deformation. I used to do it with .GetData, modifying the color array, then using .SetData, but I looked into changing it to make the work done on the GPU instead (using RenderTargets).

All is going well with that, but I have come into another problem. My whole collision detection against the terrain was based on a Color array representing the terrain, but I do not have that color array anymore. I could use .GetData every time I modify the terrain to update my Color array, but that would defeat the purpose of my initial changes.

What I would be okay with is using GetData once at the beginning, and then modifying that array based on the changes I make to the terrain later on by some other means. I do not know how I would do this though, can anyone help?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

深海蓝天 2024-11-07 06:38:45

我做了一些研究,还没有找到一种解决方案来摆脱每次修改地形时的任何 GetData 调用,但我已经找到了“优化”它的方法,或者至少减少了 GetData 调用尽可能多。

  • 火山口绘制是批量绘制的,这意味着我不是在创建时绘制每个火山口,而是将它们添加到列表中并每隔几帧绘制所有火山口。这减少了 GetData 调用的数量 - 每批陨石坑一次,而不是每个陨石坑一次。

  • 将坑绘制到渲染目标后,我会等待几帧,然后再调用 GetData 以确保 GPU 已处理所有绘图命令。这可以最大程度地减少管道停顿。

  • 如果我有一个待处理的 GetData 调用,并且有更多的陨石坑进入,则陨石坑将保持批处理状态,直到 GetData 调用完成。换句话说,绘制和获取是同步的,因此 GetData 调用总是在绘制一批火山口后的几帧发生,并且任何新的火山口绘制请求都会等到挂起的 GetData 之后。

如果其他人有任何其他建议,我仍然很高兴听到他们。

I've done a bit of research, and I have yet to find a solution to getting rid of any GetData calls every time my terrain is modified, but I have found ways to "optimize" it, or at least reduce the GetData calls as much as possible.

  • Crater drawing is batched, meaning that rather than draw each one as it’s created, I add them to a list and draw all of them every few frames. This reduces the number of GetData calls – one per batch of craters rather than one per crater.

  • After drawing craters to the render target, I wait a few frames before calling GetData to make sure the GPU has processed all of the drawing commands. This minimizes pipeline stalls.

  • If I have a pending GetData call to make and more craters come in, the craters will stay batched until the GetData call is complete. In other words, the drawing and getting are synchronized so that a GetData call always happens several frames after drawing a batch of craters, and any new crater draw requests wait until after a pending GetData.

If anyone else has any other suggestions I would still be glad to hear them.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文