Jump to content
  • Advertisement
yyam

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

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
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!