What is the difference between OpenGL and Direct3D? Are they truly different implementations to accomplish the same things (like Java and Mirosoft's CLR [.NET])?
They are very different graphics API's. But it's fair to say they mostly accomplish the same thing. DirectX is probably the API of choice if you are developing a game under windows (or a game for XBOX), and OpenGL is the choice if you want cross-platform support. Mac OS uses GL, as does the iPhone, for example, and many windows games also support OpenGL.
Because OpenGL was developed over a long time and 'by committee', it comes with a lot of baggage - the API has some older options that aren't really relevant today. That's one of the reasons for OpenGL ES; it cuts out all the junk and makes for an easier target platform.
DirectX on the other hand is controlled by Microsoft, and as such it has a more 'modern' feel to it (it's based on COM components, so is highly object oriented). MS often update the API to match new hardware.
Sometimes you don't have the luxury of choice (iphone for example can't run DX). But often it just comes down to personal preference/experience. If your a long-time graphics programmer, you tend to get pretty familiar with both...
Google is your friend in this case...there's a good Wikipedia article contrastring the two libraries:
Comparison of OpenGL and Direct3D
If memory serves, OpenGL was the open implementation before Direct3D came out. Direct3D was then based off of OpenGL...but quickly diverged and became it's own distinct library.
UPDATE
Looks like my memory is shot...
Direct3D was developed independtly of OpenGL.
Direct3D and OpenGL are different API's used to accomplish the same thing.
The major differences between D3D and GL is that D3D is Object Oriented and GL is not.
D3D9 and GLES2 basically have the same features. In fact if you plan on using OpenGL and do not need any GL3 or GL4 features you should base all you code on the GLES2 API(all GLES2 features are in GL2, but not the other way around).
If possible you should always use D3D over GL on windows, as multithreading and driver support is flaky. Take the netbooks for example, they support D3D's HLSL at ShaderModel 2 but don't support the equivalent for GLSL, they only support a fixed pipeline for GL.
Related
I have been wanting to make a game in OpenGL, c++ for a while now and i would love some explanation on how exactly it works and what it is.
Can computer graphics be made without OpenGL ? most of the tutorials i have seen online show how to use OpenGL for the most basic graphics drawing, it is possible to directly interface with your GPU ?
How does OpenGL work on different CPU's and Operating systems ? As far as i know languages like c++ must be recompiled if they want to be used on an ARM processor and the such, is this not the case for GPU's in general ?
If you can indeed make graphics without OpenGL, does anybody still do this ? how much work and effort does OpenGL save in general and how complex are the systems that OpenGL facilitates for us?
Are there other libraries like OpenGL that are commonly used ? if not, will new libraries eventually come and take it's place or is it perfect for the job and not going anywhere ?
How exactly it works and what it is?
OpenGL defines an interface that you as a programmer can use to develop graphics programs (API). The interface is provided to you in form of header files that you include to your project. It is meant to be multiplatform, so that you can compile your code that uses OpenGL on different operating systems. People that manage the OpenGL specification do not provide the implementation of specified functionality. That is done by the OS and hardware vendors.
Can computer graphics be made without OpenGL?
Yeah, sure. You can e.g. calculate the whole image manually in your program and then call some OS-specific function to put that image on the screen (like BitBlt in Windows).
How does OpenGL work on different CPU's and Operating systems?
Each OS will have its own implementation of OpenGL specification that will usually call the hardware drivers. So let's say you have machine with Windows OS and Nvidia graphics card. If you run some program that calls glDrawElements it will look like this:
your_program calls glDrawElements
which calls glDrawElements implementation written by people from Microsoft
which calls Nvidia drivers written by people from Nvidia
which operates the HW
If you can indeed make graphics without OpenGL, does anybody still do this?
Yeah sure. Some people might want to implement their own rendering engine from ground up (although that is really hardcore thing to do).
Are there other libraries like OpenGL that are commonly used ? if not, will new libraries eventually come and take it's place or is it perfect for the job and not going anywhere ?
Sure. There is DirectX that is maintained by Microsoft and targets only Windows platforms and the Vulkan that can be seen as successor to OpenGL.
I have seen many graphics applications which primarily support OpenGL. I have also noticed that many of these applications have a -d3d flag which will force them to use the DirectX API instead.
How exactly can a single graphics application use two different APIs but render the exact same result? Surely they would need to add code for both APIs, which is time consuming and a bit of a waste?
The topic of OpenGL vs. DirectX is touchy with many folks, so let me start by saying my intent is to not inflame either side of the "API wars".
If you are talking about general graphics software like CAD, they tend to have a large set of cross-platform targets to support. In these cases, they use OpenGL for systems like MAC and *NIX as well as Windows.
While the developers can use OpenGL on Windows, the 'default' support for OpenGL on Windows is pretty minimal--OpenGL v1.x software only. If you want to use a more full-featured version of OpenGL, you need to have the user install an OpenGL ICD. The quality of these OpenGL ICDs is heavily dependent on each hardware vendor keeping up with the standard, and in the past the OpenGL ICDs for Windows have been tuned for very specific calling patterns for specific applications (read "Doom"). If your application didn't match those patterns, you would sometimes have strange performance problems or hit other bugs.
There has also been a tendency in the video hardware industry for the OpenGL support on Windows on 'consumer-grade' hardware being fairly minimal effort for a few games, while the 'workstation-grade' hardware gets lots of developer resources focused on writing a high-quality OpenGL ICD. In this case, software aimed at workstation (again, read CAD) tends to offer both APIs to cater to the needs of users on both cheaper and more expensive systems. Conversely for games, it's unrealistic to require a $2000+ video card to play to it's often much easier and more robust to use DirectX--unless you happen to the one "must-have" OpenGL only game on the market that the 'consumer-grade' drivers actually work well with.
Using DirectX, particularly DirectX 11 on Windows 7+, works well 'out of the box' for most systems across a wide array of devices from different vendors. Some software developers have found it be far more consistent across different devices and use it as the default when they offer both OpenGL and DirectX. This is why many PC games are DirectX only on Windows. However, if they are already doing an abstraction to support OpenGL for MAC, they may well leave it as an option for users on Windows as well.
For games, abstraction is typical in the rendering engines. To get good performance for a AAA title and hit all the different platforms that matter to them, they typically have to implement multiple versions of their renderer anyhow (Direct3D 11 for Windows Vista+, Direct3D 9 for Windows XP esp. for emerging markets, a variant of Direct3D 9 for Xbox 360, a variant of Direct3D 11 for Xbox One, OpenGL for MAC, specific renderers for PlayStation 3 and/or 4, and for mobile games OpenGL ES). This is usually achieved through an abstraction layer, and then dedicated coders for each platform to marshal the game through to ship taking advantage of what hardware-specific features matter to them. It is not an inexpensive solution, but many large publishers try to arbitrage project risk by offering versions of their content across many different platforms and consider it worth the additional cost.
For indie and small developers, trying to support both OpenGL and DirectX can be a pretty big challenge. It's usually better for them to focus on making a great game for a single platform using a single, well-supported API on that platform. Then if they are successful, they can port it to more platforms by doing the work needed to implement multiple rendering APIs -and- create custom content processing to tailor it to each platform. That said, indie games often don't focus on differentiating on graphics, so the feature & performance trade-offs for using an abstraction layer is less of a problem. It is, however, expensive to test your game across many different devices and do it twice to cover both OpenGL and DirectX.
As I understand GPU vendors defined standard interface to be used by OS Developers to communicate with their specific driver. So DirectX and OpenGL are just wrappers for that interface. When OS developers decide to create new version of Graphic API , GPU vendors expand their interface (new routines are faster and older ones are left for compatibility issues) and OS developers use this new part of interface.
So, when it is said that GPU vendors' support for DirectX is better than for OpenGL, does it simply mean that GPU vendors primarily take into account Microsoft's future plans of developing DirectX API structure and adjust future development of this interface to their needs? Or there is some technical reasons before this?
As I understand GPU vendors defined standard interface to be used by OS Developers to communicate with their specific driver. So DirectX and OpenGL are just wrappers for that interface.
No, not really. DirectX and OpenGL are just specifications that define APIs. But a specification is nothing more than a document, not software. The OpenGL API specification is controlled by Khronos, the DirectX API specification is controlled by Microsoft. Each OS then defines a so called ABI (Application Binary Interface) that specifies which system level APIs are supported by the OS (OpenGL and DirectX are system level APIs) and what rules an actual implementation must adhere to, when being run on the OS in question.
The actual OpenGL or Direct3D implementation happens in the hardware's drivers (and in fact the hardware itself is part of the implementation as well).
When OS developers decide to create new version of Graphic API , GPU vendors expand their interface
In fact it's the other way round: Most of the graphic APIs specifications are laid out by the graphics hardware vendors. After all they are close to where the rubber hits the road. In the case of Khronos the GPU makers are part of the controlling group of Khronos. In the case of DirectX the hardware makers submit drafts to and review the changes and suggestions made by Microsoft. But in the end each new APIs release reflects the common denominator of the capabilities of the next hardware generation in development.
So, when it is said that GPU vendors' support for DirectX is better than for OpenGL, does it simply mean that GPU vendors primarily take into account Microsoft's future plans of developing DirectX API structure and adjust future development of this interface to their needs?
No, it means that each GPU vendor implements his own version of OpenGL and the Direct3D backend, which is where all the magic happens. However OpenGL puts a lot of emphasis on backward compatibility and ease of transition to newer functionality. Direct3D development OTOH is quick in cutting the ties with earlier versions. This also means that full blown compatibility profile OpenGL implementations are quite complex beasts. That's also the reason why recent versions of OpenGL core profiles did (overdue) work in cutting down support for legacy features; this reduction of API complexity is also quite a liberating thing for developers. If you develop purely for a core profile it simplifies a lot of things; for example you no longer have to worry about a plethora of internal state when writing plugin.
Another factor is, that for Direct3D there's exactly one shader compiler, which is not part of the driver infrastructure / implementation itself, but gets run at program build time. OpenGL implementations however must implement their own GLSL shader compiler, which complicates things. IMHO the lack of a unified AST or immediate shader code is one of the major shortcomings of OpenGL.
There is not a 1:1 correspondence between the graphics hardware abstraction and graphics API like OpenGL and Direct3D. WDDM, which is Windows Vista's driver model defines things like common scheduling, memory management, etc. so that DirectX and OpenGL applications work interoperably, but very little of the design of DirectX, OpenGL or GPUs in general has to do with this. Think of it like the kernel, nobody creates a CPU specifically to run it, and you do not have to re-compile the kernel everytime a new iteration of a processor architecture comes out that adds a new subset of instructions.
Application developers and IHVs (GPU vendors, as you call them) are the ones who primarily deal with changes to GPU architecture. It may appear that the operating system has more to do with the equation than it actually does because Microsoft (more so) and Apple--who both maintain their own proprietary operating systems--are influential in the design of DirectX and OpenGL. These days OpenGL closely follows the development of commodity desktop GPU hardware, but this was not always the case - it contains baggage from the days of custom SGI workstations and lots of things in compatibility profiles have not been hardware native on desktop GPUs in decades. DirectX, on the other hand, has always followed desktop hardware. It used to be if you wanted an indication of where desktop GPUs were headed, D3D was a good marker.
OpenGL is arguably more complicated than DirectX because until recently it never let go of anything, whereas DirectX radically redefined the API and stripped legacy support with every iteration. Both APIs have settled down in recent years, but D3D still maintains a bit of an edge considering it only has to be implemented on a single platform and Microsoft writes the one and only shader compiler. If anything, the shader compiler and minimal feature set (void of legacy baggage) in D3D is probably why you get the impression that vendors support it better.
With the emergence of AMD Mantle, the desktop picture might change again (think back to the days of 3Dfx and Glide)... it certainly goes to show that OS developers have very little to do with graphics API design. NV and AMD both have proprietary APIs on the PS3, GameCube/Wii/WiiU, and PS4 that they have to implement in addition to D3D and OpenGL on the desktop, so the overall picture is much broader than you think.
Some virtual machines do not have displayed card at all. I am wondering OpenGL and DirectX can be simulated by software totally or not?
OpenGL and DirectX are just APIs. The actual implementation may be done in hardware or software. The OpenGL interface DLL shipped by Windows contains a OpenGL-1.1 software rasterizer. The OpenGL implementation used on Linux, Mesa3D, also contains a software rasterizer fallback, implementing OpenGL-2.1.
Direct3D can be implemented in software emulated as, but normally isn't.
The simple answer is yes, and companies like Adobe do just that.
Take a look at SwiftShader:: http://transgaming.com/business/swiftshader
I have to used it before and it runs quite well.
Do the really big games also use Open GL? Or are there some proprietary technologies out there, which can scare Open GL's pants off?
OpenGL and Direct3D both allow comparable access to the GPU.
The "really really really really really really really big games" use one of these, in addition to other non-graphical libraries, plenty of skilled programmers, artists, musicians, game designers, level designers and other staff to create those games "that cost billions to develop".
Feature-wise you can accomplish the same output with either API (OpenGL or DirectX). Several game engines abstract the underlying API from the developer resulting in games which can use either API and are potentially cross platform.
Some examples of this are most of id software (doom,quake,etc) games and any games which use their engine. World of Warcraft also supports either Direct3D or Opengl. Also, several steam/valve games which run on Windows, Mac, and rumored Linux.
OpenGL and Direct3D are the heavy-hitters in the gaming world. Neither scares the pants off the other.
Note, however, that big game houses will use commercial game engines that hide these APIs for the most part.
Most PC games (and xbox360) use Direct3D, but some do use OpenGL.
You can find out more about Direct3D and download it all from Microsoft here...
http://msdn.microsoft.com/en-us/aa937791.aspx
Really big games use a graphics abstraction layer (as mentionned by basszero) since they have to target different platforms that have different APIs:
Xbox 360 : D3D9+
PS3 : libgcm
Vista/Win7: D3D9, D3D10, D3D11
XP : D3D9
OSX : OpenGL
The simple answer is that no, there's no direct alternative to OpenGL that's obviously superior. Direct3D is pretty nearly the only competitor of any kind, and while it's certainly competitive, it doesn't enjoy any major advantage.
At times, Direct3D has had something of an advantage in speed -- it's controlled by Microsoft, who could quickly modify the specification to take advantage of the latest graphics cards updates. At that time, OpenGL was controlled by a multi-vendor Architecture Review Board (ARB). Decisions about new versions of OpenGL took considerable time, and a fair number of vendors seemed more concerned about backward compatibility than taking full advantage of every new trick as quickly as hardware vendors invented them (and nVidia and ATI are sufficiently competitive that they do invent them, and quickly at that).
Since then, control of OpenGL has been turned over to Khronos Group. There's been some controversy about parts of what they've done with the specification (particularly deprecating a lot of features that quite a few people still use) but one thing is open to little question: they're now cranking out new revisions to the specification relatively quickly, so it provides access to the features of even the newest hardware.
Direct3D if you work for Microsoft.