• Advertisement

Which API to learn first

Recommended Posts

Hello!

I want to get into graphics programming so I've started learning DX11 but I'm not sure if it's the best choice to learn first. Obviously the end goal is to know as many as possible, but we all have to start somewhere. My first question is should I start by learning one of the newer, lower level, "bleeding edge" APIs like Vulkan/DX12, or should I start with DX11/OpenGL? I heard some people say that Vulkan/DX12 aren't really THAT much harder than the others but I've also heard the opposite. My thinking for choosing DX11 was that it was going to be easier and it would give me some good base knowledge to go and learn the more complicated APIs later.

My second less important question is should I start with the DX or GL size? I've heard that DX is more programmer friendly and is easier to debug so will be better for beginners, is this true?

A bit of background on my competency: I feel like I have a good knowledge of C and C++, I've completed a handful of games with SDL and SFML and I do embedded C programming as a job. My 3D math is lacking but I feel like it's something I can learn.

Thanks for your help :)

Share this post


Link to post
Share on other sites
Advertisement
15 minutes ago, Hodgman said:

Having a validation layer built into the API is really useful for catching your incorrect code. Of course you want to check all of your function calls for errors, but having the debugger halt execution and a several-sentence-long error message appear describing your coding mistake is invaluable.

I never did D3D. So maybe this is something different. But isn't that similar to GL_ARB_debug_output ?

Edited by _Silence_

Share this post


Link to post
Share on other sites
1 hour ago, _Silence_ said:

I never did D3D. So maybe this is something different. But isn't that similar to GL_ARB_debug_output ?

Yep, I counted it above as a vendor extension because as in that link: Implementations may create messages at their discretion. In debug contexts, the implementation is required to generate messages for OpenGL Errors and GLSL compilation/linking failures. Beyond these, whether additional warnings and so forth are generated is a matter of the implementation's discretion and quality.
i.e. the only thing that it's specified to do is the same as checking error codes. In older code, you would check glGetError after every operation, but now you can use this mechanism to do that instead.

The big problem is that you're asking your vendor's driver to police your app, so the quality of the QA that they do for you is going to vary depending on your driver. With D3D, it's Microsoft policing your app, and with Vulkan it's Khronos policing your app. Everyone gets policed the same way. The reason this distinction /separation is important is because, for example, say your app does something illegal, but Vendor A's driver is built to tolerate it -- You should expect that Vendor A's driver will choose not to warn you about this flaw in your program that Vendor B's driver will (correctly) crash on. Later on, you'll claim that your app ran fine under a debug context so Vendor B's drivers must be buggy, when actually Vendor B's drivers are correct and Vendor-A-failing-to-warn-you is the actual bug :o

The other good thing about the validation layer actually being standardized is that you can rely on its contents as a developer. e.g. if I want to track down a specific performance warning in D3D12, I can look up its enum value and tell the runtime to break into my debugger on any line of code that triggers that warning, e.g.

infoQueue->SetBreakOnID(D3D12_MESSAGE_ID_CLEARRENDERTARGETVIEW_MISMATCHINGCLEARVALUE, TRUE)

In GL this is technically possible too (if your particular driver supports the particular warning you're looking for... remember the whole layer is completely unspecified!), but you've got to reverse engineer the log message from your particular driver and then write your own code to watch for the message and trigger a breakpoint :/

Share this post


Link to post
Share on other sites

APIs are just a means to an end, in this context a way to express certain graphics algorithm and concepts. With that said wrt to what graphics API to learn first, I'll keep my bias out it and go with the recommendations already given. However, before you delve into API ( which are useless by themselves ) how is your understanding of the basics:
-3D maths
-Lighting.
-Shaders ( not the actual implementation( API specifics), but the concept of )
...

Without having a basic understanding of these, you will find that you will be fighting a battle on 2 front, on one hand the basic concepts, on the other hand API itself.. The two are NOT one and the same.
 

Share this post


Link to post
Share on other sites

@Hodgman - I would put a note besides GL support for MacOS.  MacOS stopped supporting OpenGL back in version 4.2,which is over 5 years old now?  Otherwise great summary.

Share this post


Link to post
Share on other sites
1 hour ago, Mike2343 said:

@Hodgman - I would put a note besides GL support for MacOS.  MacOS stopped supporting OpenGL back in version 4.2,which is over 5 years old now?  Otherwise great summary.

Did they stop supporting OpenGL ( kinda find that hard to believe, as this would force all legacy application to have to update ), or they just don't support any version greater than 4.2? 

Share this post


Link to post
Share on other sites
6 minutes ago, cgrant said:

Did they stop supporting OpenGL ( kinda find that hard to believe, as this would force all legacy application to have to update ), or they just don't support any version greater than 4.2? 

Older apps are fine.  They're no longer updating the drivers beyond the 4.2 standard.  They're also only fixing very critical bug issues that may lead to security issues.

Share this post


Link to post
Share on other sites
11 hours ago, Hodgman said:

My main points would be something like:

...

Thank you so much! Really great info, clears up a lot!

Thanks everyone, you'll probably see me again when I screw something up :P

Share this post


Link to post
Share on other sites
2 hours ago, Mike2343 said:

@Hodgman - I would put a note besides GL support for MacOS.  MacOS stopped supporting OpenGL back in version 4.2,which is over 5 years old now?  Otherwise great summary.

On the flip side, if you happen to own a Mac, I'd put Metal right at the top of the list for ease of learning.

You get a pretty familiar-feeling setup for anyone with an OpenGL background, while easing into the lower-level stuff without all of the complications that Vulkan/DX12 layer in.

Share this post


Link to post
Share on other sites

I think DX11 is a decent choice to start with. I've been (slowly) building game engines in my spare time. I started with DX11, then ported that project (partially) to DX12, and recently I've been messing with Vulkan. DX11 was definitely the easier one to work with and it's still very much relevant for coding games on Windows. DX12 and Vulkan require a LOT more code even to do simple things and can be daunting to start with. With DX11 (compared to DX12) there are also more books and tutorials online, so learning will be easier.

However, I do really like Vulkan, and I've found the API to be more clear as to what specifically you are doing with the code. So, in this sense, something like Vulkan can help you learn how GPUs work a little more than the older APIs that can hide a lot of details for you. I also find the Vulkan API to be more straight-forward and understandable, but this may be because I came in with experience from DirectX first. There are also a good amount of books and online resources for Vulkan (compared to DX12), so if you do want to try with the newer APIs, I would recommend Vulkan over DX12.

So, all in all, starting with DX11 is probably a good choice. It will be easier to get running, and you'll be building skills you can apply to other APIs if you decide to switch in the future. Definitely get Frank Luna's book, it's one of the most well written graphics programming books out there, and the included source code is a gold mine.

Share this post


Link to post
Share on other sites

Will not be better to start with OpenGL/ES so you could support wider device range? But don't know exactly whats the OS target, I've recently started with Metal (on Mac) then later on I'll jump to OpenGL to support Linux, Older macs and maybe Windows (I'm playing with Swift, so this las platform will be a bit harder to support yet, but theres a long, long way to get to run my engine in mac even). This is just a pet project, but maybe instead of trying to learn an API you need first to understand all the concepts (I'm not an expert) but vertex, matrix, quaternions, shaders, etc then jump into the API because I've struggle a lot in the beginning with all those things when you need to implement, new things and they are complicated (even know I just understand only the principles of shaders and still learning the math behind the render engine).

But its mostly up to you, if your target is only Windows for now, yeah the D3D11 has a wider range of supported devices.

Share this post


Link to post
Share on other sites

If your starting out, I don't think a wider device range is going to be that important. most of the time your using the os you feel most comfortable with to develop on and for, while your learning

A lot of people learn the basics of 3D graphics by learning the API's, so i would just jump into one of them honestly, he'll learn about all that stuff when he gets there. For example, to draw a triangle on the screen, you don't need to know how to multiply matrices or work with quaternions. You don't even need to know how to work with shaders right away, just copy the one line shader functions to start with. Not that some theory wouldn't make it a smoother ride or anything though.

I know it's already said, but i'd suggest starting with D3D11, It's a cleaner API in my opinion. Once you learn that you can easily learn OpenGL anyway, they have very similar concepts

Share this post


Link to post
Share on other sites

I'm curious now about...

1- Whats the main difference (in performance in Windows) between OpenGL and D3D11?
2- Is Direct3D (11/12) similar to Metal API?
3- Is Vulkan similar to Metal API?

Edit: This is the first time I found a kinda good game engine video tutorial (is a playlist with 60 videos, they are quite old but OpenGL didn't change so much in the last years), don't know if it comes to the case but in case someone finds it useful, its on Java/OpenGL but is understandable. (Yeah the voice is a bit annoying but you get used to it)

Also if you want to check directly the repo of the tutorial https://github.com/BennyQBD/3DGameEngine

Edited by norman784
Added more info

Share this post


Link to post
Share on other sites

I don't think there's a whole lot of difference between opengl and d3d11 perfromance on windows. At least I've never noticed anything that stands out. I suppose you can precompile d3d shaders, but cannot precompile opengl shaders, so start up times could maybe be slightly improved. Also i'd say the code to set up is easier to do with d3d. You don't need to check all these specific features to see if they are supported like you need to in opengl (although you might just use a library that does all the checking for you). There's a lot of really old opengl resources out there for learning, so that's another check against starting with opengl in my opinion. with d3d, you just need to look for anything with d3d11, or d3d12, depending on what your trying to work with. The separation between newer and older iterations of d3d is more distinguished than the versions of opengl (and should you use the glut or glew or glu libraries for opengl? or should you use something else? or not use any of those?)

I don't know much about metal, but d3d12 is similar to vulkan in that they are both "closer to the metal". They make no assumptions as opengl and previous iterations of d3d do. This means more work for the app developer, but allows you write the graphics system so that it fits your particular app more specifically, which can get you major gains in performance if done right than if you were to use an API that tries to do more for you. I believe Metal is similar to vulkan and d3d12 in that way?

Share this post


Link to post
Share on other sites

Just with a superficial reading about Vulkan and D3D12, seems that they objective is the same, so in the end the 3 of them (including Metal) do the things in a similar manner, so the API will looks familiar switching between them. So I don't see the point to learn D3D11, yeah you could get maybe quickly to get something done, but the market is moving to a newer API.

So I think you need to focus on one of those 3. At least if you don't target older graphic cards (I think, at least Vulkan, support graphic cards from 2012 and newer).

Share this post


Link to post
Share on other sites

D3D12 and Vulkan are there for the graphics experts to be able to get the most out of their hardware. They're not for hobbyists who want to write a toy engine in their spare time. D3D11 and GL are still there for that. Metal, in my opinion, is somewhere in the middle between the two extremes, being lower level than GL, but higher than Vulkan.

Of course, if your goal is to understand how a graphics driver works and how the full graphics stack works, from CPU to GPU, then by all means go for D3D12 or Vulkan.

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


  • Advertisement