I put this book in the same league as all the other "game programming" books out there: Nice attempt, but sorely lacking in any real content.

I got a lot of flak on #gamedev for saying this, but the guy is a total moron. Like you pointed out earlier, this is one person whose example you should NOT follow. His code is atrocious, his design abominable, and his writing style pretty damn aggravating.

MSN

If you wanna know my thoughts, I find the book a waste of time. After reading it a few times, I don't find myself any closer to making a RTS game.

He throws code at you and expect you the learn from it. If I wanted to do that, there are plently of free engines of the net. Not to mention his engine is full of bugs.

Frankly, I don't see the point of putting a class on top of directdraw. He does everything in classes, which makes things terribly hard to follow. Also the CD included used only 5 MB. Give me some examples and use the remaining 600+ MBs.

As for your question of bltting, I don't think surface are often stored in video memory because not everybody has a > 8MB card. IMO, surfaces are stored in system memory, manipulated in an system memory buffer, and then copied (blt) to the video memory surface. The only time I think when system surface is moved is when the swap file kicks in.(in that case, get more ram)

I havent read the book, so I cant comment on the material, but there are several comments in this thread that strike me as wrong (for most people):

- Building a wrapper class over DirectX or any other type of low-level system functions is totally critical to building portable or reuseable code. Now it doesnt matter what system you use or if DirectX totally changes, the only thing that will change is your encapsulated wrapper routines, not your game code. No global search-and-replace'ing of function names and all the other bad bad stuff that goes along with this. This also creates greater readability in code, as you can name things properly, and not like DDOpenDriverEx().

- As for using classes, they may not be quite as easy to read as procedural code in a book because the different things are spaced out more, but that is proper design (I cant vouch for his design, only that encapsulation is the way to go). If you are doing any project-of-size and you arent encapsulating your routines and data, you are probably going to have a hard time of it at the end, or if anything changes.

-Geoff

Yeah, I have to agree with the previous posts. The book is very poorly organized -- Like why switch gears completely while discussing targa files to suddenly introduce a string class??? WTF?? Another problem is that he explains so little of the code that one might actually use to create an RTS and wastes time explaining DX stuff and then whining about VC++ or some other thing about MS he dislikes. I was also disappointed there were no samples -- well other than the alphabet editor which doesn't run properly on my box at any bit depth and a simple iso-tile example. As far as the classes go -- I think this is the best way to design code for portability and maintanence.

L8R
Scruffy

Hey Scruffy, glad to see another extreme programmer has read that book.

My opinion is: If you are serious about game programming, add it to your library.
But if you are casual or a beginer, skip it.

Like Scruffy, I found myself saying WTF a lot. He changes gears, way to much. There are times he doesn't explain his code at all.
There are other times he throws code at you, then explains what that code does in subsequent chapters(Too late, because I had to spend a lot of time figuring out what that code did.)

I feel the two biggest problems with this book are:
1) He doesn't really teach the user! He throws code at you. He talks about interesting design issues, but does not cover how to code them. He never really ties most of the books material togeather.

2) There is little in the way of example programs or snippits of code. Major draw back! I always like to see example code of the material, with minimal fuss.
To use this material, requires a lot of extra effort.

In general, I'm glad I bought the book.
But... I found much to be desired.
That's too bad, because I had such high hopes.

Oh, I definitely agree that encapsulating DirectX is a good idea. I just don't like his class structure for some things. Like I sadi before, why stick the WndProc in the DirectDraw class? This just doesn't seem to make any logical sense.

All in all, I got alot of good insite from the book, I just didn't like his style, and don't plan on using his engine for anything. I prefer my own design, for me it seems a little more logical to have a System class with all of the Windows specific stuff and a seperate DirectDraw class for managaing DirectDraw.

The book is pretty much garbage if you ask me. I agree with encapsulating a drawing manager and everything else, but he'll say one paragraph about what he wants to do, drop about 5 pages of code and state that what he's doing should be obvious. Honestly, if anyone needs a book to explain what Mickey explains here, they don't know anything about RTS games and shouldn't be programming one.
To answer a couple of questions:
The reason for his own version of the blit is so that he can run RLE sprites (I think they're RLE, I don't remember) and accomplish transparency with relative ease. The reason some people avoid the blit is that it is somewhat expensive to lock/unlock the surfaces, especially when you do it 400 times. I say just use blt; the tile engine I made ran iso tiles at 800x600x16 and ran at about 35 fps on a shitty system, and that was redrawing the screen every frame.
Someone also asked about where surfaces are stored. In DX 6 (I don't know about 7) they default to Video Mem unless you specify system memory.

I have yet to see a really good game programming book (except WGPFD if you're a beginner).

I say spend your 50-60 bucks on Dungeon Keeper2 now, and wait for
a well-known publisher to write about this popular subject of RTS games.
This is the only book I've seen specifically tackling this subject, and I
am sure there will be better, well-written books to come in the future.
I don't want to say that programmers are bad writers, but this one is
certainly no exception.

And, I mean, come on, every game programming publisher on the face of the
planet has jammed-packed their CDs with the latest shareware version of PSP,
the latest DirectX SDK, and a crap load of demos. A CD stores 650 MB, for
crying out loud, use it! I don't care if anyone accuses me of paying too much
attention to the CD rather than the book. In my opinion, CD's are the dessert,
and the book is the main course, and I like eating my dessert first.

Reaver

I also read the book.

You can't learn his classes. It will take to long time.

I don't think wrapping is a bad idea. But I agree that wrapping the win loop inside DX.

But if you are going to make a wrapper make it yourself or you won't learn anything and won't be able to modify it.

That he makes a own blt function is because he uses plain memory and not surfaces.

If you look at the book it is not a book for beginners. The book is more for people that can make games and does big projects.

I prefer books of LaMothe.

Hmmm. Aparently most people here misunderstood me. I didn't mean to give the impression that I didn't find the book useful. I just wanted to say, and find out if others agreed, that Mickey's style (code style, class design & structure) leaves alot to be desired.

I did however find the code to be very useful. I personally find that tutorials can only take you so far. If the book held your hand throughout the entire game implementation, we'd have alot of games that look the same, no? Anyways, I do agree that he should of put more stuff on the CD, such as binaries of the samples.

All in all, I bought the book because I was interested in the design that goes into a game engine, not the code. There are thousands of books that cover DX code better and more in-depth than this one. But, this is the first one of seen that actually covered the whole (more or less) process.

I guess what I'm really interested in is seeing how the whole thing fits together.