   Handling textures and id's
  Hi I just modified nehe's loading code to get rid of glaux and I started using a bitmap class that I found open on the internet.  The problem is not with the bitmap class, it appears to be loading an initializing just fine, I can even apply the textures to cubes and such.  The problem is, I can only do 1 at a time, or run multiple calls to LoadTexture("texturename").I'd like to be able to give each texture a texid (generated by glgentextures) so I can support multiple textures, and I also need a way to be able to reference all my textures, since I won't necessarily know their texid number.  Maybe if I explicitly defined a list of resources based on what glgentextures pumps out to me.I could apply a string id that is the filename to each bitmap object, then I could  search through a map with the string to return the properly generated gl tex id.  Although I wonder about the overhead of this, and maybe if there is a more efficient, simpler way?int LoadTexture( const char *filename )// Load Bitmaps And Convert To Textures{Bitmap image;// Create Storage Space For The Textureimage.Load(filename);GLuint texture = 0;// Texture IDBitmap * pImage = &image;// Load The Bitmap, Check For Errors, If Bitmap's Not Found Quitif ( pImage != NULL && pImage->GetImg() != NULL )// If Texture Image Exists{glGenTextures(1, &texture);// Create The Texture// Typical Texture Generation Using Data From The BitmapglBindTexture(GL_TEXTURE_2D, texture);glTexImage2D(GL_TEXTURE_2D, 0, 3, pImage->GetWidth(), pImage->GetHeight(), 0, GL_RGB, GL_UNSIGNED_BYTE, pImage->GetImg());glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER,GL_LINEAR);glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER,GL_LINEAR);image.~Bitmap();}return texture;}I think maybe I should add a static iterator to the bitmap object, but then that's just a copout and essentially a global in disguise.  What would you all suggest?   
  That code should supply you with a unqiue id each time; now if you are assigning that id to the same variable each time when it returns, that's another matter.As for the name=>id mapping; yes a map is a perfectly valid way of doing it. The key is to ONLY perform that string to id lookup at load time and then store the id in the class which represents that object so you have direct access to it.   ;Quote:Original post by phantomThat code should supply you with a unqiue id each time; now if you are assigning that id to the same variable each time when it returns, that's another matter.As for the name=>id mapping; yes a map is a perfectly valid way of doing it. The key is to ONLY perform that string to id lookup at load time and then store the id in the class which represents that object so you have direct access to it.Ah yes, that makes sense, I was wondering about the overhead of such an operation and I suppose the best solution is to not do that processing during the rendering loop.As for the unique ID, how do you suggest I generate one of those each time I run this function?Should I keep a static iterator in the bitmap class?  Or should I use local variables and return them to a map wrapper along with the filename to find them later.  When I say local variables I mean I could just do all my texture loading in one function, LoadTextures instead of LoadTexture.  I could pass the function a set of filenames to look for, (instead of just one), and loop through the loading/tex id generating process and return a resource map that I can insert into the texture buffer.;  glGenTextures(1, &texture); will generate the id for you   ;  Cool, I guess all that is left to finish is changing the parameter/return types and looping the loading code.EDIT: Quick question..Where should I sit the LoadTextures function?  Right now it's hanging out in my main .cpp file, should I throw it in a namespace along with a bunch of other graphics api specific functions?Should I create a renderer class for this function?   ;  Hello,A bit unrelated, but why do you do this ?Bitmap * pImage = &image ;and then image.~Bitmap();Isn't it simpler to use the 'image' variable ? The destructor will be called if image goes out of scope I guess.kind regardsUncleEDIT : added source tags   ;Quote:Original post by UncleRemusA bit unrelated, but why do you do this ?*** Source Snippet Removed ***and then *** Source Snippet Removed ***Isn't it simpler to use the 'image' variable ? The destructor will be called if image goes out of scope I guess.And in fact, the original code causes the destructor to b called twice: once manually, and once automatically by the compiler — which is a very, very bad idea. Never manually call the destructor for an object on the stack!   ;Quote:Original post by kerilynneCool, I guess all that is left to finish is changing the parameter/return types and looping the loading code.EDIT: Quick question..Where should I sit the LoadTextures function?  Right now it's hanging out in my main .cpp file, should I throw it in a namespace along with a bunch of other graphics api specific functions?Should I create a renderer class for this function?Right now, I wouldn't worry too much about it, you can always move it later if it becomes a problem [smile]   ;  I think I see the big picture.The game says I need these objects.The objects request to have their resources added to the load queue, it's processed and hooked up to opengl and given tex id's in loadtextures, each object that made the request for their resources now need direct id's for instant lookup.So we have a few things to deal with here.The game logic will demand some objects.The objects, cubes, models, etc etc, will add themselves to the load queue.During the gl initialization i'll process the load queue and return the objects their specific id's and such. (how to do this I'm not sure).I suppose what I can do is have a list of the objects.And as we go down the list of objects(logical entities), they'll request that the renderer get various resource id's and return them.  That would deal with each object 1 by 1.Or I could save the id's in the renderer as I create them, then have some other method to match the id's.  As long as I process the objects and their textures in a contiguous way, matching them up will be simple.What would you all suggest?   