Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualHodgman

Posted 20 September 2012 - 09:22 AM

It is also arguably more flexible, but only in that it is significantly more portable. Writing linux or mac games in D3D instantly makes WINE necessary at a cost to FPS (as WINE must redirect D3D calls to OpenGL), and I'm not sure if the Wii and PS3 support D3D at all.

Wii uses a proprietary API (similarly designed to GL) called GX, and the PS3 has a proprietary API called GCM, which is much more low level than GL or D3D. The PS3 also has a wrapper called PSGL, but this is different to "Desktop GL" and is a translation layer (like Wine's D3D->GL layer). The 360 has a proprietary API that's quite similar to D3D9.

IMHO, the portability of OpenGL is a bit of a red herring.
On Windows/Linux, the OpenGL runtime is almost entierly implemented by your graphics driver, and there is no governing authority to ensure standards compliance -- it's industry self policing only. This means that vendors can and do violate the standard in ways to hurt each other -- e.g. nVidia drivers accept HLSL syntax in GLSL shaders, with the hopes that developers may ship such shaders, which will appear broken on ATI/Intel GPUs...
On the other hand, Apple keeps a much tighter grip on things (like Microsoft does with D3D), so OpenGL on Apple OS's is going to be a lot more reliable.
So the 3 platforms that GL gives you portability to -- Linux/Windows and Apple -- all actually may behave slightly differently. You still need to test your renderer separately on each platform, and on Windows/Linux, you also need to test your renderer on GPUs from each manufacturer, as each of these tests is against a completely different implementation of the OpenGL runtimes.

Also, if you want to support the latest SM5 GPU features, but also support scaled-down versions of your renderer for SM4 and SM3 GPUs, then you've still got to "port" a lot of your rendering code no matter the API.
On Windows with D3D, you'd have to maintain a D3D11, D3D11_feature_level_10 and a D3D9 version of your renderer.
With GL, you'd have to maintain a GL2, GL3 and GL4 version of your renderer.

So a "cross platform" renderer has to maintain and test code for:
Consoles: GX + GCM + "D3D360" + any other consoles
Mac: GL2 + GL3 + GL4 [edit]SM5 level GPUs not supported by apple[/edit]
Linux: GL2 + GL3 + GL4 multiplied with ATI + nVidia + Intel
Windows plan A: GL2 + GL3 + GL4 multiplied with ATI + nVidia + Intel
Windows plan B: D3D9, D3D11_10, D3D11
Mobile Phone: GLES1 + GLES2 multiplied with each Android + iOS device

Yes, sharing common GL code paths might be able to save you some time, but no matter which APIs you use, it's going to be a hell of a lot of work.

#1Hodgman

Posted 20 September 2012 - 07:44 AM

It is also arguably more flexible, but only in that it is significantly more portable. Writing linux or mac games in D3D instantly makes WINE necessary at a cost to FPS (as WINE must redirect D3D calls to OpenGL), and I'm not sure if the Wii and PS3 support D3D at all.

Wii uses a proprietary API (similarly designed to GL) called GX, and the PS3 has a proprietary API called GCM, which is much more low level than GL or D3D. The PS3 also has a wrapper called PSGL, but this is different to "Desktop GL" and is a translation layer (like Wine's D3D->GL layer). The 360 has a proprietary API that's quite similar to D3D9.

IMHO, the portability of OpenGL is a bit of a red herring.
On Windows/Linux, the OpenGL runtime is almost entierly implemented by your graphics driver, and there is no governing authority to ensure standards compliance -- it's industry self policing only. This means that vendors can and do violate the standard in ways to hurt each other -- e.g. nVidia drivers accept HLSL syntax in GLSL shaders, with the hopes that developers may ship such shaders, which will appear broken on ATI/Intel GPUs...
On the other hand, Apple keeps a much tighter grip on things (like Microsoft does with D3D), so OpenGL on Apple OS's is going to be a lot more reliable.
So the 3 platforms that GL gives you portability to -- Linux/Windows and Apple -- all actually may behave slightly differently. You still need to test your renderer separately on each platform, and on Windows/Linux, you also need to test your renderer on GPUs from each manufacturer, as each of these tests is against a completely different implementation of the OpenGL runtimes.

Also, if you want to support the latest SM5 GPU features, but also support scaled-down versions of your renderer for SM4 and SM3 GPUs, then you've still got to "port" a lot of your rendering code no matter the API.
On Windows with D3D, you'd have to maintain a D3D11, D3D11_feature_level_10 and a D3D9 version of your renderer.
With GL, you'd have to maintain a GL2, GL3 and GL4 version of your renderer.

So a "cross platform" renderer has to maintain and test code for:
Consoles: GX + GCM + "D3D360" + any other consoles
Mac: GL2 + GL3 + GL4
Linux: GL2 + GL3 + GL4 multiplied with ATI + nVidia + Intel
Windows plan A: GL2 + GL3 + GL4 multiplied with ATI + nVidia + Intel
Windows plan B: D3D9, D3D11_10, D3D11
Mobile Phone: GLES1 + GLES2 multiplied with each Android + iOS device

Yes, sharing common GL code paths might be able to save you some time, but no matter which APIs you use, it's going to be a hell of a lot of work.

PARTNERS