OpenGL Textures Disappear

[RandomDever]

Whenever I toggle fullscreen all my textures disappear.
Why?

------------------------------------------------------------------

And on a side note go play my first game:

http://donsvoice.com/randomdever/Duck%2 ... 01.0.0.zip

[eatcomics]

I think there was a moosader topic about this...
http://board.moosader.com/viewtopic.php ... tion#p4150

I do believe that its explained there. If not please post and maybe give us some more information. Maybe your rendering code, the size of your textures, and maybe some hardware specific stuff, IE monitor type and size, graphics card. I'm pretty sure that that link says it all

[epicasian]

Your game looks really polished! I love the graphics, btw:D

[Milch]

I'm pretty sure that you'll have to reload all your textures - because the context gets recreated.

[GroundUpEngine]

Nice first game, the art is funny man! aha

[cypher1554R]

Wow! I'm impressed with your first game. Well done!

I used to have one of those Nintendo consoles Got pretty nostalgic now seeing your remake.
Plus, I had that photo-gun controller 'twas pretty sweet.

Keep it up!

[RandomDever]

Thank you all for the encouragment.
@eatcomics: broken link?

Well right now I am working on making a 'ReloadTextures()' function using 'list's but I can't remember how the iterator works.
All I want it to do is go through the list and give me every item in it and my logic will do the rest.
If anyone could clear that up or post a link to an example it would be appreciated.

[Milch]

Here you go, lazy bastard
http://www.cplusplus.com/reference/stl/list/

And this example covers a iterator
http://www.cplusplus.com/reference/stl/list/insert/

[RandomDever]

Well Milch I had already looked at that but I missed something important.
the iterator has to be dereferenced before it will access the list item.
But now it gives me this:

Code: Select all

video.obj : error LNK2019: unresolved external symbol __imp___CrtDbgReportW referenced in function "public: struct GLtexture2d * const & __thiscall std::list<struct GLtexture2d *,class std::allocator<struct GLtexture2d *> >::_Const_iterator<1>::operator*(void)const " (??D?$_Const_iterator@$00@?$list@PAUGLtexture2d@@V?$allocator@PAUGLtexture2d@@@std@@@std@@QBEABQAUGLtexture2d@@XZ)

Yeah. That's gotta be THE longest error of all time.

[qpHalcy0n]

This isn't actually an OpenGL problem in itself. Your GL driver automatically backs up all resources and assets in what DX would call "managed" memory, which is normally mapped directly to system memory. So when resize events happen, the device is able to restore the assets and you don't have to do a thing.

You're using SDL or SFML or similar aren't you?

[eatcomics]

Thanks for telling me bout the broken link chaos rift regulars xD IDK what happened to it...

so do you still have the problem... I didn't read the thread...

Edit: found out why, moosader updated her site... its forum.moosader now... not board... oh well...

[Milch]

This isn't actually an OpenGL problem in itself. Your GL driver automatically backs up all resources and assets in what DX would call "managed" memory, which is normally mapped directly to system memory. So when resize events happen, the device is able to restore the assets and you don't have to do a thing.

You're using SDL or SFML or similar aren't you?

So, why does it happen?
Because I don't think that SDL/SFML break the context(or do something similar), or do they?

[qpHalcy0n]

Surely.

If SDL or SFML either implement canvases or render surfaces as pbuffers (which may or may not be the case), pbuffers will get lost on resize or minimize events. This is a terrible implementation if this is the case as pbuffers suffer a myriad of latency issues. I do know that SDL is exceptionally wonky when it comes to dealing with resizes and if you ARE using SDL there is a really daft workaround that must be done to prevent the API from destroying your device on resize events (This does NOT have to be done w/ OpenGL devices). This is not an OpenGL problem, this would be an API problem w/ SDL which is probably a drawback from some weird design limitation. The other problem that I'm aware of is that some of the Intel integrated chips, namely the 940's, are just ATROCIOUS in terms of drivers, so bad that many developers, including myself, refuse to develop for them. These chips will lose assets on resize or minimize events due to a driver limitation.

If any of these are NOT the case, I'd be curious to see what you're doing there to cause this.

[RandomDever]

@qpHalcy0n: SDL. If what you mean by "Rendering Surfaces" is an SDL_Surface * then yes I do use them for loading textures.
@qpHalcy0n: But are you are saying that I shouldn't use SDL ( At least for rendering ) or what?
@qpHalcy0n: If so what do I use?

[qpHalcy0n]

@RandomDever ah...yep, that'd be why then. SDL does NOT deal with video mode switches effectively or appropriately in any way shape or form whatsoever. It's extremely wonky.
@RandomDever I'm not saying that, necessarily. I am saying that you'll have to employ a cheap workaround for this to not happen. This workaround has some drawbacks.
@RandomDever If you abandon SDL you'll have to manage all of this yourself.

The reason this happens is because on a resize, minimize, or mode switch, SDL *literally* makes an entirely new window, which is just stupendously silly. This will in fact necessitate the device be explicitly destroyed then recreated. This is the crux of your problem. It is however completely unnecessary to do on SDL's part so it seems like a very shortsighted limitation of that particular API. This is only really exhibited when it's used in conjunction with OpenGL. That said, supposedly this was fixed and it should only recreate windows on mode switches....but again, there are no guarantees in terms of it's behavior with OpenGL. I always encourage people AWAY from SFML and SDL for these particular reasons. They're both atrocious libraries and handle typical events quite haphazardly.

So what you should do is several-fold. You should attempt to see if the API allows you to query whether a mode switch is actually occuring on window resize. You should wrap all of your asset initialization code into one handy location so that you can invoke this when you have a new window. This will make it easier to reload all assets. If you are calling or ultimately the API is invoking a video mode switch you'll need to see if there's a flag that can stop this from happening.

The hack is as follows and has the following limitations:
*Obtaining the video surface pointer from SDL will become unreliable as the result will be to a video surface that no longer exists.
*Obtaining relative mouse positions to the window will no longer be reliable.

On a video resize event, if you seek to keep all of your textures and assets, DO NOT call SDL_SetVideoMode.....ever.... It's not required by the OpenGL driver, but will jack with SDL's window state machine. So like I said, all operations and queries regarding the window that was resized then become unreliable. You will have to reset the viewport and any viewing transforms that are aspect ratio dependent. The other option is to simply do the video resize and manually re-upload all of your assets.

I leave the choice to you, good sir ...these are your options :]