Elysian Shadows

The topic is a Rhetorical Question.

I'm going to express my opinion on DirectX and OpenGL and I'll tell you which one ( in my opinion ) is the better
game API.

Let's start off with DirectX. Microsoft DirectX is a collection of application programming interfaces (APIs) for handling tasks related to multimedia, especially game programming and video, on Microsoft platforms ( taken from Wikipedia). In my honest Opinion I think that DirectX is the best API for the windows OS (Operating System) Compared to OpenGL DirectX Blows OpenGL out of the water (figuratively speaking). The reason being that the Engine is more powerful in the graphics area. DirectX is also more widely used in the gaming Industry.In my opinion the DirectX syntax is really difficult to get used to and It took me WAY longer to get used to the DirectX syntax than the OpenGL syntax.


Alright, now that I'm done praising Direct X let's go on to OpenGL. OpenGL also has a lot of things about it that I like. OpenGL is multi-platform, meaning that you can use OpenGL on both the Microsoft,Apple,And Linux operating systems. To me, OpenGL is more useful for applications rather than games. Not many professional industry games are using OpenGL out there (correct me if I'm wrong). I've programmed with both OpenGL and DirectX and OpenGL ( in my opinion) is easier to code in. Although I do prefer DirectX I find OpenGL really easy to work with and very comfortable to work with, the syntax is also easier to remember.

So in all and all, I'd have to pick DirectX is the superior game API. It's difficult to get on the ride ( to learn it ) but once you learn, in the end you'll find out that it's worth it.

Feel free to disagree with, this is a open Discussion and i'd love to hear what everyone else has to say.

Epic Games and id Software are two companies(off the top of my head) that use OpenGL in their engines.

BTW. Neither OpenGL or DirectX are engines they are APIs(well DirectX is technically an SDK but still). Also you can't compare DirectX to OpenGL when DirectX as you said also does sound, input, etc. This makes it uneven, now if you were comparing Direct3D(Graphics section of DirectX) to OpenGL it would be alot fairer since both deal exclusively to graphics and rendering.

DirectX(well Direct3D) doesn't have greater rendering capabilities than OpenGL, if you can do it in one(more than likely) you an do it in the other. And besides DirectX has been playing catch up with OpenGL for years.

Anyway have a look here

A fair comparison is Direct3D to OpenGL. They're both APIs whereas DirectX is a multimedia library like SDL.

Thanks for correcting me guys.
I guess my knowledge on the API's was a bit "clouded"

Frosty wrote:Thanks for correcting me guys.
I guess my knowledge on the API's was a bit "clouded"

And now you know. BTW, Welcome to the forums I love your avatar.

As much as I love you guys, I'll have to respectively disagree

Coming from the DirectX route (and now fully supporting OpenGL, since I'm on Mac), I must say that DirectX 10 (Direct3D10) is a much more capable graphics API. First of all, let me say that the link you provided is friggen oldz, M_D_K (check out the wiki-clean up notice on the header of the page), so it does not really reflect the current state of affairs.

Now, I could just state subjective remarks, about my personal experience, but should I? I don't need to, as there is ample frustration from the professional side already.

Here is an interesting reaction by professional OpenGL game developers developers, as the new specification was released; dismal, to say the least. Also, here is an excerpt:

Wikipedia wrote:The final specification proved far less revolutionary than the Longs Peak proposal. Instead of removing all immediate mode and fixed functionality (non-shader mode), the spec included them as deprecated features. The proposed object model was not included, and no plans have been announced to include it in any future revisions. As a result the API remained largely the same with a few existing extensions being promoted to core functionality.

Anyway, I would say lastly that if you're going to pit the two API against one another, then there is no "unfair" match. If OpenGL has no input equivalent, then that is on the Khronos group. So pitting OpenGL/AL (3.0) vs DirectX (11), DirectX takes the cake, in my opinion.

If anything, in the past 4 years or so, especially since DX9, OpenGL has been playing a *MAJOR* catch up game. The big issue with OpenGL is that all of it's functionality is still expressed through a subsystem that is over 10 years old. As such, none of the underlying subsystem has changed in 10 years. All new functionality is implemented on the graphics driver, as are all new extensions to the OpenGL spec. The real double edged sword about that is that some vendors expose exploits in their hardware via some extensions where another may not. This can tack on excessive amounts of development time for vendor specific code designed to utilize these extensions. Not to mention, just keeping track of which extensions are invalidated, new, do the same thing as another extension, are vastly inferior to another extension, etc, etc, is enough to make your head explode. The ARB has been notorious for releasing some of the *WORST* functionality of a graphics API ever conceived of by man. (See: P-Buffers). As a matter of fact their answer for that debacle was the FBO which was *DIRECTLY* modeled after D3D9's RTT object model.

The other real issue which plagues OpenGL is the fact that it IS an immediate mode driver. Extra care must be taken on part of the programmer to ensure redundant calls are kept to an absolute minimum, and that they're sequenced properly. There is actually a dedicated buffer for OpenGL drivers for command buffers which allow the programmer to buffer calls and maximize their ordering (which D3D implements in the background in vendor drivers). This isnt inherently a problem but it just means that extra time and headaches are going to be inevitable when addressing performance shortcomings. While D3D still executes MOST commands inline, many state changes are buffered and sequenced behind the scenes via the graphics driver or ignored entirely.

OpenGL's on the way out, it looks like. Unfortunately there just isnt much incentive for the ARB to make major changes to the system since the overwhelming majority of OpenGL clients are *NOT* game developers. They're in the field of professional imaging (CAD, Medical, etc). They're collectively a multi billion dollar industry that isnt interested in investing money to R&D or deal with the headaches which would no doubt ensue from a major structural departure.

qpHalcy0n wrote:If anything, in the past 4 years or so, especially since DX9, OpenGL has been playing a *MAJOR* catch up game. The big issue with OpenGL is that all of it's functionality is still expressed through a subsystem that is over 10 years old. As such, none of the underlying subsystem has changed in 10 years. All new functionality is implemented on the graphics driver, as are all new extensions to the OpenGL spec. The real double edged sword about that is that some vendors expose exploits in their hardware via some extensions where another may not. This can tack on excessive amounts of development time for vendor specific code designed to utilize these extensions. Not to mention, just keeping track of which extensions are invalidated, new, do the same thing as another extension, are vastly inferior to another extension, etc, etc, is enough to make your head explode. The ARB has been notorious for releasing some of the *WORST* functionality of a graphics API ever conceived of by man. (See: P-Buffers). As a matter of fact their answer for that debacle was the FBO which was *DIRECTLY* modeled after D3D9's RTT object model.

The other real issue which plagues OpenGL is the fact that it IS an immediate mode driver. Extra care must be taken on part of the programmer to ensure redundant calls are kept to an absolute minimum, and that they're sequenced properly. There is actually a dedicated buffer for OpenGL drivers for command buffers which allow the programmer to buffer calls and maximize their ordering (which D3D implements in the background in vendor drivers). This isnt inherently a problem but it just means that extra time and headaches are going to be inevitable when addressing performance shortcomings. While D3D still executes MOST commands inline, many state changes are buffered and sequenced behind the scenes via the graphics driver or ignored entirely.

OpenGL's on the way out, it looks like. Unfortunately there just isnt much incentive for the ARB to make major changes to the system since the overwhelming majority of OpenGL clients are *NOT* game developers. They're in the field of professional imaging (CAD, Medical, etc). They're collectively a multi billion dollar industry that isnt interested in investing money to R&D or deal with the headaches which would no doubt ensue from a major structural departure.

OpenGL is on the way out. Are you serious?! Almost all game consoles base their graphics API off of the OpenGL specs (with exception to Xbox). Direct3D does not provide the flexibility that OpenGL does, to do on the fly geometry instructions in OGL its a simple glBegin(), in D3D you have to jump through all these hoops (taking everything and crunching it down to one call, several for vertex arrays) which TBH is a pain in the ass.

You seem to be saying that having a 10 year old subsystem is a bad thing. You change to improve, you don't change for the sake of changing. And extensions added to one card are adding to others aswell, see when nVidia or ATI create a new extension it is added to the spec. This means that the other companies can see it and implement it in their card, whats so double edged sword about that. Sure you have to wait for it to make it to the driver but the time is minimal.

And OpenGL is not on its way out. Every non windows OS uses OpenGL as the primary graphics API, and this is not likely to change since hell will freeze over before MS port it to any unix based OSs.

OpenGL is on the way out. Are you serious?! Almost all game consoles base their graphics API off of the OpenGL specs (with exception to Xbox). Direct3D does not provide the flexibility that OpenGL does, to do on the fly geometry instructions in OGL its a simple glBegin(), in D3D you have to jump through all these hoops (taking everything and crunching it down to one call, several for vertex arrays) which TBH is a pain in the ass.

You seem to be saying that having a 10 year old subsystem is a bad thing. You change to improve, you don't change for the sake of changing. And extensions added to one card are adding to others aswell, see when nVidia or ATI create a new extension it is added to the spec. This means that the other companies can see it and implement it in their card, whats so double edged sword about that. Sure you have to wait for it to make it to the driver but the time is minimal.

And OpenGL is not on its way out. Every non windows OS uses OpenGL as the primary graphics API, and this is not likely to change since hell will freeze over before MS port it to any unix based OSs.

Whoa, hey now. I come in peace.

Yes, I do mean every bit of that. To be precisely specific, the 3D API in general is on the way out. It is not even close to accurate to say that "Almost all game consoles base their graphics API's off OpenGL specs". The PS2, nor the PS3 use OpenGL natively in any way, shape, or form. However, there are middleware toolchains which allow you to use OpenGL-ES for PS3, however PS2 was a different beast entirely. PS2 Linux development is also possible with OpenGL but the middleware is atrocious. Most of the middleware chains only attempt to make a direct PC port of your code to something the PS2 or 3 can understand, which is FAR less than desirable because these machines are not similar to the PC in many ways. The other thing to keep in mind is that OpenGL-ES is much closer to what was promised in OpenGL3 than what was delivered; so much so that it does not resemble OpenGL in many ways. Even Sony's support of PSGL (a special ver. of OpenGL-ES for the PS3) is minimal.

The graphics architecture of the PS2 is also very minimal, it uses several very generic SIMD chips (VU's or Vector Units) which do the majority of the T&L footwork. There are 2 vector units, the first can act as a co-processor to the CPU, the other operates completely seperately, but both in parallel with the CPU, then the GS (Graphics Synthesizer) performs the fragment ops and rasterization. The result is the graphics code is not very specific whatsoever because the processors are very generic. They're optimized (like Intel CPU's are optimized with SSE/2/3) for highly parallel 128bit vector ops, but they lack the optimizations that PC GPU's have in terms of onboard memory controllers seperate for texturing, vertex assembly, and so forth. This is why you simply don't see "OpenGL for PS2". Because it's not there.

The overwhelming majority (speaking from experience here) opt to use in house solutions and CTM (Close-to-Metal), which is really actually LibGCM for PS3 development. The PS3 is also in the same league opting out of a very highly specialized GPU and going for several more generic SIMD chips to carry out the bulk of the footwork.

Now, saying that "OpenGL is easier because you can pack draw calls inbetween a glBegin/glEnd call" is just....well I dont see where you're going with that. Most graphics programmers do not have such trivial issues. Vertex assembly isn't something thats terribly difficult nor is constructing a vertex buffer and executing draw calls from hardware buffered objects. As a matter of fact, this is preferred in OpenGL via VBO/IBO extensions. You'd find that the vertex assembly on 50,000 simply does not work within a glBegin/glEnd call. Thats horrendously inefficient. However, with FVF it is quite easy to quickly assemble a trivial vertex format and call non indexed render primitive calls on client side vertex lists. Now, you've got to understand that my criticism on OpenGL is on a critical level, I'm not really concerned with "How easy is it to draw a triangle" frivolties.

I don't think you're understanding how the vendor extensions thing works. It's not to say that if ATi comes out with an extension that it WILL be implemented into the core spec. Thats far from the case, and I'd urge you to find a case where that actually happens. If ATi can bring an extension to OpenGL that exploits hardware capability on their GPU's only thus edging nVidia out of the GL user competition, they will. They'd also have no interest in bringing that into OpenGL spec, that does not happen. There are regular contributors from both nVidia and ATi that serve on the ARB board but these core changes are very generic and are better for both parties concerned where it's vital for them that OpenGL succeed. "Other companies can see it and implement it in their card." No, absolutely not, the whole point of these is to "one up" the other by exploiting VENDOR SPECIFIC hardware exploits. That's why the vendor specific extensions often can NOT be implemented on other vendor cards without significant penalty by virtue of how their hardware operates. However, they "one up" each other all the time.....to the programmer's benefit and consequently to his chagrin as well.

Now let's think about the future here. Many of the biggest players in the realtime graphics arena (John Carmack, Tim Sweeney) are developing new technology that will exploit non-rasterized renderer architectures. Intel's new GPU the "Larabee" promises to potentially allow this thing to be blown wide open. There are many advantages to non-rasterized render architectures, and several still with rasterization. With more GPGPU solutions, like CUDA, people are exploring new more innovative ways to construct 3D vistas. I think this will be the way of the future, and over the next decade you'll see the 3D API's either dropping off the face of the earth or only resembling their former selves in proxy.

The reason having a 10 year old subsystem is not because of the fact that "You change to improve", its because the devices the API exploited are not even close to the devices of 10 years ago. Hardware buffered objects, programmable pixel pipeline, RTT, MRT....I could go on and on and on. None of these things were even close to being possible on decade old hardware. This functionality is now exploited via extensions to an aging subsystem of redundancy and inefficiency. OpenGL is in need of a pretty major face lift, and while we were promised one, I honestly don't expect anything that sweeping to happen. Again, due to reasons I have outlined in my prior post.

OpenGL is not on the way out completely for reasons I have outlined in my prior post. However, OpenGL support overall in the professional *game development* development arena is certainly waning. Primarily for a lack of cohesion and unity. These are for reasons both predictable and unpredictable (as the ARB has already shown us ).

It's not a war here. People will feel strongly about one or the other, but the bottom line is over the next 5 years at least I think you'll see professional support of OpenGL almost completely falling off in favor of more GPGPU in-house solutions (and D3D for that matter).

That was educational, qp. Thanks.

Sony's architectures are never going to be used with anything like DirectX or OpenGL. The entire goal of the PS2's architecture would not allow for it.

The design theory behind the PS2 (and basically PS3) was to have a strong CPU capable of doing things that the other (arguably smarter) designs did in hardware. As you said, the PS2 achieves this with vector units and a strong emotion engine (CPU). The PS2 doesn't have hardware t&l, anti aliasing, bumpmapping, or any of these things that the Gamecube, Xbox, and Dreamcast did in hardware.

Instead the PS2 emulates these effects in software and uses faster than shit framebuffer access to "brute force" the scene. That's why Okami looks like shit on the Wii and great on the PS2.

I don't know much about the PS2, but the PS3 does have an OpenGL implementation based on the OpenGL ES specs. And it's possibly similar for PSP even though it's nowhere near as powerful. PSGL is Sony's official implementation of the API, and interestingly enough a lot of OpenGL-related nomenclature was also adopted in the PSP homebrew scene for its homebrew devkits. (and because of that, with my prior knowledge of OpenGL, I was pushing and popping matrices in no time) But official PS3 devs also use an additional library that allows them to access more low-level functions of the hardware.

M_D_K wrote:Epic Games and id Software are two companies(off the top of my head) that use OpenGL in their engines.

Id Software uses only opengl, but Epic Games uses Directx for the Windows and Xbox 369 versions of the engine, and Opengl for the other platforms(not including PS3).