Well, SFML is annoying.

[Disch]

But including DLLs with your program defeats half the point of dynamically linking. Seems rather absurd to me.

Anyway I'm not trying to say the ATI thing isn't a problem. I'm just saying it's not as big of a problem as you guys are making it out to be. There's a workaround for it: statically link. Do that and there's no problem.

Now the issue with Intel cards that doesn't have a workaround.... That is a huge problem and is worth getting upset over. It's also one I was unaware of.

[GetOutOfBox]

Disch wrote:

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.

[BHX]

Dynamic linking can't be all that bad, seems every commercial game use dynamic linked libraries because every time a issue happens it is normally a DLL missing or corrupted. Static linking, reason I don't like it, is because it puts everything from the library into the executable so you are including functions you don't even use or add-ons you didn't even use and adding bloat to your executable.

[Disch]

BHXSpecter wrote:

Dynamic linking can't be all that bad, seems every commercial game use dynamic linked libraries because every time a issue happens it is normally a DLL missing or corrupted.

Commercial programs do it for two reasons:

1) licensing issues
2) makes it possible to upgrade just the dll (and not the entire install) if there's a bugfix released for a specific library.

As an indie developer, how often do you plan on taking advantage of benefit #2? And what licensing issues do you have that are solved by #1?

Unless you have a good answer for those, dynamically linking does absolutely nothing for you.

The only other benefit to dynamically linking is the fact that several different programs can share the same binary. Which is defeated entirely when you bundle the dll in the distribution package. Besides... frankly C++ sucks in that arena because DLLs built in X version of Y compiler are completely incompatible with exes unless they were also built in X version of Y compiler.

That's the main reason why you're expected to build SFML (and other popular C++ libraries) yourself, rather than just being handed a prebuilt DLL.

Static linking, reason I don't like it, is because it puts everything from the library into the executable so you are including functions you don't even use or add-ons you didn't even use and adding bloat to your executable.

First of all: That's not true.

Second of all: You have that totally backwards.

The DLL is what has to contain everything (even stuff you don't use -- because it has no way of knowing what programs that link to it will be using... so it has to have everything).

Statically linked libraries are linked into the exe during the build phase, which means they can be (and are) optimized to remove stuff you aren't using.

Compare file sizes sometime.
The combined size of a dynamically linked exe+dll will always be larger than the same statically linked exe.



EDIT

Holy crap I didn't see you giant reply GetOutOfBox.

GetOutOfBox wrote:

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.

I couldn't disagree more. IMO you should prefer static by default and only use dynamic if you have compelling reason to. See my reply to BHXSpecter.

Note that I'm speaking on Windows here, since Windows' setup for dynamic libraries sucks. *nix is another matter, and has the exact opposite problem... it's setup for statically linking sucks. So there I would prefer to dynamically link.

but Intel cards by-design will not work with a critical component of SFML2, sf::RenderTexture

I've already said I agreed that this is a serious problem. I agree 100%.

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."

It's not really like that at all. I don't know why people hold individual indie developers up to the same standards as professional development teams.

A game publisher has dozens of programmers each working 40+ hours a week on the product.

Laurent is one guy putting in half that time.... maybe.


But again I don't disagree with you that this is a serious problem and really should be addressed. I really do agree with you there. This is a very legitimate reason to not want to use SFML.

He's to lazy

Again... lower your standards. It's one man, and he doesn't even do this for a living. It's a side project. Saying someone is "lazy" at their hobby is retarded.

[BHX]

Really? Damn, I've been told the other for years now and since I never paid attention to my exes when I was done I assumed it was right lol.

[REVISION]
Will have to start doing static linked then.

Laurent said it is him and a friend doing the library. My issue with the API is that it is ugly for my tastes, and I have said that to him numerous times though they are hung up on it. There isn't anything he can do that would change my mind. It may be the cleanest API ever made, but my tastes are to where it is ugly to me. This is why I said it was an opinion, because there isn't anything he could do that I would change my thoughts on as I have a specific taste for casing, naming, etc.

[GetOutOfBox]

Disch wrote:

I couldn't disagree more. IMO you should prefer static by default and only use dynamic if you have compelling reason to.

I'm not saying static should never be used, I'm more saying it's not a huge deal, but it's best to use dynamic, if it suits the situation. If you have a small application that only uses a couple of libraries (and small ones to), sure, statically link. Might as well. However, if you're talking a huge game that makes use of many libraries, it's much easier to just release a tiny patch in the case an important update is released for one of the runtimes. This also opens up the capability of a self-updating application. If the applications binary is replaced as part of the update process, you can't use built-in updating. Not only could this save you a shitload of server bandwidth for distribution, but it allows for quicker updates, on your part and the users, most notably in the fact you don't have to recompile your application.

Disch wrote:

Again... lower your standards. It's one man, and he doesn't even do this for a living. It's a side project. Saying someone is "lazy" at their hobby is retarded.

I'd be very grateful if he implemented one of the solutions, but what I expect is that as a library developer, he would responsibly maintain his documentation. It's one thing for him to straight-out say "My library won't work properly in this context, I'm working on it." and quite another to say "I'm not going to bother explicitly mentioning this in the documentation, the developers should figure it out themselves. If they can't, well survival of the fittest", which has been repeatedly his attitude towards flaws in the API.

Mind you, my point was not that he should be chained to his desk until a fix is released, it's just that I feel that if most developers, myself included, would work tirelessly to fix such a monstrous problem, as a matter of personal pride. These aren't minor bugs, they are huge flaws that render his API mostly useless on a great majority of computers.

Furthermore, what irks me about this whole scenario is not so much the problems themselves, it's that the main website, and even the documentation does not reflect them, and as such I spent a great deal of time migrating my project from SDL to SFML, when it could have been to an actually functional library like Allegro. Essentially, I'm saying he should make a choice; make it clear what the current problems are on the main website, so as to prevent people from wasting a shitload of time (I could have been near finished the project before discovering this problem, which would have meant a shitload of work migrating to yet another library), or to simply fix the problems. And as BHXSpecter and a few others mentioned, the forums are filled with douchebags. Surprisingly, Laurent himself is fairly nice when it comes to assistance, but there are a lot of users with Hero Worship Syndrome, who assume that any problem you're having couldn't possibly be something wrong with their god-API, and will say things like:

"Update your drivers" (yeah sure, a minor driver update is going to completely fix a problem with simple 2D game, and in any case, how many developers do you know that don't bother keeping their drivers up to date?)
"You could be doing X better." (where X is unrelated to the problem at hand, i.e telling you using manual memory management is bad, something that seems to be brought up whenever example code has new/delete in it)
"Read the documentation" (I did. That's why I came to the forums)

[Disch]

You make very valid points GetOutOfBox. I can't see anything you just posted that I disagree with. I think we are mostly in agreement, but perhaps you tend to care more and/or are more judgemental about it than I am... .which is understandable since you were burned by it.

[naraku9333]

Looking at the issue http://github.com/LaurentGomila/SFML/issues/101 and the thread GetOutOfBox quoted from http://en.sfml-dev.org/forums/index.php?topic=7407.0 I get the impression Laurent is taking it seriously, but if it is purely an Intel driver issue there isn't much he can do.

[naraku9333]

@GetOutOfBox
Can you post some code that doesn't work on your GMA965? I have a GMA945 and 2 ATI cards I'd like to test. I tried simply creating a RenderTexture but has so far run fine on my intel and ati cards.

[formerBGIuser]

This is a very interesting thread. I've had alot of experiences with SFML hanging up in App.Clear() back when I was fiddling around with SFML 1.6. I got SFML 2.0RC to work when I do the static link about a month or two back. Still, I think SFML is fundamentally flawed from a software engineering perspective because almost all of the important functions don't return error codes. Interestingly, the people on the site recommend it for pro-dev and I just don't understand how a library/api that creates a window in Renderwindow::Renderwindow(), with not even a possibility of an error code or a graceful failure could be considered ready for pro-development.