Oh well, maybe I am just gone mad, or maybe I always was blind. We all know there was a time in which there was only TexImages, so texture must be stored in (''application'') memory, however now we have texture objects and things are a little changed... OpenGL specification, version1.4 - july 2002, pag 126 ... "The image indicated to the GL by the image pointer is decoded and copied into the GL''s internal memory." ... -------------------------------------- I may put down a lot of words on how much this is new to me. Every techdemo I saw on the internet was doing: GenTextures() TexImage() ... .. .. DeleteTextures() delete[] textureData; I always thought texture data should be in memory while the app is running - in fact, I thought, if a texture trashing occurs, the GL is going to retrieve the original texture data from that array. Well, I''m not so sure of that, I actually think we can do that: GenTextures() TexImage() delete[] textureData; ... .. .. DeleteTextures() As I said before, maybe I am gone mad, maybe I was stupid not figuring out this before, however, it makes sense. Furthermore I tried it out and it seems to work. BTW, many games reload textures from disk when a GL change mode occurs and this can be explained easily with the above reason... The texture is simply NOT avaiable in ''application'' memory. I would like someone to tell me if this is correct, since it means I always wasted twice the memory I need to store a texture - BTW it may be a good thing to know, I feel not many ppl knows that, at least most people writing the texturing techdemos I have seen.

yes...

just think of it this way:

why would the video card possibly want to access the computers memory when drawing a texture? surly it''s own memory will be probably 100s of times faster.

when it comes to reloading, probably the best bet is storing the file name of the texture, unless it needs decoding, ala jpg. in which case it may be wise to keep a buffer. Chances are it will get moved to virtual memory anyway so won''t be too much of an issue.

| - Project-X - my mega project.. big things comming soon - | - adDeath - an ad blocker I made - | - email me - |

quote:

---

Original post by RipTorn
...
why would the video card possibly want to access the computers memory when drawing a texture? surly it's own memory will be probably 100s of times faster.

---

*Texture trashing* for example. Having 25MB of textures on a 16MB card will probably cause this.

In case of trashing, I always though the card would access this array to retrieve the original texture... hey looks like it won't.

BTW, the thing applies to vertex arrays - they are actually NOT stored in fast memory - at least not explicitly (the driver may optimize this) - unsless you use VAR or stuff like that.



[edited by - Krohm on January 12, 2003 10:25:39 AM]

In OpenGL, the driver is responsible for keeping the texture as it is. If this requires the driver to keep it''s own copy in system memory, then it will do so. But you, the programmer that uses OpenGL, can safely release the pointer used by the original image as soon as you have passed it to OpenGL.

Vertex arrays are different. Textures are stored on the server side of OpenGL''s client/server model, but vertex arrays on the client side. This is why you can release the texture data, but not the vertex array data. This is also why you use glEnableClientState instead of glEnable, as in the case with textures, to enable vertex arrays.

Oh well, this was exactly what I was thinking - I was just in search of a confirmation.

I guess keeping textures in memory is a very old fashioned way to do the thing, probably a old residue from when texture objects where extensions.

Thanks for your reply brother Bob - having someone who explicitly confirmed the idea (also in reference to VA) was what I was hoping when I posted the thread.