I am currently working on a beginner level tutorial using SFML and just ran into a show stopper that I want to share. If you are already using SFML 1.6, this is probably old news to you, but it caused me enough pain that I want to share it here. Maybe someone in the future will find this on Google and they wont end up wasting a couple hours like I just did.
Anyways, I was developing away at my game and doing most of my work on my portable laptop, which has an integrated Intel chipset. On occasion I did a little bit of work on my primary development laptop which has a higher end Radeon GPU and everything works fine. Anyways, earlier this week Deus Ex: Human Revolution came out and PC gaming being what it is, I had to download and install the latest drivers. Fast forward to today, I load up the project make a few changes and:
Completely hung. Zero response whatsoever. If I run the same application outside of Visual Studio, it requires me to kill it in Task Manager.
So I jump to the logical conclusion and figure it was something I changed recently in my code, so I start hacking and slashing out the changes until I am back to nothing. Still hangs. WTF? Now I start hacking even more until the point I get to my main() consisting of a single return statement and still it hangs! WTF x2? Obviously at this point it’s a linker problem, and my lost likely culprit is SFML, so off to Google I go!
End result, yes, the dynamically linked version of SFML apparently has a bug with the OpenGL implementation of modern ATI drivers. Yay. Apparently it is only in the dynamic version of SFML, so you can switch to static linking and it will go away, but when writing a tutorial, this kind of added complication simply isn’t realistic. That said, there is a work around and there is a fix… of sorts.
Apparently the problem is caused in atigktxx.dll and you can grab a copy that works here ( along with additional explanation ). I haven’t an actual clue what the bug itself is ( it’s wayyyyyy outside my code ), but by including this copy of atigktxx.dll in your executable folder, it overrides loading the one that is installed on your machine, thus preventing the bug.
Oh, and although that post was in February and the fix is “coming soon”, the problem still occurs. I do however believe this is fixed in the 2.0 version of SFML, but please don’t quote me on that!
So, long story short, if you are using SFML 1.6 and you want to support ATI cards with recent drivers, ship your game with atigktxx.dll in your executable directory.
Oh and moral of the story… don’t always go blaming your code first! I kow have a ton of damage to undo that I needlessly caused! Moral number two… ATI still suck at making drivers!