A legitimate disadvantage OpenGL has had since the beginning in comparison to DirectX is the lack of a way to check if a feature is truly implemented in hardware or is a mix of hardware/software or even fully implemented in software.
You're such a DirectX fanboy, always going on about how superior it is over OpenGL.
Heh, seriously though, interesting tidbit of info I wasn't aware of.
instead they sort them into hardware classes for which they had done extensive testing during development. If you plan on supporting a wide range of graphics hardware generations, this is really the only sane thing to do.
A wide range of hardware is unfortunately, a luxury most indies don't have.
In the past, I've done pretty well just having a min spec machine, and both AMD and NVidia cards, even if it's just to switch them out on the same machine. These days you should also test on intel graphics too, for games meant to run on low end hardware. Beyond that, you rely on a lot of beta testing to achieve a wider range of hardware.
In the past, I used DirectX on Windows, and OpenGL on linux. Honestly, the linux support was far, far more painful. That wasn't always related to OpenGL issues. Sometimes. MESA drivers suck for anything but the most basic graphics functionality. Other problems were related to distro variations, differences in windows managers, and 32- vs 64-bit interoperability (I couldn't build a 64-bit exe because I used a closed source physics lib which was only available 32-bit). Fullscreen support on dual-monitor systems was a nightmare. I only saw it through it as a labor of love.
Windows was actually pretty smooth. But for the SFML game I'm working on now, we'll have to see how much of a "second class citizen" OpenGL is on windows. Honestly, I'm not quite sure what to expect, and consider it one of the risks of this project. That being said, there will be some advantages to using OpenGL across the board. For example, I won't have to rewrite every shader in both glsl and hlsl. And certainly, SFML is able to keep it's code cleaner, supporting only OpenGL.
Nothing speaks more words than a bunch of links to the code of SFML projects that all contain the same OpenGL code that is lacking in SFML. Often times, suggestions already fail to gain any momentum at this step, and unfortunately I think your suggestion would to.
Fair point.
However, it may be a case of "build it, and they will come". Most of the SFML projects I see are hobby projects with pretty basic graphics. Not that there's anything wrong with that. And maybe this is the user base you prefer to cater to.
I'm actually a bit surprised SFML isn't used by more indie devs, or even full game studios. The API is so much better than your closest direct "competitor". If I had to guess, I'd say that many developers are scared off by the OpenGL-only back end. That may be a combination of legit thinking (e.g. "I can't port to XBox"), and superstition (e.g. "you can't use OpenGL on windows").
I'm not advocating for a DirectX port, as I know most of the SFML team is dead set against it, for both technical and ideological reasons. That's something I need to accept as an SFML user. I'm just identifying it as perhaps a factor behind what might steer a professional studio away from SFML. And how this might thin out the crowd of users interested in more advanced uses of SFML, like we have been discussing.
Maybe a couple breakthrough projects would change all that. Again, I'm not assuming you guys care or not. You probably don't.
Anyway, that's all a bit of a tangent. Incidentally, here's
one indie dev who very much agrees with your guys stance on OpenGL. That post reads very much like it could have been written by the SFML team.
Oh, and thanks for clarifying the "real programmer" comment. I thought maybe things were getting a little tense around here.