• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
mrheisenberg

DirectX "Blue" speculations

15 posts in this topic

New DirectX version coming in 2014(atleast rumors say so): http://www.fudzilla.com/home/item/30666-next-directx-codenamed-blue
 

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#####.

0

Share this post


Link to post
Share on other sites
Whatever features it implements, it will almost certainly not run on old computers.


Microsoft moved DirectX into the Windows SDK.


That means when the Windows 8.1 or Windows 9 (or whatever the end up calling it) SDK is released, that Windows SDK will include updates to DirectX.
0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

It'll be probably be something to do with unified virtual memory > http://www.xbitlabs.com/news/graphics/display/20130412175120_Nvidia_Next_Generation_Maxwell_Architecture_Will_Break_New_Grounds.html

I just hope the code difference isn't like it was between dx9 and dx10, so it would be easier to port existing code to the new one and just set a feature level for backwards compatibility.

0

Share this post


Link to post
Share on other sites
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...
0

Share this post


Link to post
Share on other sites

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).

I guess the problem is this: http://www.rockpapershotgun.com/2013/02/22/week-in-tech-the-end-of-graphics-and-other-stuff/

No point in updating the APIs when the hardware itself isn't bringing much new to the table

 

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

Likely it'll happen only the day we get rid of rasterizers (e.g. if we get raytracing GPUs or something like that)

0

Share this post


Link to post
Share on other sites

Is it normal to feel worried every time they announce a new API version?Like a primal fear of change or something huh.png Its like when people panicked about XNA's future.

0

Share this post


Link to post
Share on other sites

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).

I guess the problem is this: http://www.rockpapershotgun.com/2013/02/22/week-in-tech-the-end-of-graphics-and-other-stuff/

No point in updating the APIs when the hardware itself isn't bringing much new to the table

I'd have guessed that hardware adapts to new API specs rather than the reverse.

0

Share this post


Link to post
Share on other sites





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).

I guess the problem is this: http://www.rockpapershotgun.com/2013/02/22/week-in-tech-the-end-of-graphics-and-other-stuff/
No point in updating the APIs when the hardware itself isn't bringing much new to the table
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.
0

Share this post


Link to post
Share on other sites

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.
0

Share this post


Link to post
Share on other sites

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.
0

Share this post


Link to post
Share on other sites

<snip>

 

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.

0

Share this post


Link to post
Share on other sites

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.

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.
0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0