OpenGL: Is it acceptable to work with textures like 2500*2500 pixels?

Of course the texture will not be completely visible on the screen. And I can make it always draw just the visible part (With glTexCoord2f and then glVertex2f). (It is the big "level"-image, which I have to move around for a sliding camera). Notice this rendering has to be real-time in my game (game is written in C++).

A short calculation:

2,500 * 2,500 = 6,250,000 pixels
6,250,000 pixels * 4 bytes / pixel = 25,000,000 bytes
25,000,000 bytes = 23.8 MiB

So, is 23.8 MiB not to much for a cross-platform commercial game? Knowing that people can have all sorts of grap开发者_如何学Gohical cards.

That's a lot for one texture. Shouldn't be too much of a problem if the video card has enough memory to keep it onboard (at least 32MB, and that's if you have nothing else in your game! 128MB is actually more reasonable), but if it doesn't then the system will have to push the bits to the video card each frame as long as it's on the screen. That can cause a massive slowdown.

If you can get away with making the texture smaller, i'd highly recommend it. If possible, since it won't all be visible at once, you might try breaking it up into several pieces -- only the visible ones will have to be in video memory, which means less memory used if you break it up at the right places.

I believe cards that support SM3 guarantee 4Kx4K textures will work (can't find confirmation, though).

Cards that support DX10 guarantee 8Kx8k textures will work.

As others have said, power of two textures should be preferred.

And last but not least, the maximum size is not only related to memory used, it has direct impact with the precision that the hardware has to treat the texture coordinates. Since DX10, e.g. requires that you can access up to 6bits of sub-texel precision, the hardware has to handle texture coordinates in a format that can address 19=13 (for 8k texels) +6 bits (for sub-texel addressing) (ignoring repeat wrap mode for now).