   Why is it such a hassle to use DirectX API?
  I find it tremendously hard, even after tutorials, to memorize/do any functions hardly at all without constant reference. I can't get a sprite loaded because of constant errors, I don't know what to do with so many device stuff.....I get lost with all the information required to initialize Direct3D itself.How can anyone seriously make a full game with DirectX? I can't believe it's even possible at the rate I've been going through....And yes, I've read tutorials, and even though they elaborate they don't elaborate enough on explaining exactly what and how to do every single thing. And that's where my problem begins.....If no one tells me "Do this to do that, exactly this way, then this will work, etc."Then I won't ever really understand what to do next. I'm currently stuck at barely drawing a triangle to the screen and no one, so far, can really make me understand its better workings easier.   
If no one tells me "Do this to do that, exactly this way, then this will work, etc."Then I won't ever really understand what to do next.Actually, if somebody does tell you that (as many tutorials do), you will know even less what to do about 5min later when you want to do something that's mostly like it but not quite. Don't blindly memorize step-by-step-instructions, don't even try to memorize all API-calls and their parameters (they just turn everything upside down with every second version of DX anyway). Learn WHY you call those function and WHAT they actually do.Write enough projects with it and you will know all the important functions inside out, but don't expect to read a book or tutorial and be able to write a DX app without having a reference or the documentation nearby. I still wouldn't know where to start creating a window using the windows API. I wrote that once sticking to MS documentation and reused that code for years. Same goes for initializing DX.   ;  Direct3D is a low level API for controlling the hardware. It's not aimed at game programmers, but at game-engine programmers.If you don't need that low-level control, then something more abstract, like SDL, is probably an easier choice.   ;Direct3D is a low level API for controlling the hardware. It's not aimed at game programmers, but at game-engine programmers.If you don't need that low-level control, then something more abstract, like SDL, is probably an easier choice.A game engine is usually done with C++ anyways. It is not limited to DirectX or anything, but I want to use DirectX because I already have it installed and installing others will be a hassle. Also, DirectX does fine with game development......Many do it. It does good with graphics displays/results, and has everything needed for game development in both 2D and 3D.So I didn't get your point there.....   ;  6 months ago, I was stuck with OpenGL. It didn't make sense, I had no idea how anyone could learn it. 6 months later, I can make it do some amazing things. Different API, but chances are the story would be the same if I had chosen DX. Like Trienco said, don't put too much effort into learning the individual API calls. You'll pick up the important ones through repetition, and the ones that you use less can always be found from MSDN. There's a lot to learn, and if you try to learn it all quickly, you won't actually know any of it. If there's something you don't understand, look it up on MSDN or google it. Chances are someone else was in a similar situation at some point.   ;  After a while you will have some kind of framework anyway. I usually copy this stuff (window loading, sprite shit etc) from earlier projects and tweak them if necessary   ;[quote name='Hodgman' timestamp='1302152825' post='4795355']If you don't need that low-level control, then something more abstract, like SDL, is probably an easier choice.DirectX does fine with game development......Many do it. It does good with graphics displays/results, and has everything needed for game development in both 2D and 3D.So I didn't get your point there.....[/quote]My point was explaining the the reason that D3D is complex -- it's because it's a low-level API that gives you a lot of direct control over the hardware.If you don't need that level of control, then there are alternative libraries, which, in return for giving up those low-level details, reward you with a simpler-to-use library.Learning D3D is equivalent to earning a heavy vehicle license and becoming a bus driver.Alternatives like SDL are the equivalent of simply catching the bus to the shops.Yes the former can be a good long term investment, but sometimes you just want to let someone else do the driving for you.I know D3D is fine for game development, it's my job to use it. I was trying to answer your question as to why it's such a hassle to use -- because of the level of abstraction on which it operates.   ;  Its not that bad    The API is for providing a hardware neutral interface to the hardware, and the API more or less reflects what the hardware can do.   The main thing with the D3D to keep in mind is that for the most part, the only commands that matter from debugging point of view are the Draw functions (Draw, DrawIndexed, DrawIndexedPrimitive etc).  The remaining functions are broken up into two major categories:Resource Management (CreateTexture, LockTexture, Map, Unmap, etc)State Control/Setting (OMSetBlendState, PSSetShader etc)The other major wrinkle is that D3D10 and up were refactored to be much  more efficient in the driver layer, at the cost of being more annoying  to developers.  The main side effect of this change was all the states became state objects you have to create, are slow to create, and are limited to a somewhat artificially low number (4096 for most tpes of state objects)So tools like PIX are used to find the broken draw, use it to inspect every aspect of the state for errors, and figure out why the code didn't set it correctly.   The PC PIX UI is really poor in many areas, but the data is all there if you know how to look for it.  The major thing to do is select a draw call, and the device pointer it is bound to will be right-clickable which can get you to the screens that display every piece of the render state.   ;The other major wrinkle is that D3D10 and up were refactored to be much  more efficient in the driver layer, at the cost of being more annoying  to developers.  The main side effect of this change was all the states became state objects you have to create, are slow to create, and are limited to a somewhat artificially low number (4096 for most tpes of state objects)Really? Because as I recall it the reaction to the introduction of the DX11 API was 'ah, thank god.. this is so much better than DX9'.While state block numbers might be limited in practical terms there are more than enough to be working with and the creation (in a thread free manner so as not to block your rendering thread) being slow isn't a problem as these things are often created once up front and shared after that point. That's not to day D3D11 doesn't have problems below the API layer, but from a game developers point of view it's certainly not 'more annoying', if anything it gives a greater level of fine grain control which is always welcome at that level.   ;  IMO it's not about learning the API, it's about learning the concepts (and the math that entails) behind 3D graphics. The Gfx API is just the vessel to put those concepts into practice and onto the screen.   