What other APIs would that be which offer this functionality? In D3D this used to be offloaded into a separate D3DX API, but AFAIK this is no longer supported in Windows8 (at least in the WinRT API) and has been moved into separate mostly personal projects (e.g. http://directxtex.codeplex.com/). A 3D rendering API should only be concerned about efficient 3D rendering and not burden itself with specific resource file formats. For OpenGL there's plenty of libraries to choose from, for instance:
- ...and more which I am not aware of or forgot to list
GPU vendors also have SDKs and especially debugging tools (e.g. NVIDIA nSight which integrates into VStudio). It's not in one place like in DirectX, but on the other hand, the OpenGL world has a lot more platforms and usage scenarios to cover then D3D or the various new-style APIs like Metal or Mantle (these are the actual motivation for OpenGL-Next, reducing overhead even when this means a lower-level API which is even more focuses and harder to use then before).
> What other APIs would that be which offer this functionality?
Game console APIs.
> In D3D this used to be offloaded into a separate D3DX API, but AFAIK this is no longer supported in Windows8
DirectX is now integrated into the Windows SDK and makes use of new APIs:
Math is provided via DirectXMath.
Shaders can still be combined via Effects.
Interactions with the windowing system are done via DXGI.
Image loading is done via Windows Imaging Component.
> For OpenGL there's plenty of libraries to choose from, for instance:
Yes, I had to go library hunting already a few times. It gets tiring trying to see what are the current ones for people like myself that only occasionally do graphics stuff.
For example, a few years ago DevIL was the library to go for image loading.
Game console APIs have it easy though since they only support a single GPU and a single texture compression scheme. In the OpenGL world it is more tricky, especially on mobile since each GPU vendor used to only implement their own patent-infested compressed texture formats (this useless GPU-vendor-infighting held back OpenGL back more then anything else). And most of the Windows APIs you listed are not part of D3D, but either part of (what used to be) DirectX, or some completely unrelated part of the Windows API, and with this you've locked yourself into the Windows world. From your requirements it sounds like you're best served with SDL2 or a similar medium level wrapper API, at least if you want to support platforms outside of Windows.
I'd agree with this. He doesn't want a low-level graphics API, which is what OpenGL is. He wants everythng else around it. For what it's worth, I totally want that too. I'm just not blaming OpenGL for being a leg when I really want a tail.
SDL2 is cool, and so is @icculus. It isn't everything he wants, by a long shot, but it's good at what it is. I used SDL2 for a while when writing my game engine in C++ and didn't port to Mono for any reason related to it (just a burning desire to have a scripting layer that wouldn't make me put my head in an oven.).
- glm for math (http://glm.g-truc.net/0.9.5/index.html)
- gli for texture loading (http://gli.g-truc.net/0.5.1/index.html)
- assimp for general asset loading: http://assimp.sourceforge.net/index.html
- the STB headers (not OpenGL specific): https://github.com/nothings/stb
- GLFW as window system glue and input wrapper
- ...and more which I am not aware of or forgot to list
GPU vendors also have SDKs and especially debugging tools (e.g. NVIDIA nSight which integrates into VStudio). It's not in one place like in DirectX, but on the other hand, the OpenGL world has a lot more platforms and usage scenarios to cover then D3D or the various new-style APIs like Metal or Mantle (these are the actual motivation for OpenGL-Next, reducing overhead even when this means a lower-level API which is even more focuses and harder to use then before).