So I really liked his website it's really easy to read and they are structured good for the eyes. Anyways so I googled "Directxtutorial.com review" and it came up with a couple results from like 2004? about how bad his code is and the bad practices he teaches. Infact I like his website so much that I was think about buying his DirectX Premium thing which includes making a like 3 different game engines(Mostly just building on the engine from like 2D to 3D). And he's about to come out with a multiplayer tutorial. So the people that HAVE done his tutorials what do you think about them? Are they good for people that have never touched a API other then win32 much less DirectX? Does it teach bad practices and have bad code? Is it easy to understand? Thanks in advance!

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.