5 ms·

All the whining and complaining makes me wondering how anyone was able to write something with OpenGL at all. This is fascinating because a great amount of peo

• ekr 12y ago
  >The API is still pretty rough and could see some improvements. I know this myself, I also played around with OpenGL at some point. There is a lot of boilerplate code that needs to be written before you can start yourself with the real game. OpenGL is a graphics library (and a rather low-level one too), so it has very little to do with games. It's only a specification for the wrapper above the gpu hardware.
• pjmlp 12y ago
  Except other APIs offer what in OpenGL requires an engine/framework. - Font loading - Texture loading - Shader loading - Math library - Geometry loading - Meshes - Integration with the OS UI - Debugging capabilities
  • flohofwoe 12y ago
    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/ 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: - glm for math (http://glm.g-truc.net/0.9.5/index.html http://glm.g-truc.net/0.9.5/index.html) - gli for texture loading (http://gli.g-truc.net/0.5.1/index.html http://gli.g-truc.net/0.5.1/index.html) - assimp for general asset loading: http://assimp.sourceforge.net/index.html http://assimp.sourceforge.net/index.html - the STB headers (not OpenGL specific): https://github.com/nothings/stb 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).
    • pjmlp 12y ago
      > 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.
      • 12y ago
• overgard 12y ago
  Well by that logic, IE is a great browser because a lot of people got some amazing applications to run on it despite the fact that it was a nightmare to develop for... OpenGL is almost like the IE of graphics development. You usually have to support it because it's so ubiquitous, but it constantly makes you want to tear out your hair because it does so many unexpected things and you have to memorize 5000 little caveats.
  • twelvechairs 12y ago
    What OpenGL does is hard - to make things worth fast across multiple platforms with backward compatibility. Not like IE which was/is stagnant because of big company sluggishness/exceptionalism, but because its open source trying to do a huge amount with limited resources. There are always higher level platforms if you want something easier to work with, but you sacrifice a little speed.
    • overgard 12y ago
      > What OpenGL does is hard If you think what browsers do is easy... :-) Here's the thing though: most of what OpenGL screws up is the not-hard stuff. Here are the main things wrong with OpenGL right now: * Everything operates on and modifies implicit global state, especially with the various "bind" patterns (direct state access will help a lot with this). Even a first year CS student knows global state is bad. It was sort of acceptable-if-ugly back when the fixed function pipeline was the thing, but for almost the last 10 years that's been deprecated, and with how you program a GPU now that global state and bind patterns is ridiculous. * Error handling is unfriendly and confusing and slow. It's very easy to accidentally send in a bad parameter to a function, have OpenGL silently ignore it, only for something to blow up in your program in a completely different module because that error went silently unchecked. This is just bad. Not only that, but glGetError rarely gives you any useful information. Why can't it at least tell me what function failed, and which parameter/value it was that made it fail? A lot of times you'll see an error in a complex function like glTexImage2d that has a ton of possible parameter combinations for "invalid value". Well, which one is invalid? What inputs would be valid? The driver knows, so why can't it tell me? > Not like IE which was/is stagnant because of big company sluggishness/exceptionalism, but because its open source trying to do a huge amount with limited resources. Have you looked at the companies that comprise the khronos group? They're not exactly poor. The problem isn't resources, it's bad design by committee.
• EpicEng 12y ago
  Like javascript is an awesome programming language because it is so widely used? Oh, wait...