OpenGL：纹理大小和视频内存
我正在使用 OpenGL 制作一款《百战天虫》风格的位图可破坏地形游戏。我想知道视频内存对于世界大小的限制在哪里。
目前，我使用 512*512 RGBA 纹理块作为地形。
- 我预计这样的 512*512 RGBA 纹理会占用多少内存？
- 是否有任何内部自动压缩正在进行？
- 我期望大多数用户的计算机可以有多少可用视频内存？
I'm making a Worms-style bitmap destructible terrain game using OpenGL. I'd like to know where the limitiations in terms of video memory are for the size of the worlds.
Currently, I use blocks of 512*512 RGBA textures for the terrain.
- How much memory, very roughly, can I expect such a 512*512 RGBA texture to take up?
- Is there any internal, automatic compression going on?
- How much video memory can I expect most user's computers to have free?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
信息不足。您应该始终使用大小合适的OpenGL图像格式 (GL_RGBA8 ，GL_RGBA16）。
GL_RGBA8每个像素占用32位，即4个字节。因此，512*512*4 = 1MB。
不。
您目前使用的是多少？
OpenGL将根据可用空间将图像数据分页进出。如果 GPU 内存不足，OpenGL 将乐意分配系统内存并根据需要上传图像。
但说实话，你的小百战天虫游戏实际上不会消耗任何内存大小。完成后可能有 64MB，顶。这不是你需要担心的。
Not enough information. You should always use sized OpenGL image formats (GL_RGBA8, GL_RGBA16).
GL_RGBA8 takes up 32-bits per pixel, which is 4 bytes. Therefore, 512*512*4 = 1MB.
No.
How much are you using currently?
OpenGL will page image data in and out according to the available space. If you run out of GPU memory, OpenGL will happily allocate system memory and upload the images as needed.
But to be honest, your little Worms game isn't going to actually cost anything in terms of memory size. Maybe 64MB when you're done, tops. It's nothing you need to be concerned about.
我不会太担心这个。即使有 8192*2048 世界（4 个屏幕宽，2 个屏幕高，这对于百战天虫风格的游戏来说非常大），您也只需要 8*2*4=64Mb（添加 mipmap、其他纹理、帧缓冲区），您应该适合 128MB界限。据我所知，即使是较旧的 GPU 也有这种内存（我们不谈论 GeForce4 卡，对吧？）。
较旧的 GPU 可能对每个纹理的大小有限制，但由于您已经将世界分割成 512x512 块，所以这不会成为问题。
如果视频内存成为问题，您可以允许用户使用一半大小的纹理（即将世界采样到 4096*1024 和 256x256 缝隙）并按需获取新的/丢弃未使用的区域。
I would not worry about that very much. Even with 8192*2048 world (4 screens wide and 2 screens tall, which is very big for Worms-style game) you would require only 8*2*4=64Mb (add mipmaps, other textures, framebuffer) you should fit into 128MB bounds. As far as I know even older GPUs have that kind of memory (we don't speak about GeForce4 cards, right?).
Older GPUs may have limitation on how big each texture could be, but since you already split your world into 512x512 chunks it won't be a problem.
If video memory becomes an issue you could allow users to use half-sized textures (i.e. downsample the world to 4096*1024 and 256x256 chinks) and fetch new / discard unused regions on demand.
使用 32-bpp（4 字节），您将获得 4*512*512 = 1 MB
有关纹理压缩的信息，请参阅：http://www.oldunreal.com/editing/s3tc/ARB_texture_compression.pdf
With 32-bpp (4 bytes) you get 4*512*512 = 1 MB
See this regarding texture compression: http://www.oldunreal.com/editing/s3tc/ARB_texture_compression.pdf
再说一次，这取决于你的引擎，但如果我是你，我会这样做：
由于你的地形纹理可能会重用一些类似马赛克的纹理，并且你需要知道像素是否存在或被破坏，那么给定你使用不大于 256x256 的马赛克纹理，您绝对可以使用 GL_RG16 内部格式（其中每个组件都是一个纹理坐标，您需要从 [0, 255] -> [0.0, 1.0]并且你会为你的地形纹理保留一些特殊的值来指示地形被破坏），使得每个512x512块占用0.5MB。
虽然很想添加一个额外的字节来指示地形存在，但 3 字节格式的缓存效果不太好
Again, this depends on your engine, but if I were you I would do this:
Since your terrain texture will probably be reusing some mosaic-like textures, and you need to know whether a pixel is present, or destroyed, then given you are using mosaic textures no larger than 256x256 you could definitely get away with an GL_RG16 internal format (where each component would be a texture coordinate that you would need to map from [0, 255] -> [0.0, 1.0] and you would reserve some special value to indicate that the terrain is destroyed) for your terrain texture, making every 512x512 block take up 0.5MB.
Although it's temping to add an extra byte to indicate terrain presence, but a 3 byte format wouldn't cache too well