GL_MAX_TEXTURE_IMAGE_UNITS?

[Jabberwocky]

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. 

[binary1248]

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.

It's funny really, even after all this time and numerous other court cases, one would expect them to wise up and provide a fair playing ground for OpenGL as well. Packaging a default DirectX driver and a barely usable OpenGL driver is just as bad as packaging Internet Explorer without any alternatives with a default installation of Windows. I wonder how long and if it ever happen that they will end up in court again because of this. The problem with this kind of a lawsuit is that it isn't easily understandable by "your average consumer". They don't know the difference between DirectX and OpenGL, and they are the ones that the plaintiffs have in mind when going to court. Put simply, nobody bothered to make enough noise for this to become a real issue, and the ones who could have already been in Microsoft's boat for a long time.

I really wonder how Vulkan support on Windows will turn out to look like. It is a direct competitor to DirectX 12, so there is already an obvious motivation to hinder its proliferation from the get-go. Maybe this time around they won't be able to get away with it that easily since consumers/media have become more tech-savvy and would already be on the lookout for such things this time around.

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.

That's the thing, since SFML is licensed under zlib, there is no obligation to even mention it in your final software. People around here have been working hard to track down projects that do indeed make use of SFML, and all I can say is that there doesn't seem to be a lack of them.

And about "build it, and they will come": SFML is not a for-profit organization. I don't see any need to lure new developers into using it, for whatever reason one could think of. It's not so much a question of "What can SFML do for me?" rather than a question of "Can I do what I need to with SFML?". The library isn't developed with the aim of a larger userbase in mind, if you ask me, if more people use SFML, it would be primarily because they only just heard of it, or something that was hindering their adoption of it in the past has been resolved. SFML still lacks many features that we want supported as well, and it will take time, but when the work is done, people will be able to compare SFML to its "rivals" more easily and go for whichever API they feel the most comfortable using.

The key to the growing user base is not attracting new users but making sure the ones who previously rejected SFML for whatever reason have less reason to do so in future releases. This ultimately just comes down to clearing out bugs and implementing features that have been long awaited and direly needed.

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

Remember what I said about "real programmers"? Yeah...

I can live with the fact that the superstition and general misinformation exists in the heads of the consumer, but I don't think it is unreasonable to demand that someone who seriously considers themselves a developer should know better. Nowadays there is really nothing that DirectX can do that OpenGL can't, I've said this many times in the past and am still waiting for someone to prove me wrong.

Also, about the console support: I think indie developers who come to SFML asking if it supports consoles underestimate the amount of effort/money it takes to support them, both on SFML's side and the developer's side. There is a reason why you barely see any indie titles on consoles, and if it ever happens, then most of the time it is a port of a successful title from the PC to the console after some time has passed. Indie developers should really just focus on getting a foothold in the PC market before venturing off into higher-risk territory.

[Jabberwocky]

Packaging a default DirectX driver and a barely usable OpenGL driver is just as bad as packaging Internet Explorer without any alternatives with a default installation of Windows.

Yeah, I have read that the default OpenGL drivers on windows boxes are crap.

From opengl.org

Without drivers, you will default to a software version of OpenGL 1.1 (on Win98, ME, and 2000), a Direct3D wrapper that supports OpenGL 1.1 (WinXP), or a Direct3D wrapper that supports OpenGL 1.1 (Windows Vista and Windows 7). None of these options are particularly fast, so installing drivers is always a good idea.

In your experience, what has been the general approach of OpenGL-based software on windows?  Simply some kind of instructions to update your drivers, perhaps on the website?  And probably a crap-ton of support cases of people who ignored those instructions and are experiencing terrible performance?  Or is there some better way of handling it?

I really wonder how Vulkan support on Windows will turn out to look like. It is a direct competitor to DirectX 12, so there is already an obvious motivation to hinder its proliferation from the get-go.

Yep, there's a battle brewing for sure. I doubt we'll see MS change their tactics on this.

That's the thing, since SFML is licensed under zlib, there is no obligation to even mention it in your final software. People around here have been working hard to track down projects that do indeed make use of SFML, and all I can say is that there doesn't seem to be a lack of them.

Is this the list?

For sure, I don't mean to dismiss those lightly.  There's a couple in there I'm pretty excited about.  I've got a feeling moonman is going to do quite well.  I chipped in to it's kickstarter.

And about "build it, and they will come": SFML is not a for-profit organization. I don't see any need to lure new developers into using it, for whatever reason one could think of.

Yeah, totally.  I get it. 

Non-profit open source is interesting in its relationship between the creators and users.  I imagine there is usually some desire to see FOSS used in cool projects.  But there is certainly no obligations to serve users in any way.

Also, about the console support: I think indie developers who come to SFML asking if it supports consoles underestimate the amount of effort/money it takes to support them, both on SFML's side and the developer's side.

Totally agreed.

[binary1248]

In your experience, what has been the general approach of OpenGL-based software on windows?  Simply some kind of instructions to update your drivers, perhaps on the website?  And probably a crap-ton of support cases of people who ignored those instructions and are experiencing terrible performance?  Or is there some better way of handling it?

glGetString() with GL_VENDOR and GL_RENDERER will return strings like "Microsoft Corporation" and "GDI Generic" respectively. If you see any of those, chances are the user didn't bother to install proper drivers themselves or their OEM lied to them and/or simply don't care when they provided their driver package for download. The latter case is easier to answer: Never buy hardware from them again. The former case is a bit trickier. The first half of the problem is informing the user that there might be something wrong, the second half is getting them to acknowledge there is something wrong and take corrective measures. If they do choose to perform corrective action, I can imagine opting to open a browser pointing to either the AMD or Nvidia driver download pages to save them the hassle of searching themselves.

I can imagine some really stubborn/ignorant people implying things like "But XYZ games run fine so why should I have to fix anything?" not knowing the difference between OpenGL and DirectX. You can try to educate these people all you want, but just remember, the longer it takes the less likely the chance of success. In my experience, an average gamer who doesn't know the difference between OpenGL and DirectX and thinks that gaming on Linux is just a myth will not care if you can help them fix the problem. They will just declare your game as "broken" although it is in fact their operating system that is broken instead. This is the core strategy behind Microsoft's campaign against OpenGL if you ask me, and it has worked for them so far, because, well... people are simply too stupid to know any better .

Steam has made it worse over the years. It "guarantees" that stuff will work out of the box, not even requiring the basic intelligence to install a game manually any longer, so if something doesn't work on the first try after installing from Steam, it is always the developer's fault. I don't think Steam even has a mechanism for checking driver versions yet, so you are pretty much screwed when distributing a native OpenGL game on Windows. It looks to me like Valve is advocating "DirectX on Windows and OpenGL on SteamOS when possible". I find it kind of hypocritical of them to push for more games to support OpenGL when their own distribution platform doesn't even try to make the situation better, but that's just my take on their marketing politics, so yeah...

[Jabberwocky]

\glGetString() with GL_VENDOR and GL_RENDERER will return strings like "Microsoft Corporation" and "GDI Generic" respectively. If you see any of those, chances are the user didn't bother to install proper drivers themselves or their OEM lied to them and/or simply don't care when they provided their driver package for download. The latter case is easier to answer: Never buy hardware from them again. The former case is a bit trickier. The first half of the problem is informing the user that there might be something wrong, the second half is getting them to acknowledge there is something wrong and take corrective measures. If they do choose to perform corrective action, I can imagine opting to open a browser pointing to either the AMD or Nvidia driver download pages to save them the hassle of searching themselves.

Much appreciated.

I'm not too worried about the stubborn/ignorant people.  I'll just make sure to very clearly indicate up to date graphics drivers are necessary in the system requirements.  Beyond that, I won't feel guilty if someone refuses to follow a few simple steps that should be part of any gamer's regular routine.

About Steam and driver updates -
Now that you mention it, I definitely recall Steam telling me a new driver was available.  I just can't remember whether it was on Linux or Windows.  I just booted up steam (windows), and see that there's a menu option:  Steam > Check for Video Driver Updates

Provided that works as advertised, that makes support quite a bit easier.