DirectXtutorial.com

The short answer: very bad.

The longer answer: that site has become notorious around here, due to amount of newbies that end up posting topics here about problems that are the direct result of bad practices they learned from the tutorials. The biggest problem with that site (IMO) is that it doesn't teach you how to properly check return values of Direct3D/D3DX functions and extract information from them for debugging.

I like the site. I often refer back to it when I have forgotten something.

I am not sure what others have had to say about it. The thing I like about it is that it places the relevant code in an in-line fashion to get the point across.

It is really upto the end user what they do with the code after that, often wrapping things up in a class.

In my opinion the way these tutorials are laid out is ideal. Too often we have peoples classes imposed on us and are told to use them. This does not help us in understanding how any of these funtions etc work.

Thumbs up for the author of 'directxtutorial.com'.

FWIW, the site helped me get DirectX going, code up a few small (weak) games, and generally have a lot of fun. Thats a lot more then almost any free tutorial can claim and so I hate to complain about it. I paid for the content after going through the free stuff, and found it fairly helpful, easy to extend, and easy to understand. He restructures a lot of the code in the free stuff so that your not dealing w/ windows + gamelogic + d3d all in the same block, goes through a pong tutorial, tetris, and then throws in error handling at the very end.

That said, I've read up on how and why its dangerous, and have to agree. There is some bad stuff going on in the code that you def would not want in large, long term projects. Thats not a reason to dismiss the site completely, just realize the code is a start point, not production stuff. However, this is probably true of any tutorial on the web.

The dude knows how to write and explain things, and thats no small feat. I'd suggest go to the site, run his code to the ground until you feel relatively comfortable with the stuff. Then, if you want to continue, lay down some cash for a good book ( I am really enjoying Frank Luna's DirectX9 Shader approach).



[Edited by - MooseHuffer on January 1, 2009 11:12:48 PM]

As what others think, I believe that it won't teach you everything and there are some bad practices. However, it is a very good reference site. If I forget something about DirectX, I go back to it. It's very good for showing you how to set up things and how certain features of DirectX work. If you were to try and code an engine, which I currently am, solely based on what you learn from that site, you would not get very far. It is a very good supplement, but that is all.

Lo$t

Quote:

Original post by MooseHuffer The dude knows how to write and explain things, and thats no small feat. I'd suggest go to the site, run his code to the ground until you feel relatively comfortable with the stuff. Then, if you want to continue, lay down some cash for a good book ( I am really enjoying Frank Luna's DirectX9 Shader approach).

This is exactly the path I have taken too. I have this book also and the DX10 one that he recently released.

The major problem I have is that the tutorials don't even mention the things you need to do. None of the code from that site will work on even slightly obscure video cards (That don't do 32-bit display modes for instance), when it goes wrong it'll just crash without any help about why it crashed ("The application has encountered a problem and will be terminated"), and there's lots of little things - such as every tutorial has graphical glitches in it, due to the author not telling people that the backbuffer needs to be the same size as the client area, not window area.
That, and the horrific way of getting a "fixed" frame rate - using GetTickCount() is only accurate to around 16ms, measuring 10 or 25ms (I forget which it uses) is horribly wrong.

I can guarantee you that if you use that website, you'll run into problems with the code he teaches as soon as you start trying your app out on different hardware.
I'm in the process of writing some tutorials of my own, although only the first one is complete, it's very basic and is probably a bit verbose for your average beginner.

Nice work on the tutorial Evil Steve. It takes a huge amount of time and commitment to take on something like that. :)

Quote:

Original post by MJP The biggest problem with that site (IMO) is that it doesn't teach you how to properly check return values of Direct3D/D3DX functions and extract information from them for debugging.

I know I'm going to post something apparently unpopular, but I share your POV.

In principle I'm against suggesting stuff like "always check return values". To just check return values is useless/potentially harmful. I know where this adversion comes from: exception handling.

My point is: some exceptions/errors are IMPOSSIBLE TO HANDLE.

Writing "Hey I got a problem here!" to a file/screen/vs output is not handling an error/excepion. It's logging.

Since some things are impossible to handle, it is pointless to try ho handle them. You'll always end up in noncoherent state. The myth is "by exception handling/error codes check you can write code which doesn't crash". This is a double mistake as:
- people could think about checking error codes as a solution while they are mostly a TOOL
- people could think their goal is to write code that never crashes, which is not what they really need/want

I've seen people lost trying to prevent any possible crash, checking everything everywhere, switching missing resources with default ones (!!!!)! That's as bad as not checking any error code.. probably it's even worse!

In a typical hobbyst scenario you have one person working on a small amount of code. This code is supposed to produce something which just *works*: being a game, a screensaver, a demo.

In this case it's easy to launch the app from you favourite IDE, then automatically see what's going on as the debugger will stop when (and where) the error/exception occurred. To say "Houston, we have a problem!" doesn't add any kind of information.

As the codebase gets bigger, some dependencies can become non trivial: the points where the problem arises and where the debugger stops are in different places, at different times.

I see this as a strong point AGAINST only checking return codes/pretend to write uncrashable code/think about return codes as a solution.

Suppose you have 300+ textures to load. One of those is missing, you correctly check return codes and the app loads and starts perfectly, despite a missing texture. After 10 minutes playing your game, you find an uberweapon. When you fire your uberweapon, for apprently unknown reasons, the app crashes. Or you just can't see your shoot. The problem is the missing texture should be drawn when you have uberweapon and shoot, but you couldn't load it because it's missing. 10 minutes ago.

Counterintuitively, it would have been better NOT to check return codes and let the application crash. In that case the app would have crashed exactly where the problem lied. Now you have a problem but you don't have a clue about where it comes from. That's why I say that by suggesting to check return codes to prevent an app crashing, people could misunderstand your point and write potentially harmful code.

This is not a problem about return codes, of course, it's about (lack of proper) logging.

My POV is simple: you need logging, use return codes to help you log errors/warnings. The important part isn't the return code, it's logging. The return code is a TOOL you should use to improve your logger, which is the SOLUTION to the following PROBLEM: "How do I know where and when something unexpected happened?".

The problem is about context. If a model/level/texture/sound is missing, I find acceptable that my app can expose non coherent behaviour and in some cases horribly crash. If my shader folder is missing to show a black screen is not better than a crash. Because it's a game/engine/app/screensaver/demo, not a fail-safe software for a nuclear power plant. If the screen is black the game is non functional. From an user POV, it's the same to see a black screen or a dialogue saying an error occurred.

If my shader folder is missing, I don't really care about the specific return code, or my application behaviour. I care about writing somewhere a list of "unable to load shader xxx" strings. Once you have a base logger, you can use error codes to identify if the file is missing, if there's a syntax error in shader code, if the board doesn't support the target shader model, etc.

Error codes are the SOLUTION when, like Evil Steve pointed out, you can actually do something to handle an error/exception. It's the case of texture formats, video mode, resource creation flags, etc. In that case it is mandatory to correctly check return codes as you could probably do something to make your application flawlessly work despite that "exception/error".

I think what DirectXTutorial.com doesn't teach is the following: good code practices allow you to easily identify where and when a potential error occurred. This is achieved by logging unexpected events. Error codes help you doing it.

IMHO to blindly check error codes just because "it's the way it's meant to be done(tm)" is as bad as DirectXTutorial.com's code.

Quote:

Original post by undead [Lots of text]

I agree with this; It's usually a good idea to check the return values for functions that will cause a crash if you don't notice the function fails (E.g. most Create*() calls). I personally don't bother checking the return value for functions like SetRenderState(), because the application will continue to function if it fails (And the debug runtimes will tell me when it fails anyway - in a release app I don't care as much / at all).

On the missing assets front (And going slightly off-topic), my personal opinion is that it's better to use some sort of placeholder asset than for the application to crash - this is what we do at work so that having a missing texture won't crash the game for everyone - an error is logged and the texture isn't used at render time. On a 1 person project it may be preferable to crash or bail in some way instead, since you don't need to worry about the application running for anyone else.

Quote:

Original post by Evil Steve On the missing assets front (And going slightly off-topic), my personal opinion is that it's better to use some sort of placeholder asset than for the application to crash - this is what we do at work so that having a missing texture won't crash the game for everyone - an error is logged and the texture isn't used at render time. On a 1 person project it may be preferable to crash or bail in some way instead, since you don't need to worry about the application running for anyone else.

We are OT.. I'll try to be concise. :)

My problem with placeholders is they should change according to their semantics.
If a normal map is missing, your placeholder should be a flat normal map. If a lightmap is missing your placeholder should be a white texture. My material system doesn't crash if a texture is missing, but after loading I always ask the materials to validate themselves. The process of "autovalidation" allows the material to ask for placeholder textures in order to "fill holes". Unluckly that implies to load many different placeholder assets, which is a dangerous solution as sometimes a texture could be missing but you don't notice it. You should check the logfile, but if the artist thinks everything's fine, he'll probably don't do that. :(

In case of a missing normal map which solution do you prefer? To use a 1x1 white texture so that rendering is clearly incorrect or to use a proper flat normal map texture and expect artists to check the logfile often?

Quote:

Original post by Evil Steve On the missing assets front (And going slightly off-topic), my personal opinion is that it's better to use some sort of placeholder asset than for the application to crash - this is what we do at work so that having a missing texture won't crash the game for everyone - an error is logged and the texture isn't used at render time. On a 1 person project it may be preferable to crash or bail in some way instead, since you don't need to worry about the application running for anyone else.

I reread an old article recently after it was picked up by industry broadcast and thought it was apt for what you are saying steve.
http://www.gamasutra.com/features/20041013/fristrom_01.shtml

Quote:

One of the oldest tools in game development for eliminating a dependency is the placeholder asset. This is something film makers don't get to use: if a prop isn't ready for a scene, they can't film. Granted, if our prop isn't ready, we can't ship - that dependency will never be eliminated. But it's nice to know we can get useful work done in the meantime. There's a right way and a wrong way to use placeholders. Let's take sounds, for example. You've just coded or scripted a feature where a badguy shoots a ray gun at the hero, and you need a sound before you playtest. There happens to be a sound similar to a raygun in your game already, when your hero runs into an electric fence, called "electric_fence_001.wav", so you just have your script use that sound file, and it's ready for playtest. That's the wrong way. If you do it that way, when your sound engineer finally makes "ray_gun_001.wav", you have to go back into the script and change it. You've introduced a dependency between the sound engineer and you. The right way is to copy the sound file, rename it (you get bonus points for asking the sound czar what the name should be - although this does introduce another small dependency, it's worth it so the sound guys can keep track of all the sound assets), and check it in. That's the sound file you use in your script. Then, the sound engineer can record the sound at their leisure, and it doesn't have to go back to you for the final pass. ... Textures. We like to stamp the word "PLACEHOLDER" on our placeholder textures, so angry executives don't ring us up and ask us why our game looks crappy. (Another, more obscure problem occurs when we replace the placeholder texture with the final one, and those same executives rave: "We liked the old one better!" For some reason, this is a more pernicious problem with textures than with other kinds of placeholder assets.)

Hmm, I just came back from Evil Steve's tutorial on initializing DirectX... the biggest problem is the fact that all the code comes in big batches instead of being broken down. The reason that is bad is mainly due to a phsychological factor; basicly it scares 'noobies' and could throw 'em off programming or just make them think that DirectX is even harder than they previously thought. Nevertheless it seems to be a great tutorial, just try to break it down a little next time.

Getting back to the main subject of this thread... I personally think that DirectXTutorial is a great site to learn of I even have my own account there, although I do agree that it needs some to teach its users some error handling techniques, but then again when your just learning simple aspects you do not want it to seem like hell with all that error handling, but still when you learn that's when you pick up your habits. The best thing to do I believe would be to have one tutorial aimed at error handling and then to supply an extra file at the end of every tutorial that is the same as 'main.cpp' but includes error handling, that way you could compare both and see what you do/don't need... or something along those lines.

Fissure.

Evil Steve... I just did a little research on you and it seems that your some kind of serious pro. Do you mind me asking how you learned so much? Did you take classes?

Fissure.

Quote:

Original post by GameFissure Hmm, I just came back from Evil Steve's tutorial on initializing DirectX... the biggest problem is the fact that all the code comes in big batches instead of being broken down. The reason that is bad is mainly due to a phsychological factor; basicly it scares 'noobies' and could throw 'em off programming or just make them think that DirectX is even harder than they previously thought. Nevertheless it seems to be a great tutorial, just try to break it down a little next time.

I completely agree. I also think it's a bit too "wordy", I need to revisit it and break it down into smaller chunks. I may even break the first tutorial into two, one for just setting up the window, and one for setting up D3D.

Quote:

Original post by GameFissure Getting back to the main subject of this thread... I personally think that DirectXTutorial is a great site to learn of I even have my own account there, although I do agree that it needs some to teach its users some error handling techniques, but then again when your just learning simple aspects you do not want it to seem like hell with all that error handling, but still when you learn that's when you pick up your habits. The best thing to do I believe would be to have one tutorial aimed at error handling and then to supply an extra file at the end of every tutorial that is the same as 'main.cpp' but includes error handling, that way you could compare both and see what you do/don't need... or something along those lines.

The error handling is the most important part, and I believe that you need it as part of a tutorial, even if it sacrifices some readability. If you don't do any error handling, then any errors will cause the application to crash. On a development machine, you'll get shown the line of the error in the debugger, but if you try running it elsewhere - like sending the .exe to a friend, then you'll just get a "The application has encountered an error and needs to be closed." message with no indication of where the error is.
I'm thinking of changing the source code you see inline in the tutorial so it'll look like:

hResult = SomeFunction();if(FAILED(hResult)){   // Handle error   return false;}

and then leave the full error handling in the downloadable code.

Quote:

Original post by GameFissure Evil Steve... I just did a little research on you and it seems that your some kind of serious pro. Do you mind me asking how you learned so much? Did you take classes?

I develop games for a living, yes (Nintendo DS and Wii). I learnt C++ just from reading tutorials on the Internet, and from a fairly crap book ("Teach Yourself C++ in 21 days"). Everything else is self taught. I started tinkering with Quake C, making some very simple mods for Quake, then played around with DJGPP and Allegro doing text based stuff. Then I started getting in to DirectX, around DX5 or DX6 and made the mistake of trying to jump in a the deep end and do things like making a 3D desktop manager, when I didn't have any idea about 3D maths.
In all, I've been learning C++ since I was about 13 or so, and DirectX since I was 14 or 15, so around 10-12 years in total.

Quote(Evil Steve): I completely agree. I also think it's a bit too "wordy", I need to revisit it and break it down into smaller chunks. I may even break the first tutorial into two, one for just setting up the window, and one for setting up D3D.

Well don't worry about it too much... it is your first tutorial right? Give it time you'll learn. I really do think it is a good tutorial though. Breaking it up? I guess that makes sense since both of them are in some ways different, for example the first part simply focuses on Win32 while the second DirectX.

Quote: I develop games for a living, yes (Nintendo DS and Wii). I learnt C++ just from reading tutorials on the Internet, and from a fairly crap book ("Teach Yourself C++ in 21 days"). Everything else is self taught. I started tinkering with Quake C, making some very simple mods for Quake, then played around with DJGPP and Allegro doing text based stuff. Then I started getting in to DirectX, around DX5 or DX6 and made the mistake of trying to jump in a the deep end and do things like making a 3D desktop manager, when I didn't have any idea about 3D maths.
In all, I've been learning C++ since I was about 13 or so, and DirectX since I was 14 or 15, so around 10-12 years in total.

Nice, but that book's title has always been a bit... shitty. I've yet to see anyone who has 'properly' learned all of C++ in under a month. It just ain't that simple. Oh that makes sense, you actually have a job in programming to... hmm, I know this could sound a little rude but does a job involved in programming pay a lot? because when I get older I'd like to be a full time programmer and my dads tryin' to talk me out of it because he thinks it just isn't worth it.

The reason I think DirectXTutorial isn't to bad of a site is because almost every tutorial misses something out... some of them don't have error handling while other fail to describe some basic details almost entirely. That's why I rate sites out of how much information they do have rather then what they don't. For example DirectXTutorial misses out error handling... and that's about it I think, but the site does have other qualities that I like that most sites don't have, for example a good description on functions and suprisingly its really enjoyable(the way the author describes things and makes it seem a little more easier). Now when you compare DirectXTutorial with other sites you should see that it is one of the more complete tutorials but just misses out error handling, but don't forget it isn't complete yet either or that the site is still being updated.

Fissure.

Quote:

Original post by GameFissure The reason that is bad is mainly due to a phsychological factor; basicly it scares 'noobies' and could throw 'em off programming....

I agree that, in general, tutorials should be broken down into sections.

The method I use is to do the minimal to get the job done and in later tutorials go deep into error handling, best practises etc.

This way the potential 'noob' wont get scared off (as easily) and keeps them excited about what they have just achieved. I think they would appreciate it more in the long run. That's just me though...

Oh my friend that isn't just you :). Now that I think about it, when I read tutorials from DirectXTutorial I do feel excited at the end of every tutorial because of:

A) The way author/programmer of the site made it sound so easy(most the time, haha).
B) Simply because the tutorial was short AND I did managed to get to the end of it without a hassle... which made programming seem easy(which is what gives people hope or makes them what to go on).

Fissure.

Quote:

Original post by GameFissure hmm, I know this could sound a little rude but does a job involved in programming pay a lot? because when I get older I'd like to be a full time programmer and my dads tryin' to talk me out of it because he thinks it just isn't worth it.

Games programmers get a fairly high salary, the exact amount depends on your experience, location, and the studio you work for. There's been a few posts in the lounge about salaries, you might be able to find them via Google. IMO, it's certainly worth doing, and most importantly it's fun [smile]

Haha, yeah good to know :). Atleast now I know it won't be to much of a problem when it comes to payment :D.