# Windows Game Programming for Dummies

This topic is 4324 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I recently got this book off of ebay, is it a good book to start with?

##### Share on other sites
I've never read it but from looking at amazon it looks a little dated. 1998 was a long time ago and DirectDraw is kinda obselete.

With that said, It's probably perfectly usable for starting with.

And isn't this usually the kind of question you ask before purchasing something :) ?

##### Share on other sites
My opinion: It's going to teach you bad habits that'll take a long time to shake.

##### Share on other sites
I have it. It is a little dated, so you should just try to look at the concepts (BOBs, game loop, etc), don't try to memorize the DirectDraw and GDI stuff. The book kind of ends up being an API reference. It's almost as if the author is reading through the docs and writing up the book lol. Also look at the marketing and physics sections.

It's basically the same as "Game Programming Gurus" which a lot of people recommend. If you have the last edition, it uses dinput8 for input.

But the future is 3D hardware and the APIs that tap that hardware, so you should not feel the need to start with DDraw, start with SDL because it is easier and cross-platform.

Edit: there are some *really* funny comments about "C++ for C programmers" and "Windows for DOS programmers" (that shows what time period it is from)

##### Share on other sites
It's alright, I have it. It's not good for beginners, Andre' LaMothe is an excellent programmer but he's horrible at explaining things to beginners, but it does state in the beginning that you should know at least C. I recommend you get "Beginning C++ Game Programming" by Michael Dawson, it's great for beginners and VERY simple, it's the book I got to learn programming.

Good luck.

##### Share on other sites
Get rid of it. It is the single worthless programming book in my library. I'd burn it, but that seems like it would show too much respect.

##### Share on other sites
A few thoughts:

It was a pretty decent book a few years ago. It gets you to the point where you can make games using his engine. However, as stated before, it is dated (no one uses directdraw anymore), and can get you in some bad programming habits (which I recently had to unlearn).

If you aren't familiar with c/c++ I recommend the Beginning C++ Programming book by Dawson, it's a great intro to the c++ language and basic game programming theories.

If you already know some c/c++ and want to start making games, I suggest Beginning Game Programming by Johnathan Harbor. It is similar to Game programming for dummies but uses DirectX 9.0b with Direct3d and the sprite class, which is the current preferred method of 2d games.

I wouldn't throw away Lamothe's book, you can still learn quite a bit from it (there are many nontechnical parts), and i'd rather create games in an old API then not create games at all.

Good luck!

##### Share on other sites
"Bad habits"? Could any of you expand what these might be? Are you talking about using DirectDraw, or are there more fundamental concerns?

Thanks!

##### Share on other sites
Quote:
 Original post by Silverwings"Bad habits"? Could any of you expand what these might be? Are you talking about using DirectDraw, or are there more fundamental concerns?Thanks!

Sure. First off, everything is procedural, the book is really done in C. That's not that big of a deal but OOP is pretty much taking over and I've had a hard time making the switch.

He uses a lot of #defines in the book instead of const's. And he does a lot of very low level programming (sometimes even in assembly!).

There are a lot of other things, honestly I can't name them all. I just know from other people looking at my code and from reading other c++ books that a lot of the stuff that I was doing (most of which i picked up from Lamothe), was bad practice.

I am a big fan of Lamothe, I think a lot of people needlessly bash his books. But given the choice, I would recommend more up to date books. Also, if i could start all over, I would start by learning OOP.

##### Share on other sites
Quote:
Original post by ChurchSkiz
Quote:
 Original post by Silverwings"Bad habits"? Could any of you expand what these might be? Are you talking about using DirectDraw, or are there more fundamental concerns?Thanks!

Sure. First off, everything is procedural, the book is really done in C. That's not that big of a deal but OOP is pretty much taking over and I've had a hard time making the switch.

He uses a lot of #defines in the book instead of const's. And he does a lot of very low level programming (sometimes even in assembly!).

There are a lot of other things, honestly I can't name them all. I just know from other people looking at my code and from reading other c++ books that a lot of the stuff that I was doing (most of which i picked up from Lamothe), was bad practice.

I am a big fan of Lamothe, I think a lot of people needlessly bash his books. But given the choice, I would recommend more up to date books. Also, if i could start all over, I would start by learning OOP.

Everything you just mentioned is not a bad habit. It's the way the C language works (well except for assembly. but learning or using assembly is not bad thing(TM)).

The only thing that can be considered "bad" is the use of #defines, but since const didn't become standard in C until C99, people are going to just have to deal with that.

##### Share on other sites
So maybe it's more of "old" habits rather than "bad"? I can understand not wanting to get stuck in the past (which is why I wish the industry wasn't so slow to adopt better technologies and languages), but isn't there some call for understanding the "older" coding schemes?

Then again, I started with OOP, so maybe it's easier to understand that first and then look at how it "used to work".

##### Share on other sites
Quote:
 Original post by SilverwingsSo maybe it's more of "old" habits rather than "bad"? I can understand not wanting to get stuck in the past (which is why I wish the industry wasn't so slow to adopt better technologies and languages), but isn't there some call for understanding the "older" coding schemes?Then again, I started with OOP, so maybe it's easier to understand that first and then look at how it "used to work".

Yes exactly. The reason I consider the habits I learned "bad" is because I thought I was using c++. It's a beginner book so when you use a c++ compiler you are thinking "hey I am learning c++!" Then as you are making the switch you realize that a lot of the stuff you have been doing is...nonstandard. So no they may not be incorrect habits, but clearly the world of gamedev has moved to C++ and probably OOP C++, so it would make more sense to a beginner to get into those habits as opposed to learning something that has to be unlearned later on.

However, I also feel strongly that it is better to learn an older language and an older API then not learning anything at all. So if WGPFD is the only way you can make games, use the GPDumb engine!

##### Share on other sites
Quote:
 Original post by SilverwingsSo maybe it's more of "old" habits rather than "bad"? I can understand not wanting to get stuck in the past (which is why I wish the industry wasn't so slow to adopt better technologies and languages), but isn't there some call for understanding the "older" coding schemes?Then again, I started with OOP, so maybe it's easier to understand that first and then look at how it "used to work".

well i started procedural. which is why mostly whenever is get to the point of doing 3D i'll be using OGL instead of D3D (initially). so sometimes learning something new (or as you guys put it: unlearning the old) is a chore.

[Edited by - Alpha_ProgDes on April 18, 2006 1:06:19 PM]

##### Share on other sites
Quote:
Original post by ChurchSkiz
Quote:
 Original post by SilverwingsSo maybe it's more of "old" habits rather than "bad"? I can understand not wanting to get stuck in the past (which is why I wish the industry wasn't so slow to adopt better technologies and languages), but isn't there some call for understanding the "older" coding schemes?Then again, I started with OOP, so maybe it's easier to understand that first and then look at how it "used to work".

Yes exactly.

??
Quote:
 The reason I consider the habits I learned "bad" is because I thought I was using c++.

if (noob)    language = c == c++;else if (!noob)   language = c != c++;
[smile]
Quote:
 It's a beginner book so when you use a c++ compiler you are thinking "hey I am learning c++!"

Not when the book, explicitly tells you that you'll be using C and that the C++ compiler can be used for C and C++.
Quote:
 Then as you are making the switch you realize that a lot of the stuff you have been doing is...nonstandard.

I take it the '...' means you couldn't find the appropriate word or phrase. So instead of "nonstandard", let's try "not appropriate with the current programmng paradigm".
Quote:
 So no they may not be incorrect habits, but clearly the world of gamedev has moved to C++ and probably OOP C++,

which world? between mobile games, GBA, PSP, and DS the world of gamedev still uses C. also if you're just using procedural C, there are really a handful of GOOD reason to actually use C++ (STL being one of them).
Quote:
 so it would make more sense to a beginner to get into those habits as opposed to learning something that has to be unlearned later on.

i think we should not take the process of going from procedural programming to OOP as unlearning. no more than going from C++ to Lisp.
Quote:
 However, I also feel strongly that it is better to learn an older language and an older API then not learning anything at all. So if WGPFD is the only way you can make games...

I agree there. Just be sure to learn what he's doing and more importantly way he's doing it. Believe me, you'll get about 100 posts showing various BETTER ways to do some of the things he demonstrates in that book (and still be using the C language to boot).

##### Share on other sites
So, a so-so reveiw. Should have asked before buying. Well, at least it was only 12 bucks WITH shipping(buy it now was 7). It'll help though. thank you for the reveiw. can't wait for it though.

##### Share on other sites
Quote:
 Original post by Alpha_ProgDesif (noob) language = c == c++;else if (!noob) language = c != c++;

So, basically:
language = noob;
?

What exactly were you trying to say? That, for a "noob," C and C++ are equivalent? In that case, you're dead wrong (plus, operator == and operator != perform tests returning booleans, and are not statements of equivalence).

C and C++ are distinct languages with certain similarities. They are both exceptionally valuable, and both exceptionally valid for game development. C++, being a larger language, is capable of expressing a wider range of constructs and leveraging more programming paradigms. Neither is representative of an "old" or "new" way of programming. Well, actually, they're both old.

##### Share on other sites
Quote:
Original post by Oluseyi
Quote:
 Original post by Alpha_ProgDesif (noob) language = c == c++;else if (!noob) language = c != c++;

So, basically:
language = noob;
?

What exactly were you trying to say? That, for a "noob," C and C++ are equivalent? In that case, you're dead wrong (plus, operator == and operator != perform tests returning booleans, and are not statements of equivalence).

C and C++ are distinct languages with certain similarities. They are both exceptionally valuable, and both exceptionally valid for game development. C++, being a larger language, is capable of expressing a wider range of constructs and leveraging more programming paradigms. Neither is representative of an "old" or "new" way of programming. Well, actually, they're both old.

He's saying the newbies tend to think C and C++ are the same language. I can tell you that a lot of the students in my advanced java class think so.

##### Share on other sites
It's been a long time since I read the book (and in all honesty, it's what I got a lot of my foundation in), but here are some of the things I recall as being bad (some of these may not be entirely accurate, but as far as I can remember, they're true):

(1)Overuse of globals. The theme of the book seemed to be, "if more than one function should use a variable, make it a global."
(2)Emphasis of optimization over solid design. If this sacrificed readability/maintainability, well then, that's a sacrifice he was willing to make.
(3)Reinventing the wheel. Some of the content can be covered in a basic algorithms book, - probably better.
(4)VERY outdated. DirectDraw is deprecated. All the other Directs have changed significantly (if I recall properly, I don't even think DirectSound even resembles what the book uses). Some of the optimization information is now practically irrelevant.

And here's what I think is alright:
If you regard the book as a manual on how to do certain things that you're unfamiliar with, then alright. It really eases entry into some Windows concepts and some of the 2D foundations. It is not, however, a particularly good book on design/coding practices.

Cheers,
--Brian

##### Share on other sites
Quote:
Original post by Oluseyi
Quote:
 Original post by Alpha_ProgDesif (noob) language = c == c++;else if (!noob) language = c != c++;

So, basically:
language = noob;
?

What exactly were you trying to say? That, for a "noob," C and C++ are equivalent?

Quote:
 Original post by Lazy FooHe's saying the newbies tend to think C and C++ are the same language.

Exactly. Thanks Lazy Foo. Sorry if I didn't make that clear, Oluseyi.

Quote:
 Original post by NairbIt's been a long time since I read the book (and in all honesty, it's what I got a lot of my foundation in), but here are some of the things I recall as being bad (some of these may not be entirely accurate, but as far as I can remember, they're true):(1)Overuse of globals. The theme of the book seemed to be, "if more than one function should use a variable, make it a global."

He definitely made use of A LOT of globals. The approach I like better is the one from the Tetris tutorial here on GameDev. It's cleaner.
Quote:
 (2)Emphasis of optimization over solid design. If this sacrificed readability/maintainability, well then, that's a sacrifice he was willing to make.

That was probably my biggest complaint of the book. Even though the it was "for Dummies", I had a hard time following where he got formulas and how his algorithms even worked. I guess you need the unabridged version of the book to know that stuff.
Quote:
 (3)Reinventing the wheel. Some of the content can be covered in a basic algorithms book, - probably better.

I haven't read the book in a while, but which sections do you speak of?
Quote:
 (4)VERY outdated. DirectDraw is deprecated. All the other Directs have changed significantly (if I recall properly, I don't even think DirectSound even resembles what the book uses). Some of the optimization information is now practically irrelevant.

Personally, I don't like the DDraw is deprecated reasoning. To me, it would be the equivalent of saying don't use SDL (which is a layer over DDraw 5). People can still benefit over the traditional 2D way of programming. GBA and mobile games for instance.
Quote:
 And here's what I think is alright:If you regard the book as a manual on how to do certain things that you're unfamiliar with, then alright. It really eases entry into some Windows concepts and some of the 2D foundations. It is not, however, a particularly good book on design/coding practices.

I agree with the overall statement, but I don't think it was ever presented as a good design/coding book [smile]

[Edited by - Alpha_ProgDes on April 19, 2006 7:31:30 AM]