|I think he actually said it doesn't work unless you statically link. Don't people do that for Windows binaries anyway? I know I sure do. In which case it's a nonissue.|
The only time that you can strongly justify static linking is if your software is dependent on a certain version of libraries (or a certain build), and you want to make sure it is using that specific version. Technically static linking results in performance gain, but that gain is rarely tangible, unless you are perhaps calling shitloads of libraries.
Anyways, note that that 70% comprises of BOTH Intel integrated GPUs and AMD cards. Yes, statically linking (the SFML 2 library, which is still in RC phase and has not been locked yet, and I'd note that before SFML 2, you were simply screwed when it came to AMD cards. There were a few hackish solutions that didn't consistently work across all cards) bypasses the problem for AMD cards, but Intel cards by-design
will not work with a critical component of SFML2, sf::RenderTexture. To put in perspective how sf::RenderTexture is important, here's a list of things its used for:
V-Sync - sf::RenderTextures are the only way to implement backbuffers in SFML2 (render everything to a surface off-screen, then draw that surface and begin drawing the next frame, etc, etc). SFML2 by-design only allows you to easily render to sf::RenderTextures, rather than any drawable surface, which is good design, WHEN IT WORKS :( Note that with SDL, you could "blit" one surface to another, be it an ordinary surface to a screen, or vice-versa, etc.
Applying shaders - You can apply a shader directly to the screen surface upon every draw to that surface, however it's better design to draw everything to a backbuffer, then apply the shader to it, as if you have tons of sprites being drawn the screen at various times, it's difficult to assure the shaders being applied consistently without messy code.
Rendering a 3D object to a 2D surface - If you want to render a 3D object or scene created with OpenGL code to a 2D texture which can applied at will (i.e 3D backgrounds in a 2D game), you have to use sf::RenderTexture.
Essentially, sf::RenderTexture is the only drawable surface in SFML that emulates a window/screen surface, without actually being attached to one. And this class straight-up doesn't work on Intel cards, with the exception of the one really new line that Intel integrates with their Core i7 GPUs (which are desktop only anyway). To picture how damning this fact is, consider the fact that most laptops use Intel integrated CPUs. Since it's fairly safe to assume that most 2D game fans probably haven't bothered investing in expensive gaming rigs, that means most of your target audience will not be able to play your SFML game, unless you make no use of sf::RenderTexture, which is severely limiting, and justification enough to use another library.
Laurent (author of SFML) seems like a fairly nice guy compared to most of the people on his forum, however I don't think he realizes the impact of these problems. Here is a direct quote of one of his responses to people complaining about the Intel problem:
|I'm not sure to understand what you want me to tell you.|
RenderTexture are known to be broken with Intel graphics, and I've already said that I'd work on this problem soon after SFML 2.0 is released. So what else do you expect me to say or do?
Note that the post that's from was made 3 months ago, and this problem has existed since SFML2's conception, which was more than a year ago. And he thinks it's a low enough priority problem that it should be fixed post-release. That's like a game publisher being told their game will not work on 30% of their customers computers, and they respond with "Oh. We'll see if we can figure it out and make a patch for it later. Can't guarantee anything."
I think it's also worth noting that this problem isn't exactly a nebulous one, it arises simply from the fact that sf::RenderTexture is an abstraction of an OpenGL FBO (Framebuffer-object), which Intel has repeatedly "forgotten" to implement, or implemented wrong. In this case however, there are some fairly obvious alternatives, such as rendering to a flat OpenGL plane off-screen. I believe one can make 2D games in DirectX using a similar process. Yes, this approach is very much less optimized, but it is also better than silently failing.
Here's yet another instance of SFML's quirks that Laurent hasn't bothered putting anywhere in the website. If you draw an sf::RenderTexture before calling Display() on it, the resulting draw will be upside down. Sure, it's not a bug, but a big enough quirk that could cause hours or days of nightmarish debugging to no avail. And when asked to put some kind of warning in the code or website tutorials, he replied:
|If something goes wrong then read the doc. Isn't it enough? ;)|
Note that the docs have no mention of this problem. What he expects is that you'll notice that the docs have a certain order to display-draw calls, which they assume you'll follow. He's to lazy to even explicitly add a note saying "FYI calling draw before display will produce an upside down result" so that someone googling the problem could find the explanation.