• 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
Seabolt

Vulkan
What are your opinions on DX12/Vulkan/Mantle?

121 posts in this topic

https://github.com/boreal-games/magma

 

Decided to write my own comprehensive Mantle headers and loading library so I can use Mantle while waiting for Vulkan.  So far I've filled out [tt]mantle.h[/tt], [tt]mantleDbg.h[/tt], and [tt]mantleWsiWinExt.h[/tt].

 

There are a couple minor issues that I've discovered so far:

  • [tt]grWsiWinGetDisplays[/tt] thinks the output array you pass into it is zero-length
  • The Windows WSI error code values haven't been determined for the aforementioned reason
  • I could only get the functions working for the 64-bit DLLs so far, seems to be a calling convention issue

Over the next few days I'll be writing the other extensions, like the DMA queue extension.

Edited by Boreal Games
0

Share this post


Link to post
Share on other sites

Porting such that your Direct3D 12 implementation mimics that of Direct3D 11 will leave you will 50% the final performance of Direct3D 11 on Direct3D 12. In other words, definitely do not model your graphics pipeline around that of Direct3D 11 inside Direct3D 12.

It's obviously not ideal, but probably still better performance than just sticking with D3D11. MS showed off a naive port of Futuremark's engine, where there'd just shoe-horned D3D12 into their D3D11-oriented engine (by replacing their D3D11 redundant state removal / caching code with a D3D12 PSO hashmap) and still got ~2x the performance of the original D3D11 version.

0

Share this post


Link to post
Share on other sites

It is just me, or with this new APIs (at least with D3D12 and after you learned the new basis) writing code and implement things feels more natural and less artificial then older APIs with a higher level of abstraction? Yeah, it is not sill like writing general code that will run on the CPU only, but it feels kinda closer.. Or probably it is just because these API are shorter and you have to remember less calls and structures XD

Edited by Alessio1989
0

Share this post


Link to post
Share on other sites

It is just me, or with this new APIs (at least with D3D12 and after you learned the new basis) writing code and implement things feels more natural and less artificial then older APIs with a higher level of abstraction?

I agree. I think that's because there is less member and structures ; at least with OpenGL there are often several way to have the same result with very subtle difference.

For instance to create a buffer there are 2 functions, glBufferData and glBufferStorage, which can be used to upload data, and you have 1 function to upload data to a specific range (glBufferSubData), you have 2 functions to map the data (glMapBuffer and glMapBufferRange), there are 2 ways to define VAO (one that binds underlying storage and another one that split the vertex description and the buffer mapping), and so on...

 

With DX12 creation and upload are completly decoupled, there is a single mapping function. There is also an upload function but I never used it so far. It's much nicer.

 

The only "not so natural" things that may come from DX12 is that you need to avoid modifying resources when they are used by a command list. I do this by having dual command allocator and constant buffer that are swapped when a frame is finished.

0

Share this post


Link to post
Share on other sites

I do this by having dual command allocator and constant buffer that are swapped when a frame is finished.

You are supposed to use signals.


L. Spiro
0

Share this post


Link to post
Share on other sites
You are supposed to use signals.


L. Spiro

 

Sure, I use signal to wait for frame N to be completed when frame N+1 last command list has been submitted.

I assume that it's still necessary to keep command queue filled so that gpu is always busy.

0

Share this post


Link to post
Share on other sites

I was just wondering, since game engines like DICE support already support mantle, wouldn't those engines be more likely to switch to Vulkan rather than DirectX 12, since Vulkan is based on Mantle?

Then, they would have a big competitive avantage over other games because they could run on Windows 7 and 8, and not just Windows 10. From the looks of it Vulkan seems to set to be released soon. Imagination Tech already has their GPUs working with Vulkan.

Edited by Ed Welch
0

Share this post


Link to post
Share on other sites

Direct3D 12 is based on Mantle and some reports say it will replace it.
Vulcan may or may not be is based on (or rather inspired by) Mantle (couldn’t double-check while on my phone).


L. Spiro

Edited by L. Spiro
0

Share this post


Link to post
Share on other sites

Direct3D 12 is based on Mantle and some reports say it will replace it.
Vulcan may or may not be based on Mantle.


L. Spiro

 

There has never been any mention of D3D12 being based off of Mantle, nor did Microsoft ever make any statement about that. 

AMD however has stated that they provided Khronos with Mantle to use as a base, and from what I can see they pretty much did draw inspiration from it.

0

Share this post


Link to post
Share on other sites

There has never been any mention of D3D12 being based off of Mantle

“Based off” might be a slightly inaccurate choice of words (since I was just using the words he used), but no need to get pedantic.
http://www.extremetech.com/gaming/177407-microsoft-hints-that-directx-12-will-imitate-and-destroy-amds-mantle

“Imitate” and “inspired by” are words often used (same words used to describe Vulkan’s relationship with Mantle).


L. Spiro

Edited by L. Spiro
0

Share this post


Link to post
Share on other sites

That is indeed a much more reasonable way to look at it. 

 

I like to see it as AMD lighting a fire under both Microsoft and Krohnos's asses by showing them that developers do truly want and need new and better ways to interact with graphics hardware on PC. If you want to call that Microsoft being inspired by AMD that's totally valid, but the APIs themselves while sharing certain concepts (just like previous versions of DirectX and OpenGL shared concepts) are very very different.

0

Share this post


Link to post
Share on other sites

I like to see it as AMD lighting a fire under both Microsoft and Krohnos's asses by showing them that developers do truly want and need new and better ways to interact with graphics hardware on PC.

That’? how I see it.


L. Spiro
0

Share this post


Link to post
Share on other sites

I was just wondering, since game engines like DICE support already support mantle, wouldn't those engines be more likely to switch to Vulkan rather than DirectX 12, since Vulkan is based on Mantle?
Then, they would have a big competitive avantage over other games because they could run on Windows 7 and 8, and not just Windows 10. From the looks of it Vulkan seems to set to be released soon. Imagination Tech already has their GPUs working with Vulkan.

These guys already support half a dozen different APIs. It's cheap for them to internally support both (and then game teams can choose whether to ship both/either/neither based on practical realities at the time).

Also Dx12 isn't just Windows10; it's also Xbone. Console games likely make more money for EA than PC, so optimizing for Xbone is probably important to them.

Off the top of my head, the full list of current APIs (as in, there's a justification for using them for a product right now) is:
Dx9(PC), Dx9.x(360), GCM(Ps3), GNM(Ps4), GXM(PsVita), Dx11(PC), Dx11.x(Xbone), Dx12(PC), Dx12.x(Xbone), GL3(PC), GL4(PC), Mantle(PC), Vulkan(PC), GL|ES2(Mobile), GL|ES3(Mobile), Metal(iOS).
At this point, adding one item to that list seems like a small task! :lol:
[edit]..aaand I forgot Nintendo, add two more![/edit]

Direct3D 12 is based on Mantle and some reports say it will replace it.
Vulcan may or may not be is based on (or rather inspired by) Mantle (couldn’t double-check while on my phone).

Vulkan is very much Mantle derived. Lots of the example Vulkan code that's been shown off so far would compile perfectly fine under the Mantle SDK if you just replace the "vk" prefixes with "gr" :D
I'd go as far to say that Vulkan 1.0 will be thr first public release of Mantle! :lol:
0

Share this post


Link to post
Share on other sites

Just for laughs...

 

uGgcRYG.jpg

 

Don't know how much is old this page on Mantle manual, but the DX SDK page was there when I joined to the DX12 EAP on October 2014..

 

Anyway looking at the early private DX12 EAP docs the D3D12 API has changed a lot from it announcement to the current public version..

Edited by Alessio1989
0

Share this post


Link to post
Share on other sites


Don't know how much is old this page on Mantle manual, but the DX SDK page was there when I joined to the DX12 EAP on October 2014..

 

I'm in both the Mantle beta program and the DX12 EAP, the mantle documentation has been around for quite a bit longer as far as I'm aware.

0

Share this post


Link to post
Share on other sites

Apple has announced their upcoming OS X version El Capitan. Thought that it would be relevant to this thread, as it will bring support for their Metal API to OS X.

 

I have no details, but apparently there has been claims of 50 % improvement in performance and 40 % reduction in CPU usage.

1

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