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)

- 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

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.

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.

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

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

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.

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.