A Puzzlement
Author
Riddle: When does glGenTextures not give a texture name?
The line in questions is
glGenTextures( 1, &texId );
...where texID is an GLuint initialized to 0;
The story is that in my lab's video-watching software project, we need to bind the video texture to certain OpenGL objects. This line of code was working fine (meaning that texID starts off as an unitialized GLuint, and is then 'filled' by glGenTextures and set to 1) in our old code, but then we merged some versions, moved up from Visual Studio 2003 to Visual Studio 2005, and suddenly when we run the code texID just refuses to be filled by glGenTextures.
I know there are alot of variables involved here, I'm just looking for ideas that I can follow up on. Why on earth would glGenTextures ever NOT fill up the passed variable?
Thanks!
are you calling glGenTextures inside a glBegin/glEnd block?
Nothing dictates that it'll be filled with 1, even if it's the first texture you create.
How are you checking to see if texID is being changed? I suggest initialising it to 0.
Quote:Original post by Elahrairah
texID starts off as an unitialized GLuint, and is then 'filled' by glGenTextures and set to 1)
Nothing dictates that it'll be filled with 1, even if it's the first texture you create.
How are you checking to see if texID is being changed? I suggest initialising it to 0.
Have you tried initialising your variable to some other value (such as some very high value)?
As I understand it, that's what the original poster is already doing.
Quote:I suggest initialising it to 0.
As I understand it, that's what the original poster is already doing.
It sounds to me like you're doing this:
1) Initialising texId to zero
2) Passing it to glGenTextures
3) Checking to see if texId is still zero.
That isn't fool-proof, if OpenGL runs out of memory then then the results of calling the function are undefined.
The correct way to determine whether a call worked and what, if anything, went wrong is to call glGetError in a loop until you get GL_NO_ERROR. The error codes returned before that will tell you what's up, otherwise you can assume the function worked.
As mentioned, you shouldn't assume that glGenTextures returns contiguous sequences of numbers, it's allowed to return *any* non-zero integer that isn't currently in use.
1) Initialising texId to zero
2) Passing it to glGenTextures
3) Checking to see if texId is still zero.
That isn't fool-proof, if OpenGL runs out of memory then then the results of calling the function are undefined.
The correct way to determine whether a call worked and what, if anything, went wrong is to call glGetError in a loop until you get GL_NO_ERROR. The error codes returned before that will tell you what's up, otherwise you can assume the function worked.
As mentioned, you shouldn't assume that glGenTextures returns contiguous sequences of numbers, it's allowed to return *any* non-zero integer that isn't currently in use.
Author
Quote:Original post by dmatter
As mentioned, you shouldn't assume that glGenTextures returns contiguous sequences of numbers, it's allowed to return *any* non-zero integer that isn't currently in use.
Even then, though, shouldn't I be getting a number OTHER than zero?
The only time I used glGenTextures() and no name was generated was because openGL wasn't initialized when glGenTextures() was called. Could it be your problem?
Author
Quote:Original post by dmatter
The correct way to determine whether a call worked and what, if anything, went wrong is to call glGetError in a loop until you get GL_NO_ERROR. The error codes returned before that will tell you what's up, otherwise you can assume the function worked.
Do I just stick this loop right after the line I'm suspicious of?
Quote:Original post by ElahrairahQuote:Original post by dmatter
As mentioned, you shouldn't assume that glGenTextures returns contiguous sequences of numbers, it's allowed to return *any* non-zero integer that isn't currently in use.
Even then, though, shouldn't I be getting a number OTHER than zero?
Only if it succeeded, besides the rare case of running out of memory, if the function fails then it won't do anything at all.
Quote:Do I just stick this loop right after the line I'm suspicious of?
Yeah, that'll do it, unless of course the error happens prior to that function (which could also explain why the call fails). It might be worth checking the error state before and after calling that function whilst debugging.
Author
Right... looks like the gl error flag is set to GL_INVALID_OPERATION before we hit this line of code.
So now I'm assuming I need to track down what invalid operation that is.
Which I did... I traced it back to...
...the beginning of the whole program. Right at the start of my Main() the gl error flag is still set to GL_INVALID_OPERATION.
Um.... ideas?
Thank you for taking pity on a n00b!
So now I'm assuming I need to track down what invalid operation that is.
Which I did... I traced it back to...
...the beginning of the whole program. Right at the start of my Main() the gl error flag is still set to GL_INVALID_OPERATION.
Um.... ideas?
Thank you for taking pity on a n00b!
Use a tool to help track down which function causes INVALID to be thrown
http://glintercept.nutty.org/
http://glintercept.nutty.org/
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
