🔒 Locked

making my texture manager

Started by fireking Nov 19, 2003 at 6:19 PM 5 replies 500+ views

Original Post

Nov 19, 2003 at 6:19 PM

hey guys, i gotta question. I was sitting here programming my texture manager, and i was working on the texture class (the texture manager will manage an array of texture classes). And i was thinking, well after you load the texture into gl, you have the option to keep the data, or delete it, cuz open gl moves it into the video card, and when you delete pData (an array of bytes), it has no effect on the texture, because open gl has already moved it. I was wondering, should i program support to keep textures in memory in case you want to perform operations like, getcolor, setcolor, and so on, OR does open gl already have these type of operations that can be performed on textures (like setting pixel, getting pixel, and so on)?? Your help is appreciated!

Raloth

Nov 19, 2003 at 6:24 PM

If you need to get the data from the texture then definately keep a copy of it yourself. Otherwise, you can let the driver handle transfering it back and forth between system memory and video memory when you run out of video memory.

fireking

Nov 19, 2003 at 6:31 PM

i think im going overboard with the texture manager, but i want to code it once and forget about it

i wanna be able to do image operations on any texture at anytime, so im programming it to do so

i was just wondering if opengl had some sort of method of changing the texture while it was in memory, or if you actually had to make changes on your own, with your own memory/data, then re-bind the texture to open gl's texture stuff (which is probably slow as hell, but im not talking real time effects here)

[edited by - fireking on November 19, 2003 7:32:26 PM]

fireking

Nov 19, 2003 at 7:19 PM

Let me clarify

im loading the image into system memory first, because thats how all texture loading works (loading all the pixels within the texture into an array, and then passing that to open gl in the gentextures function)

im asking if open gl has the capability to edit these textures in video memory, even after i''ve destroyed the system memory copies, or if i should keep the texture within the system memory for modification (then updating opengl because the texture has changed)

Raloth

Nov 19, 2003 at 7:26 PM

If you know you are going to be reading the data, then you should absolutely keep the data in system memory as your own copy. Reading from data in the video card is horribly slow. If you don''t need to actually know what data is on the card then you don''t have to worry about keeping the array of pixels. You can use glTexSubImage2D to update only part of a texture, but in my experience it isn''t as fast as I would like it

LousyPhreak

Nov 20, 2003 at 9:14 AM

Raloth:
if glTexSubImage2D is to slow what else would you use to update texture data

fireking:
glTexSubImage2D would defiantely be the way to go unless you also want to support reading from textures in which case you need to leave the textures in memory as reading from the gfx card is incredibly slow. also keep in mind if editing textures in memory you should upload them with glTexSubImage2D instead of glTexImage2D as glTexImage2D creates internally a new texture (slow) but glTexSubImage2D just updates the pixel data.

benjamin bunny

Nov 20, 2003 at 9:44 AM

I wouldn't bother maintaining a local copy of the image data. In my experience it's rarely, if ever, needed. If I happen to need a local copy of an image then I'll just keep a copy when I load it, like this:


mTexImage("foo.bmp");
Texture* tex=TextureManager::inst().loadTextureFromImage(mTexImage);

[edited by - benjamin bunny on November 20, 2003 10:53:44 AM]

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.