• Advertisement
Sign in to follow this  

uploading all textures again

This topic is 4408 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I think this question belongs more in General Programming than in Graphics Programming and Theory, but it could be a mix of both. I use SDL + OpenGL for most of my programs. You can set up an OpenGL window (or go fullscreen) with SDL in most operating systems. OpenGL has a very annoying thing though, if I change the resolution of the screen or switch to fullscreen, OpenGL forgets all the textures that I had uploaded (I mean, load them from RAM into the video card)! So I have to upload them all again. This is really a stupid property of OpenGL imho, I've never seen something else forget all it's textures when changing the size of a window... is there a way around this? Because it seems so ridicioulous that maybe I just do something wrong. In your OpenGL program, is it there possible to change the resolution without that it forgets all textures? But if there's no way around it, the only thing I can do when you want to change the size of the window or go to fullscreen, is upload all textures again... However, textures can be created and uploaded at any time in my program. I have a texture class that can load textures from png images or from buffers into an std::vector of the texture class, and the class has an upload function that will store the texture from that std::vector into the 3D hardware with different OpenGL function calls, and it also has a bind function that will make a certain texture (that has already been uploaded) the one that will be used on the current polygons that you're drawing. But after changing resolution I'd have to upload them all again, but how can I know which of all the texture objects floating around everywhere in my program there are, and which ones had already been uploaded? In the "screen" function that changes the resolution I'd need to have a list available of all those textures, but they could be in an entirely different scope!!! Is it possible in C++ to remember a pointer to all textures that have been uploaded somewhere in a publically available location, and add new pointers there whenever a new texture is uploaded? And then use that list to upload them all one by one again when I changed resolution? Or is this a huge overkill for something as simple as remembering all textures when changing relolution or swapping from window to fullscreen?

Share this post


Link to post
Share on other sites
Advertisement
The reason that you lose all of the textures is because when you go from windowed to fullscreen, or changed the screen, you've destroyed the SDL window context. Uploading all of the textures is the only way to do it properly that I know of. I'm still learning OpenGL and SDL and I've learned recently how to get a window to be resizable and still load the attributes and model that I had previously.

Share this post


Link to post
Share on other sites
Quote:
Original post by Lode
Is it possible in C++ to remember a pointer to all textures that have been uploaded somewhere in a publically available location, and add new pointers there whenever a new texture is uploaded? And then use that list to upload them all one by one again when I changed resolution?

Or is this a huge overkill for something as simple as remembering all textures when changing relolution or swapping from window to fullscreen?


What I would do is use a texture manager to manage all texture that are used in your program. I'm actually working with SDL + OpenGL myself atm, and the reason I'm using a manger is for the same reason, besides the fact it makes life easier [wink]. If you want to take a look at my manger that I've written, take a look at this post. For you though, and myself, you'd have to track all the data required for loading the texture along with the texture itself, so you can easily do a silent reload when needed. There are many other uses for using a manager as well, not just for this, so it's definitly not overkill! If you need a more specific example using my code, I'd be more than happy to make one [wink] Good luck!

Share this post


Link to post
Share on other sites
If I'd have a public list of pointers to all textures ever created (or uploaded), then I could add every newly created texture to that list by putting in the constructor of the texture something like "add address of this texture to the list". And then when going fullscreen all I have to do is go through the list with a for loop and use texturelist->upload(). But what if during the program, addresses of textures change (because they're in an std::vector)? Then the pointers in the list won't be updated! How to solve that?

BTW if you go fullscreen, are all textures that used to be in video memory, actually removed from video memory? Or are they still in there but not accessable? (Then there would be useless memory wasted!!)

Share this post


Link to post
Share on other sites
havent read all the previous posts, but you could try to setup a seperate openglrenderingcontext that shares resources with the one you use, then change your sdl window/fullscreen mode, while the seperate oglrc (+windowcontext and stuff you need) keeps all the data in memory. after the mode change of your main window you wont need the seperate oglrc anymore... dunno if it works, but you could try...


T2k

Share this post


Link to post
Share on other sites
As far as SDL goes I don't think you're going to be able to do much if switching from fullscreen to windowed causes all the textures to be lost. If you don't use SDL, then on Linux you should be able to avoid losing the textures in any kind of switch because the colour depth and virtual screen size of X11 servers are fixed, but this might require a bit of hacking to get the windows decorations on/off during the switch. As far as Windows goes, resizing the window will not cause you to lose the context, and actually neither will changing screen mode, however when id software wrote GLQuake they found that despite the fact that it can be done it didn't actually work on any drivers. I don't know if this situation has changed.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement