I was wondering, when someone will implement a decent glCopyTexImage function, why it’s so slow to copy a part of the frame buffer to the texture memory, without intervention of the CPU?
It will be much faster in our next major driver release.
- Matt
oh i say spiffing news. i take it the same applies to glCopyTexSubImage, im using it quite a bit in me game.
[edit] one more thing why is it quite a bit slower using GL_LUMINANCE than GL_RGB with glCopyTexSubImage (conversion i expect) its a pity cause most of stuff is greyscale.
[This message has been edited by zed (edited 11-30-2000).]
Yes, it’s a SW format conversion.
When you’re doing a copy, always try to match the internal format of the texture as closely as possible to that of the framebuffer.
So the preferred texture internal formats are:
16-bit color: RGB5
32-bit color w/o destination alpha: RGB8
32-bit color w/ destination alpha: RGBA8
Assuming that the user hasn’t changed the registry key that sets the default texture depth, you can use RGB when there’s no destination alpha and RGBA when there is, and we will pick 16-bit or 32-bit based on the screen color depth. If you don’t trust the user, use RGB5, RGB8, and RGBA8.
- Matt