5 ms·

>> but in 2014 if you're still writing games in DirectX, you're most likely doing it wrong. No, you are not. There is no wrong and right, it's just a stupid st

by maaaats 13y ago

>> but in 2014 if you're still writing games in DirectX, you're most likely doing it wrong. No, you are not. There is no wrong and right, it's just a stupid statement. OpenGL is years behind D3D (not DirectX, it's not comparable!) in many areas, and writing using the whole DX stack can be much nicer than setting up a GL stack with a lot of different libraries.

gambiting 13y ago
>>OpenGL is years behind D3D (not DirectX, it's not comparable!) in many areas, Explain please?
- dimillian 13y ago
  I think it's not years behind, for example the latest AAA game I've played on OSX (Elder Scrolls Online) run natively on it, and it's in OpenGL. It look as good as on PC where it run with D3D.
  - kevingadd 13y ago
    The gap between GL and D3D has nothing to do with visual quality and everything to do with framerate and load times.
- maaaats 13y ago
  Note that I said in many areas. Not all. A history lesson of why many actually prefer the Windows stack can be read here: http://programmers.stackexchange.com/a/88055/51669 http://programmers.stackexchange.com/a/88055/51669
  - outworlder 13y ago
    And you did not say which areas and why it is behind in them. I see multicore support in another comment, and maybe things related to geometry shaders. What else am I missing?
    - zanny 13y ago
      Geometry shaders are in OpenGL 3.2. Almost any complaints about "OpenGL is missing X feature" ignore the existence of the entire 4.0 generation as well. Which is kind of understandable - I use Mesa as my "assumed" OGL level, and it just hit 3.3. So you absolutely can't assume anything from the 4 line. Though I still couldn't use geometry shaders as an assumption, because as recently as Sandy Bridge Intel GPUs didn't support it. Add on if you want to port to mobile you need to refactor to GLES2.
- sharpneli 13y ago
  Complete lack of multicore rendering. You can practically issue render commands only from one thread. And there is no way to save bunch of commands anymore as display lists were deprecated. Also it's still very much state machine based. So you have to do a lot of individual calls to set everything up for actual draw call. I personally love OpenGL and use it on my work. However this is one of the biggest drawbacks on OpenGL currently.
  - kosinus 13y ago
    No clue what multicore rendering D3D offers, but 'complete lack' is an overstatement. OpenGL has context sharing, which means several contexts in different threads sharing the same objects. You can issue commands as long as you synchronise access to objects yourself. In practice, that means filling buffers, rendering to an off-screen framebuffer, etc. from other threads.
    - sharpneli 13y ago
      As mentioned in the other comments it's not consistent nor always supported. And you can do the multithreading only by sharing already rendered fbo's. In D3D it works as OpenGL display lists would, except with arbitrary commands. So you have multiple threads composing the scene and then a single thread just issues few commands to replay the command buffers created by the other threads. It would be rather simple to implement the same in OpenGL as we already have the display list concept, even if it originally was made to reduce the amount of glvertex3f calls. "complete lack" was maybe bit of an exaggeration, however in practice it is true.
    - kevingadd 13y ago
      Multithreading in GL does not work consistently. If you ask the driver vendors (AMD, NVIDIA, etc) they will tell you it doesn't work at all or across platforms. If you ask engine developers (like Valve) they will tell you in talks that it doesn't work across platforms.
      - kosinus 13y ago
- jstelly 13y ago
  One of the biggest problems with OpenGL currently is the lack of a good binary intermediate representation of shaders. Direct3D has a byte code representation that is vendor neutral. OpenGL has APIs that let you cache off binary shader representations (glProgramBinary), but they are configuration specific. Configuration differences may include hardware vendor, hardware version, driver version, client OS version, etc. So in practice these formats are only useful when the shader files are compiled on the client machines. They don't actually allow developers to ship only compiled shaders unless they are comfortable with their shaders not running on future hardware, for example. This leads to developers pursuing various less optimal solutions that all involve more startup time for users and less predictable performance and robustness for developers (at least when compared to the solution D3D has offered for more than 10 years). So when people say OpenGL is years behind D3D this is one of the things they mean. D3D isn't perfect here either. There is a fair amount of configuration-specific recompilation going on, but the formats are more compact than the optimized/minimized GLSL source formats people are pursuing on OpenGL and while the startup time (shader create time) is still too long, it is still much better than OpenGL. Shader robustness is generally more predictable and better on D3D but it's hard to disentangle shader pipeline issues from driver quality. To be fair multicore is also an issue for OpenGL, but D3D isn't great at that either. The current spec for D3D11 includes a multicore rendering feature called "deferred contexts" but performance scaling using that feature has been disappointing so it isn't a clear win for D3D. Other APIs (e.g. hardware-specific console graphics APIs) expose more of the GPU command buffer and reducing abstraction there allows for a real solution to the multicore rendering problem. There should be a vendor neutral solution here, but so far neither of the APIs has delivered one that is close to the hardware-specific solutions in performance scaling.
ZenoArrow 13y ago
Behind in what sense? I'm not a video games programmer, but judging by the benchmarks it seems the most efficient graphics stack is based around AMD's Mantle: http://hothardware.com/News/AMD-Mantle-vs-DirectX-Benchmarks-with-Battlefield-4-and-Star-Swarm/ http://hothardware.com/News/AMD-Mantle-vs-DirectX-Benchmarks... John Carmack suggests the OpenGL extensions that NVidia have developed give comparable performance to Mantle: http://n4g.com/news/1376571/john-carmack-nvidias-opengl-extensions-rival-mantle-8gbs-on-consoles-not-a-significant-change http://n4g.com/news/1376571/john-carmack-nvidias-opengl-exte...

by maaaats 13y ago

gambiting 13y ago

>>OpenGL is years behind D3D (not DirectX, it's not comparable!) in many areas, Explain please?

dimillian 13y ago
I think it's not years behind, for example the latest AAA game I've played on OSX (Elder Scrolls Online) run natively on it, and it's in OpenGL. It look as good as on PC where it run with D3D.
- kevingadd 13y ago
  The gap between GL and D3D has nothing to do with visual quality and everything to do with framerate and load times.
maaaats 13y ago
Note that I said in many areas. Not all. A history lesson of why many actually prefer the Windows stack can be read here: http://programmers.stackexchange.com/a/88055/51669 http://programmers.stackexchange.com/a/88055/51669
- outworlder 13y ago
  And you did not say which areas and why it is behind in them. I see multicore support in another comment, and maybe things related to geometry shaders. What else am I missing?
  - zanny 13y ago
    Geometry shaders are in OpenGL 3.2. Almost any complaints about "OpenGL is missing X feature" ignore the existence of the entire 4.0 generation as well. Which is kind of understandable - I use Mesa as my "assumed" OGL level, and it just hit 3.3. So you absolutely can't assume anything from the 4 line. Though I still couldn't use geometry shaders as an assumption, because as recently as Sandy Bridge Intel GPUs didn't support it. Add on if you want to port to mobile you need to refactor to GLES2.
sharpneli 13y ago
Complete lack of multicore rendering. You can practically issue render commands only from one thread. And there is no way to save bunch of commands anymore as display lists were deprecated. Also it's still very much state machine based. So you have to do a lot of individual calls to set everything up for actual draw call. I personally love OpenGL and use it on my work. However this is one of the biggest drawbacks on OpenGL currently.
- kosinus 13y ago
  No clue what multicore rendering D3D offers, but 'complete lack' is an overstatement. OpenGL has context sharing, which means several contexts in different threads sharing the same objects. You can issue commands as long as you synchronise access to objects yourself. In practice, that means filling buffers, rendering to an off-screen framebuffer, etc. from other threads.
  - sharpneli 13y ago
    As mentioned in the other comments it's not consistent nor always supported. And you can do the multithreading only by sharing already rendered fbo's. In D3D it works as OpenGL display lists would, except with arbitrary commands. So you have multiple threads composing the scene and then a single thread just issues few commands to replay the command buffers created by the other threads. It would be rather simple to implement the same in OpenGL as we already have the display list concept, even if it originally was made to reduce the amount of glvertex3f calls. "complete lack" was maybe bit of an exaggeration, however in practice it is true.
  - kevingadd 13y ago
    Multithreading in GL does not work consistently. If you ask the driver vendors (AMD, NVIDIA, etc) they will tell you it doesn't work at all or across platforms. If you ask engine developers (like Valve) they will tell you in talks that it doesn't work across platforms.
    - kosinus 13y ago
jstelly 13y ago
One of the biggest problems with OpenGL currently is the lack of a good binary intermediate representation of shaders. Direct3D has a byte code representation that is vendor neutral. OpenGL has APIs that let you cache off binary shader representations (glProgramBinary), but they are configuration specific. Configuration differences may include hardware vendor, hardware version, driver version, client OS version, etc. So in practice these formats are only useful when the shader files are compiled on the client machines. They don't actually allow developers to ship only compiled shaders unless they are comfortable with their shaders not running on future hardware, for example. This leads to developers pursuing various less optimal solutions that all involve more startup time for users and less predictable performance and robustness for developers (at least when compared to the solution D3D has offered for more than 10 years). So when people say OpenGL is years behind D3D this is one of the things they mean. D3D isn't perfect here either. There is a fair amount of configuration-specific recompilation going on, but the formats are more compact than the optimized/minimized GLSL source formats people are pursuing on OpenGL and while the startup time (shader create time) is still too long, it is still much better than OpenGL. Shader robustness is generally more predictable and better on D3D but it's hard to disentangle shader pipeline issues from driver quality. To be fair multicore is also an issue for OpenGL, but D3D isn't great at that either. The current spec for D3D11 includes a multicore rendering feature called "deferred contexts" but performance scaling using that feature has been disappointing so it isn't a clear win for D3D. Other APIs (e.g. hardware-specific console graphics APIs) expose more of the GPU command buffer and reducing abstraction there allows for a real solution to the multicore rendering problem. There should be a vendor neutral solution here, but so far neither of the APIs has delivered one that is close to the hardware-specific solutions in performance scaling.

ZenoArrow 13y ago

Behind in what sense? I'm not a video games programmer, but judging by the benchmarks it seems the most efficient graphics stack is based around AMD's Mantle: http://hothardware.com/News/AMD-Mantle-vs-DirectX-Benchmarks-with-Battlefield-4-and-Star-Swarm/ http://hothardware.com/News/AMD-Mantle-vs-DirectX-Benchmarks... John Carmack suggests the OpenGL extensions that NVidia have developed give comparable performance to Mantle: http://n4g.com/news/1376571/john-carmack-nvidias-opengl-extensions-rival-mantle-8gbs-on-consoles-not-a-significant-change http://n4g.com/news/1376571/john-carmack-nvidias-opengl-exte...