OpenGL: Texture size and video memory

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 vide开发者_运维技巧o memory can I expect most user's computers to have free?

How much memory, very roughly, can I expect such a 512*512 RGBA texture to take up?

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.

Is there any internal, automatic compression going on?

No.

How much video memory can I expect most user's computers to have free?

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.

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.

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

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