What new features do you think will be implemented?Will it run on Windows 7 like they allowed for 11.1 or will they completely move on?It's weird, cause if it really does come out in 2014 and requires a new breed of chips, then the new consoles(which should support shader model 5) would be in for a really bad deal.I mean if they had waited just 1 more year, they would have been supplied with a new DirectX12-supporting GPU and drastically prolong their lifespan.Eh, I think I over-speculated, what are your thoughts?What would you like to see?I'd really like it if they remove all the numbers, so it'll be just ID3D##### instead of ID3D11##### or ID3D12#####.

"One objection to a “critique of C#” would be that you can’t talk about C# without talking about the whole “.Net experience”. However, one can approach the topic of Hitler without a complete discussion of Nationalist Socialism, so I feel justified." - Steve White.

I'd like to see if Khronos has any news on OpenGL 5 (or 4.4), unless they're specifically playing "catch-up" with DirectX right now (ie, no news until new DirectX gets released).

Anyway, whatever they're going to peddle, I just don't have the money for it. So I'm staying with my GTX 560 Ti. In any case, its going to be a while before I even learn enough to use OpenGL 4.3 features, and its not like I have much time for gaming these days.

I doubt it; from a DX point of view unified memory address space doesn't matter one bit it's all hidden away by the driver arch anyway.

Likely to be a DX11.2 update; few new features and that's about it to go with the Windows Blue/8.1 update which is also coming.

However the planned introduction of simple serial cores by both AMD and NV does prove an intresting challenge to DX in general as there is currently no provision to access them; but frankly given the two couldn't agree on a way to do PRT for DX11.1 I don't hold out much hope for a unified solution there either for a while yet.(Until then, like AMD's ACEs, it'll be OpenCL extensions and custom APIs to get at them for compute work.)

Really, a new API is needed to replace both DX and OpenGL for games... well, I can dream...

Usually the reverse is true. You can check up on the OpenGL extension registry because typically new graphics functions show up as OpenGL extensions rather early in the process.

The last forty or so of the extensions are not in the current Direct3D in any obvious form. There are also quite a few of the roughly 570 extensions that have never been incorporated into Direct3D but are available to OpenGL developers.

An SDK update will likely include several of the new OpenGL extensions that are now missing in Direct3D, but not all of them.

This problem is the main gripe about Direct3D, and why I have always disliked it.

In the OpenGL world you simply test if a feature is present. If it exists you can use it. You need only wait until the driver supports it. As a programmer you are expected to know what features are fast and modern, and know what features are slow and ancient. You can mix and match old and new, fast and slow. When a new feature comes out you do not need to rewrite your game engine, you can simply enumerate and use the feature if enumeration succeeds. And if you are working with a hardware vendor on a cool new feature you only need to wait for your experimental drivers and not for a new version of the operating system.

Direct3D provides the convenience of a single feature set: If you can create the interface then you get those features, all from the same graphics card era. That is also its fatal flaw. If the feature is not in the feature set you cannot get access to it. If you want to target cards from 2003 but also take advantage of newer features on new cards there is no way to do it on Direct3D. For quite some time many games shipped with dual binaries to handle different versions of Direct3D. This is something OpenGL developers don't encounter.

If you want to know what is coming in the next Direct3D release, look at the features that OpenGL has added over the last two years. Direct3D will include some (but usually not all) of those.

I'd like to see if Khronos has any news on OpenGL 5 (or 4.4), unless they're specifically playing "catch-up" with DirectX right now (ie, no news until new DirectX gets released).

Anyway, whatever they're going to peddle, I just don't have the money for it. So I'm staying with my GTX 560 Ti. In any case, its going to be a while before I even learn enough to use OpenGL 4.3 features, and its not like I have much time for gaming these days.

OpenGL has never needed to play catch-up to Direct3D.

Almost every feature that was added to Direct3D was available to OpenGL first. Many of the features developed at Microsoft's request for Direct3D and that have Direct3D-style names for their OpenGL extension were co-released for both OpenGL and Direct3D at the same time as the hardware became available. One notable exception to the rule was hardware vertex buffers.

Of the roughly 570 extensions, about 99% of the features were available on OpenGL before or simultaneously with Direct3D.

When ATI and nvidia create new features, they nearly always provide the features to close-relationship developers to test and try out as private OpenGL extensions on development drivers. These are then submitted to the ARB and registered as extensions at about the same time they are made public. This process almost always happens months before the feature becomes available to general developers through Direct3D SDK updates.

Anyway, whatever they're going to peddle, I just don't have the money for it. So I'm staying with my GTX 560 Ti. In any case, its going to be a while before I even learn enough to use OpenGL 4.3 features, and its not like I have much time for gaming these days.

I guess I'm on the same boat. My opinion is that further market fragmentation is to be avoided. I don't expect next D3D to add much though.

I'm not sure that it's wise to start raising the old API war here, but this post - while containing a kernel of truth - ignores the main reasons why people like using D3D - better tools, better consistency (I can write a D3D11 program today and it will run consistently on Intel, NV and AMD hardware) and more robust drivers. Let me know when Intel and AMD have fully featured GL4.3 drivers that don't come with the usual havoc caused by bugs and inconsistencies.

On the other hand, with GL I sure can tap into extra hardware functionality via vendor-specific extensions early, but if I do so then I'm limiting my code to the segment of the market that has that specific hardware. Otherwise I'm looking at writing multiple different code paths with varying performance and quality. Remember when Doom 3 had 5 different rendering backends? We don't want to have to go back to those days.

Microsoft and D3D have done the world a favour by forcing vendors down a path of consistency which has been of benefit to everyone; throwing that away seems a strange thing to want to happen.

The newer vendor-specific extensions are nice for experimental work, but it's a bit disingenuous to speak of them as if they were more generally useful. The real advantages of GL have always been it's portability, it's richer and more flexible API and it's exposure of more modern features (here I'm talking about the core API, not vendor-specific extensions) without requiring an OS upgrade (unless you're Apple, who seem to have missed the point of that part of it).

In reality both APIs bug me but for different reasons. Each has their own strengths but the weaknesses are sufficient that anytime I'm using one I find myself wishing I was using the other.

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.

Almost every feature that was added to Direct3D was available to OpenGL first. Many of the features developed at Microsoft's request for Direct3D and that have Direct3D-style names for their OpenGL extension were co-released for both OpenGL and Direct3D at the same time as the hardware became available. One notable exception to the rule was hardware vertex buffers.

Off the top of my head, missing from the core API while present in D3D; VBO, FBO, efficient frame buffer blitting ability, functional multi-sample render target support, Geo Shaders (and associated functionality), Hull/Domain shaders, Compute shaders, (still missing, last I checked, append/consume buffers), no cross vendor way of dealing with the depth/stencil buffer for ages (DX9 feature), draw indirect (index, instanced and dispatch variants), instancing support (DX9), point sprites where missing and then broken for ages.

I dare say others exist.

While the ARB are getting better, it only took a couple of years post-D3D11's release to sort out the gaps, to claim OpenGL was never missing features is to distort the truth so much it starts to resemble a VW Beatle. Heck, FBOs and associated functionality took YEARS to appear even in extension form as back then the ARB couldn't organise an arse finding competition if they were given a map and complete step by step instructions.

Right now I can only think of two (AMD) OGL extensions I'd like to play with; multi-draw indirect and 'sparse texture' (aka PRT) as they have no D3D version... unfortunately every time I consider writing some code to do so I remember that a) I have to worry about extensions in some manner and b) bind-to-fucking-edit is still OGL's way of doing things which is a pants-on-head retarded API model these days.

Bind to edit needs to die in the next GL_VERSION. Fortunately GL_EXT_direct_state_access is quite well supported (and id Software use it so it bloody better well be) but a core API version with an extension available for downlevel hardware is badly needed. This is something that's a purely artificial software construct and there is no good reason for it to continue to exist beyond ARB inertia (and the possibility that someone on the ARB loves it - which I'm not ruling out because even newer functionality like texture storage still uses it). Just bite the bullet and respecify both texture objects and buffer objects; there is a LOT of other cleanup needed in both (the old binding point concept is also a bizarre artificial software construct) and buffer objects in particular are still (even in the days of GL_ARB_map_buffer_range) missing a sensible and performant method of consistently handling dynamic updates for all buffer types - which is incredibly stupid considering drawing from buffer objects is the only way to draw with the core profile.

D3D never had that last problem; DISCARD/NO_OVERWRITE works and works well; it behaves as expected, you ask for specfic behaviour and you get it. I'm eternally bemused that GL continually adds esoteric (and sometimes not-so-esoteric - like vertex attrib binding, which D3D has had since version 9) functionality but still fails to have these really basic problems addressed.

GL FBOs still lack the ability to switch the color buffer without also switching the depth buffer. That's nuts.

On the other hand, I can add something like texture arrays to my GL code without having to also move to a completely different API and rewrite all of the rest of my rendering code in the process, and that's awesome. It's understating how awesome it is by just mentioning it as one point over a few lines so I'll say it again - that's AWESOME.

So overall that's why I'm annoyed by both APIs and that's why I get annoyed whenever anyone talks of either as if they were perfect, because neither is and each has serious flaws that the other doesn't have. I fail to get excited about a new version of either in the current circumstances, but give me a GL with bind-to-edit removed for textures and buffer objects, shared standalone uniforms and a sensible performant way of updating dynamic buffer objects, make this functionality available for downlevel hardware, get bug-free drivers exposing these out in a decent timescale, and I'll be happy. Without those, D3D still wins.

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.

So overall that's why I'm annoyed by both APIs and that's why I get annoyed whenever anyone talks of either as if they were perfect, because neither is and each has serious flaws that the other doesn't have.

I think anyone with a degree of honesty would agree with that; while D3D is now my preferred API (before the GL3.0 fiasco I was using OpenGL all the way) it is, as you say, not perfect but currently it is the best we've got.

That's partly why my opening post mentions a new API; something akin to NV's Bindless extension/design to remove the overhead that exists in both the APIs. With D3D being considered 'mature' technology now there might be an opening for something to come along; I dare say it would gain some ground reasonably quickly from the AAA speed nuts like myself even if it wasn't used for a couple of years in a real product after release.