[SOLVED]Textures disappearing out of existence.

[Halsys]

Can buggy drivers cause textures to disappear from existence? Ie. The "latest" WHQL Nvidia 320.18 drivers.
Because this has been a thing only for my windows builds.
Second thing.... does SFML have any code that I can put a break point on to figure out this problem?
(Like if the texture is drawing without a texture or if a texture became corrupt?)

Because asking all this is easier than just saying that my textures are disappearing and blaming it on SFML for something I'm not entirely sure how it could do it.

Any help would be great!

[MrMuffins]

Can drivers cause problems? Yes. In fact sometimes can prevent programs from running (for some reason)

The 320.18 drivers seem to be bad...here's what it did to someones battlefield 3:
http://i.imgur.com/agsJfgnh.jpg

I suggest rolling back to a version that worked for you until they figure this out.

[OniLinkPlus]

Nvidia's 320.18 drivers are known to literally fry people's GPUs and make them unusable. I highly suggest reverting back to a previous version of the drivers.

[Halsys]

Just confirming everything now... The textures do disappear because of the drivers.

#0 64A3D420     ??() (C:\Windows\SysWOW64\nvoglv32.dll:??)
#1 6699772B     sf::Texture::~Texture() () (C:\PROJEC~1\PROJEC~1\bin\Debug\sfml-graphics-2.dll:??)
#2 00BDCB78     ?? () (??:??)
#3 00000017     ?? () (??:??)
#4 ??   ?? () (??:??)
 

Points to the Nvidia OpenGL 32 library that was packed with this ever so buggy driver.
So yeah... Its busted...

On a side note... what scares me to think that this some how slipped WHQL inspection and became a "Stable" driver on the Nvidia web site and since its release they have done nothing to fix this ridiculous bug.

[Halsys]

Crap its in 314.22 as well..... now what... Go back further? or debug deeper?

[Mario]

The backtrace you posted actually shows that the texture is destroyed by the driver (which is obvious and right). But it also shows that SFML's destructor for sf::Texture is calling it, so not the driver's fault at all. Instead, your texture is destroyed, probably due to going out of scope. Are you by any chance storing copies of sf::Texture in a STL container or something similar?

[Halsys]

Are you by any chance storing copies of sf::Texture in a STL container or something similar?

I am... on a std::map... I use a string to reference each texture and look them up when I need them. It lets me improve performance by only loading the texture once. Does that have anything to do with the glitch? How do you suppose I fix this?

[Nexus]

Just confirming everything now... The textures do disappear because of the drivers.

#0 64A3D420     ??() (C:\Windows\SysWOW64\nvoglv32.dll:??)
#1 6699772B     sf::Texture::~Texture() () (C:\PROJEC~1\PROJEC~1\bin\Debug\sfml-graphics-2.dll:??)
#2 00BDCB78     ?? () (??:??)
#3 00000017     ?? () (??:??)
#4 ??   ?? () (??:??)

I have no clue how you come to this conclusion. The stack trace doesn't let you infer driver bugs.

Using std::map is not a problem per se -- you only have to be careful at the time of insertion, where a copy is performed. So that you don't let pointers refer to the local object which is inserted.

Other than that, we cannot say anything without code. The only way to find out whether drivers are the problem in your case is to come up with a complete and minimal example.

[Halsys]

Okay, this is embarrassing... but at least its solved.
Basically my code does a check(Makes sure the actor type is not blank*) on a string inside my actor class and sometimes the string gets reset for some reason(Still unknown but I know the effect happens when a Box2D bullet hits a actor). So the texture and the way it was stored was not an issue. But that doesn't mean these new nvidia drivers escape the noose... They still need to fix my skyrim and BF3! D:

*Note to self.... Replace with enum instead!

[Nexus]

Maybe some copy constructor or assignment operator which you forgot to define, or which is implemented wrong?

I would suggest to abstract all this C++-specific technical stuff (like defining the Big Three, or managing memory) away, as far as possible. Those are mostly boilerplate code and correspondingly error-prone. If you use value semantics and RAII, most of your classes don't need the Big Three or any delete operators. Also make sure you adhere to const-correctness, it prevents you from accidentally changing values.