That's some impressive graphics fetishism on display there. It's hard not to take offense at the comment that anything less is not "worthy". Not everyone is a AAA studio with an engine development team, nor should everyone hold themselves to those standards of engine performance.
OpenGL 3.3 is a pretty nice target. It's easy to port an OpenGL 3.3 game to a lot of systems, including mobile, since OpenGL ES 2.1 is pretty similar, and Windows XP, which cannot run DirectX 10. (This matters less as time goes on, but it's been an important point in certain markets in Asia.) So you can write the graphics code once, more or less, and run it everywhere, more or less.
The idea that somebody who chooses to do this is therefore not "competent" just boggles the mind. No point in deriding engineers who decide not to use the latest bells and whistles in the graphics pipeline. Maybe they just have other priorities.
(To clarify: the recommendation that everyone should just use OpenGL regardless of situation is, in fact, stupid. So I agree with that part. But it's equally stupid to say that everyone should use D3D12 / Metal regardless of circumstance.)
> That's some impressive graphics fetishism on display there.
More like compatibility and stability fetishism. nVidia and AMD can't even agree on how to compile the same GLSL shader - I'm much more confident about my ability to ship working D3D9 or D3D11 than OpenGL without a QA team with a wide range of hardware and driver revisions. D3D? Uniform bytecode. Uniform debug layers. Nice. Being indie just makes it easier - simpler rendering pipelines, easier to port.
For Android dev, where I have no choice about using e.g. OpenGL ES 2, the compatability mess is so bad that even for solo dev, I've been eyeing AWS Device Farm and Xamarin Test Cloud. Maybe AAA studios can afford the QA time - but I can't even afford enough phones to test to my satisfaction. And in my heart of hearts, I blame OpenGL, even if it's really the fault of mobile GPU vendors. I have a much weaker urge for a PC device farm, where D3D mostly just works. It'd be a much stronger urge if you threatened me with the prospect of supporting desktop OpenGL.
Biggest company I've worked for had about 50 people, usually on a much smaller team. I don't think that's AAA. Wasting milliseconds left and right, we didn't need much per-platform tuning - still lower hanging fruit around. Still almost agree with euos. Aside from compat - getting OpenGL working on a console or in the WinRT sandbox is probably more work and worse results than just doing a straight up port. Worst of all worlds.
> The idea that somebody who chooses to do this is therefore not "competent" just boggles the mind. No point in deriding engineers who decide not to use the latest bells and whistles in the graphics pipeline. Maybe they just have other priorities.
Agreed - competent engineers and managers may decide that competent 3d support not worth their time. I welcome this restraint when it comes to Excel's pie charts and the good fight against scope creep. If you're targeting the holy trifecta of Windows, Linux, OS X, and little else - OpenGL might be right for your MVP and your launch window.
Yet I'd still be eyeing that OpenGL on Windows as possible technical debt. Hell, I basically look at OpenGL ES on Android as unsolvable technical debt. I'd have a hard time labeling it "competent 3d". And I'd be wondering if it was really better than D3D9 + Wine.
Metal might be a little flavor-of-the minute. I need to give it a shot sometime...
Intel HD 3000 has better OpenGL support on Linux (thanks to Mesa). It's at 4.0 with software implementation of ARB_gpu_shader_fp64. And I doubt it supports all of DX11 properly as well.
I don't think you need to worry about that when gaming is concerned though. It's too old and below minimum requirements of huge amount of games already.
> That’s correct for AAA titles. Casual gamers however often play on PCs without a dedicated GPU.
Even in such case, they wouldn't commonly use Sandy Bridge generation GPU. And those who use it, aren't expecting recent games to support it (whether they are demanding or not). Increasing number of games already require OpenGL 4.x, even if they are not very demanding in practice. And now with Vulkan, older Intel GPUs simply won't cut it anymore.
Before it happened, software developers need to choose whichever GPU API works best for their particular project.
Personally, I have not developed games for several years.
For the last 1.5 years, I’ve been working on a CAD/CAM software. Traditionally people use OpenGL for this area. I have picked D3D 11 instead. The renderer is reasonably sophisticated; there are many complex shaders in there. The software is now used by thousands customers worldwide, and yet there were very few rendering-related bugs so far.
OpenGL 3.3 is a pretty nice target. It's easy to port an OpenGL 3.3 game to a lot of systems, including mobile, since OpenGL ES 2.1 is pretty similar, and Windows XP, which cannot run DirectX 10. (This matters less as time goes on, but it's been an important point in certain markets in Asia.) So you can write the graphics code once, more or less, and run it everywhere, more or less.
The idea that somebody who chooses to do this is therefore not "competent" just boggles the mind. No point in deriding engineers who decide not to use the latest bells and whistles in the graphics pipeline. Maybe they just have other priorities.
(To clarify: the recommendation that everyone should just use OpenGL regardless of situation is, in fact, stupid. So I agree with that part. But it's equally stupid to say that everyone should use D3D12 / Metal regardless of circumstance.)