views:

609

answers:

2

I know this is such a trivial question, yet I haven't found any information that seems to help, starting from glGet()'s documentation. I'm using my textures as sprites, so it's crucial that I keep track of their sizes in texels/pixels.

When I'm creating my textures with glTexImage2D() I'm required to pass the size of the pixel data array to it. But does OpenGL store it anywhere, or do I have to keep track of them in my code? (This feels awkward, as client code would still be able to overwrite the texture with glTexImage2D() / glTexSubImage2D() / glCopyTexImage2D() etc. calls while not changing the size accordingly, thereby resulting in visual distortions.)

+2  A: 

If you really want to rely on GL, use

glGetTexLevelParameteriv(GL_TEXTURE_2D, 0, GL_TEXTURE_WIDTH, &param)

That said, I'm not sure what client code means in your context, but if you're expecting to write middleware that allows your customers to manipulate directly your own state, you're in trouble.

Bahbar
+2  A: 

As Bahbar says, glGetTexLevelParameteri can be used to query the GL_TEXTURE_WIDTH. However, I strongly advise against using this as a general method. For one thing, you can stall the pipeline with glGet* calls, as the driver has to get the GPU to finish what it's doing, figure out what you asked, and return the answer. The result is a massive performance hit.

So you really are better off managing state like this in your own code. Presumably you have a Sprite class (or struct or equivalent), with the texture handle. It's nothing to dedicate a few more bytes to keep track of the width and height, and it will save you from having to hit the driver or GPU to get the information.

As for glTeSubImage*, well that's a policy decision as to when and how you update the texture.

gavinb
while Gets can in theory flush the pipe, I seriously doubt you'll find recent implementations that actually flush. Most drivers store the vast majority of state client-side these days.
Bahbar
I can see how something simple as the dimensions of a texture may be cached client-side, but other `glGet*` queries may depend on things being rendered to answer. And arguably, it is better design to keep the texture metadata in the object (and faster to directly access a data member than call into the driver). Anyway, just about all the books I've read talk about gets causing stalling. Do you have any references for which drivers cache which state information? That would be very handy.
gavinb
thank you - it makes complete sense. my conflict was at the point, where writing functionality for my framework is meaning that the client won't go behind it. I'm guessing that so far these details are documented, it's reasonable to expect that if the client wants to go with the framework AND the desired functionality is provided, they won't ((feel they) have to) hack their way around it.
iCE-9
Yes, it's better to book-keep the state shadow yourself. However, the Gets that require a pipe flush are precisely the ones you can't keep track of yourself. That's why they require a flush. I don't have public references, but then again, it's not _that_ difficult to test. Put a very long operation in the pipe, call a Get, see how long it takes.
Bahbar
I should add that the states that tend to big huge (texture data, e.g.) are an exception. Those are rarely cached on the client side.
Bahbar