XNA 内存中加载了太多纹理

发布于 2024-10-13 23:56:47 字数 289 浏览 4 评论 0原文

我正在开发图形引擎的关卡编辑器。最近,随着一个项目的扩展,我遇到了内存问题。特别是,关卡相当大,需要加载大约 300 个不同大小的纹理。一些纹理非常大,例如 2048x2048,其他纹理较小,例如 256x256 或 512x512。不管怎样,编辑器在这个关卡消耗了 1.3GB 内存,并且一些纹理无法加载,因为它会抛出内存不足的异常。那么我这里有什么解决方案呢?

目前我能想到的唯一解决方案是将关卡分成更小的部分,并根据可见区域按需加载纹理。但我相信这会在场景中导航时大大降低性能。有什么想法吗?对于关卡编辑来说,在这个问题上应该有一些标准方法。

I am working on a level editor for a graphics engine. Recently, as one project expanded I have been experiencing memory issues. In particular, the level is quite big and around 300 textures of varying size need to be loaded. A few textures are quite big like 2048x2048, others are smaller like 256x256 or 512x512. Anyway, the editor consumes 1.3gb of memory for this level and some textures can't be loaded as it throws out of memory exceptions. So what solutions do I have here?

Right now the only solution I can think of is to divide the level into smaller parts and load the textures on demand, depending on the visible area. But I believe this would slow down the performance big time when navigating in the scene. Any thoughts? There should be some standard approach for level editors on that matter.

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

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

发布评论

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

评论(2

猫弦 2024-10-20 23:56:47

使用不同质量的纹理可能是一个好主意,如果您距离很远,请使用 64x64 纹理,那么当您靠近时,请继续将其交换为 128x128、256x256、512x512 等...还要重新考虑使用以下纹理2056x2056,因为最好有 4 个 1024x1024 纹理:)。

(注意:生成 mip-map 可以部分执行此操作,但不会释放计算机上的内存)

编辑:还可以尝试打开 DXT5 纹理压缩,这可能会节省大量内存!

It might be a good idea to use with different quality of textures, if you're far away use the 64x64 texture, then when you get closer keep swaping it out to 128x128, 256x256, 512x512, etc... Also reconsider using textures of 2056x2056, since its better to have 4 1024x1024 textures :).

(note: generating mip-maps partially does this, but doesn't free memory on your computer)

Edit: also try to turn on DXT5 texture compression, that might save a lot of memory!

暖阳 2024-10-20 23:56:47

您基本上有两个选择

  1. 切换到基于图块的方法。如果您使用图块,这意味着您可以一遍又一遍地重复使用相同的纹理,这可以节省大量内存。
  2. 按照您的描述切换到按需。

我认为,如果您的艺术方向与基于图块的方法并不真正相符,那么您将需要开始考虑方法#2。需要考虑的一些事情

  • 它不一定要慢,只要您的“活动”区域足够大,这样您就不会因加载太频繁而对磁盘造成影响,应该没问题。
  • 衡量衡量衡量,你可能必须更好地掌握你的内存预算是多少,并围绕它设计你的关卡,而不是设计直到碰壁。 :-)
  • 维护单独的内容管理器,请记住,您无法卸载通过内容管理器加载的单个内容,因此请保留一个管理器列表,您可以在移动时更换这些管理器。

You basically have two options

  1. Switch to a tile-based approach. If you're using tiles, that means you can re-use the same texture over and over which saves a lot of memory.
  2. Switch to on-demand as you described.

I'm thinking that if your art direction doesn't really mesh with the tile-based approach, so you will want to start thinking about approach #2. A few things to think about

  • It doesn't necessarily have to be slow, as long as your "active" regions are big enough so that you don't thrash the disk by loading too often you should be fine.
  • Measure measure measure, you probably have to get a better grip on what your memory budget is, and design your levels around that rather than designing until you hit a wall. :-)
  • Maintain separate content managers, remember that you can't unload an individual piece of content loaded through contentmanager, so keep a list of managers that you can swap out as you move around.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文