   ARB_multitexture and vertex array crash
  Actually it's a little more complicated than that. Here's the deal:* I have the window in normal (restore) mode* I draw a set of elements:   glClientActiveTextureARB(GL_TEXTURE0_ARB);   glTexCoordPointer(2, GL_FLOAT, sizeof(TVector2f), Coord[n]);   glClientActiveTextureARB(GL_TEXTURE1_ARB);   glTexCoordPointer(2, GL_FLOAT, sizeof(TVector2f), Coords[n]);   glClientActiveTextureARB(GL_TEXTURE0_ARB);   glEnableClientState(GL_TEXTURE_COORD_ARRAY);   glClientActiveTextureARB(GL_TEXTURE1_ARB);   glEnableClientState(GL_TEXTURE_COORD_ARRAY);   glActiveTextureARB(GL_TEXTURE0_ARB);   glBindTexture(GL_TEXTURE_2D, T1);   glEnable(GL_TEXTURE_2D);   glActiveTextureARB(GL_TEXTURE1_ARB);   glBindTexture(GL_TEXTURE_2D, T2); glEnable(GL_TEXTURE_2D); glDrawArrays(GL_TRIANGLES, 0, Vert[n]);   * I then disable the second texture unit (having left the loop as insinuated by the index)   glActiveTextureARB(GL_TEXTURE1_ARB);   glDisable(GL_TEXTURE_2D);   * ... and select the first   glActiveTextureARB(GL_TEXTURE0_ARB);   Normally the above code runs just find. However, when I resize (physically drag the size or maximize/iconize) the window, the program crashes at the next call to glDrawArrays(); Removing the last call to glActivateTextureARB() seems to fix that, but that way it will be impossible to draw single texture unit objects later in the code. The program crashes only if the vertex array moves into the visible portion of the screen. Any ideas why that is so?Cheers[edited by - crispy on August 2, 2003 9:25:46 PM]
  Maybe your your context crashed during resizingOtherwise check the Arrays. Maybe some of your arrays have some errors (different lenght?)   Corrailcorrail@gmx.atICQ#59184081 ;quote:Original post by CrispyglClientActiveTextureARB(GL_TEXTURE0_ARB);   glTexCoordPointer(2, GL_FLOAT, sizeof(TVector2f), Coord[n]);   glClientActiveTextureARB(GL_TEXTURE1_ARB);   glTexCoordPointer(2, GL_FLOAT, sizeof(TVector2f), Coords[n]);  This seems suspicious to mee. What are the declarations of ''Coord'' and ''Coords'' ? You''re supposed to pass pointers to the function. ;  OK, first a caveat - I know you generally know what you''re doing with OGL, and these comments are probably going to be simply answered by the fact that you haven''t posted the entire code, especially in light of the fact that you say the code works normally.  That said, here are some things that strike me as suspicious:1. No glVertexPointer used - just not posted?2. Stride parameter to glTexCoordPointer looks odd - may well be valid, but I thought I''d check3. Count parameter to glDrawArrays - again, may be valid but if so Vert is an odd name to choose for an array of triangle counts.Enigma ;  Yes, in fact I did omit a large portion of the code (including calls to glVertexPointer(), glNormalPointer(), glFogCoordPointer() and the respective glEnableClientState()''s and glDisableClientState()''s; as for the stride parameter - making the respective vertex structure non-padded and not adding any additional variables to it will return the size of the actual data in the structure - eg 2 * sizeof(float) in this case). I am passing glTexCoordPointer() a valid pointer and the count parameter in glDrawArrays() is correct as well. The actual coordinate list parameter to glTexCoordPointer() originally looked something like this: &Terrain->Patch[n]->Map[0]  so I thought I''d simply truncate it a little... The same goes for Vert[n] in glDrawArrays().>>Maybe your your context crashed during resizingI don''t see why or how. Furthermore, the program only crashes when I resize and the rendered vertex array moves into the view. Everything else is rendered normally.This morning, however, I ran a mem leak test on my program and got back about a billion reports. Right now I don''t really see where or how, but I''m guessing memory leakage can actually be responsible for this. The fanciest thing is that the program runs fine even after resizing if I don''t select the first texture unit after rendering everything... Then again, memory leaks often make software behave (seemingly) irrationally.Thanks for the response, though - if it''s not the leaks I''ll probably continue this thread. In the meantime - any suggestions are more than welcome ;  Yup - it was due to some memory leak. Originally I got like a 9.04 Mb file in ascii format (around 200000 (two hundred thousand) memory leaks in total! - and I consider myself a careful coder). I removed the most severe 30-40 ones (reduced the total size from 17 Mb to 2 Mb) and now it works just fine. In any case, I learned a lesson: always implement a destructor for all of the classes that need one (yes, there are certain classes that must not have a destructor) and always include a matching delete/delete[] in the destructor to any corresponding new within the scope of the class. I still have a zillion mem leaks to deal with and that number alone is intimidating! Of course, my project is quite large (and most of them are generated in loops and are no more than 4-12 bytes in size), but the point remains nevertheless: ultimately, memory leaks are out to kill your application.Hope somebody reads this and develops a habit of cleaning up their code - I can''t even remember the countelss nights I''ve been browsing through the code, looking for this invisible something that causes the application to crash... ;  I''m kind of curious about your stride parameter.  Do you really have sizeof(TVector2f) between coordinates?  I thought 0 meant tightly packed. ;  Okay I had a second look at the code. I wrote this about two years ago, but it only started crashing now. I don''t know why I''ve written it like that - it doesn''t seem to be the stride parameter as much as the count parameter instead. Upon closer inspection, glTexCoordPointer and glVertexPointer in my code seem to have one parameter less than documented. Changing this parameter doesn''t change the visual side. This is weird - should''ve noticed this before... I guess I thought back then that stride specified an element''s size for some reason - I was obviously wrong. ;  Err, Crispy I was just wondering how do you run a mem leak test? I have no idea how, so I dont know how bad my coding is lol. ThxKazade.   Hyperdev"To err is human, to really mess up requires a computer";  Check your mailedit: can't spell   [edited by - crispy on August 4, 2003 9:11:05 PM]