Customer Reviews

.NET Game Programming with DirectX 9.0

5 star:		(1)
4 star:		(2)
3 star:		(4)
2 star:		(2)
1 star:		(10)

 

 

If you want to read something of 3D forget this book.
This book cover 2D programming.
There are a chapter talking about 3D (basic concepts).

I've gotten about halfway through this book in the past two weeks and I feel like I'm learning enough where I can start writing my own simple games once I'm done with it. I started from knowing VB.net pretty well (for business apps), but not knowing the first thing about DirectX or Game Programming. That said, the editing of the code samples in this book is atrocious. The code samples in the book almost never match those on the CD and you have to figure out "what they mean" most of the time, debugging stuff yourself. Another dumb thing is that whoever wrote the code doesn't know how to use arrays, and always Dims a 4 element array as MyArray(4) instead of (3). Lastly, they don't tell you to enable "key preview" on your forms, so if you didn't know to do that from reading it in another .Net book, the keyboard handler functions would never work for you. Bottom line is that this book can help you learn elementary game programming in VB.net, as long as you know the language reasonably well (decent VB6 would be enough), and you won't get too frustrated trying to reconcile the code in the book and on the CD. It's too bad: If they had gotten their act together, this could have been a 5 star book.

I've been buying books from Amazon for years now, and not once have I actually written a review about one. However, this book is so terrible that I felt compelled to send out a warning to all those considering this book.

The whole time I was reading it, the only thing I could think of was all of the naive programmers out there who might just be learning and not realize all of the bad practices this book is advising. Not to mention a complete misunderstanding of how Object Oriented Programming is to be used. According to Mr. Lobao, EVERYTHING derives from a game engine - a sprite, a tile, a font, etc...

I can't believe a book like this ever made it to press. I also find it laughable that the foreward is written by a Microsoft MVP whose focus is in ADO.NET, and the technical reviewer specializes in data warehousing and internet solutions. Um, since this is a book about GAME programming, shouldn't someone who actually knows a bit about GAME programming actually review the thing?

I should have waited until there was reviews on this book before I bought it. Im trying to get the hang of multiplayer game programming in a 3D environment and the introductional text to this book sounded very promising. When I got it the book I got very disappointed when I discoved that it almost only covered 2d programming and only had one chapter on 3d and that was very basic stuff. The topic multiplayer only covered peer2peer technology and almost nothing on client-server which is more interesting when programming multiplayer for more then 4 connected players.
For persons interested in 2d game programming i suppose this book could be of good value though.

I can forgive the horrible editing, I suppose: sadly, I've gotten used to it, as it seems endemic to the computer book industry (and there are no errata on the publisher's web site). I could forgive the horrible misunderstanding of inheritance concepts in object-oriented programming (a sprite derives from a game field???). Mostly I could forgive these because the authors have a nice, clear style, and seem to understand fundamental game development principles that I am still learning, like collision detection. But when I was able to greatly enhance the performance of the example in chapter 3 because I already understood culling even though the authors don't, I became annoyed. And I just gave up when the example from chapter 4 ran at an unplayable speed: I just couldn't navigate the river in this game, the performance was so bad, and that was without moving enemies or the ability to shoot. Additionally, this example crashed both computers I tried it on twice. I won't even try to resell this as a used book: I'd be doing the buyer a disservice.

This is a pretty good book. It is very easy to read although the subjects discussed aren't really trivial. The book touches on a wide array of topics, ranging from GDI+ to DirectInput and DirectAudio, as well as DirectDraw.

However, the potential buyer should be aware that this is a very basic book. If you want to write the next Doom, this book will not teach you how to do that. In fact, considering that this book has "DirectX" in the title, it covers very little 3D programming. However, this book DOES teach the basics of game development and almost all aspects that go along with that, from simple graphics to controlling sound, and controllers such as force feedback joysticks. But as I said: Most of it is pretty basic. But if you have no experience with game development whatsoever, reading this book will be an excellent first step...

I was lucky enough NOT to buy this book. I sat down in Barnes & Noble this weekend and read the first 60 pages and skimmed briefly through the rest. I would hate to try and recommend this book to anyone. A beginner may learn a few things, but it's riddled with errors and some terrible programming techniques, that I would hate to see a beginner pick those techniques up as "the way to do it."

I think authors should take more care in the editing procedure. Even a casual re-reading by the author would have, I should think, exposed many problems, which could have been fixed before going to press.

A couple errors:

- Saying you'll take errors if you try and use a certain technique with indexed pixel formats, like JPEG. Excuse me? JPEG is not, never has been, and never will be an indexed pixel format image. Sorry!

- Saying "In .NET all the arrays must be defined without boundaries, which are later assigned in the code.
So we must always use Redim before assigning values to an array." What?! Are you nuts??

The biggest chuckle I got was when, in the first chapter, he is careful to code his own "Rectangle" storage so that he can save an addition (+) operation. But, if you look at the code for drawing the blocks, he is as inefficient as you can get: creating and destroying entire device contexts for EACH BLOCK. Yeah, for each (X,Y) block, he calls "ArrGameField(X, Y).Show(WinHandle)", which in turn does "Graphics.FromHwnd(WinHandle)". Crazy!!

eI am not sure if I am the only one who researched before I bought, but I found this book to be precisely what I expected, to a degree, but more on that in a moment. Some of the other comments are unfair to say the least. A sprite can inherit from a monkey if I want it to. This does not make it any more or less OO and those who say it does I feel lack the abstract vision...no point in bashing, the book does what it is designed to do and code-nazis will never be happy with anything that doesn't fit their narrow perception of 'the right way.'

I would say this book is really good for those who have written a lot of code, are at least somewhat comfortable with .net and know how to debug. That is because you will do a lot of debugging. I have no idea what went on, but the editing is horrendous, to be very kind. They will suddenly rename objects a page after they declared them, they will completely forget to inform you that you have to include a method and you only realize it when it is referenced later, they (and this is completeley unexcusable) have syntax errors that don't even make it past the copiler. The actual code in the text as a sample is completley useless unless you view it as psuedocode.

That being said, I found this book to be fairly uselful when I accepted the psuedocode notion above. If you know how to get around the text issues, this book does a pretty good job at intorducing many concepts of game programming. The DirectX info is good and let's be honest, how many other books are out there covering game coding in VB? I can churn out three complete, working apps (even taking into account all the textual errors) in the time it takes to muck through a C++ direct3D lib. It has been a fantastic 'jump start' on my game programming and you get to experiment and tweak where in other cases you spend the entire week just chunking out the code. It is just to bad the text is riddled with issues, because there are so many talented programmers who learned completely through working with VB, it is sad this title will not enable those same self-visionary-types to do the same with games.

All I can say is that I picked this book up hoping it could guide me through some simple game programming. I ended up more confused by How to use the book than I ever would by the code. As someone who likes to step through working samples, it seems virtually impossible to do so using this book. I have had it for over a month and am still trying to decipher the first chapter!

Here's an idea of what I am talking about. You begin by programming a tetris clone. You start by coding the little objects (puzzle pieces) that will fall from the top, you get to a certain point and the author says to run the program to look at the object - only one problem - there is no "playing field" for the object to be displayed! You have to flip ahead several pages to find out how to program the playing field. The playing field probably should have come well BEFORE you'd ever program the object that is going to be placed onto it. At the very least it should come before you are asked to run the program. Once you find the playing field code in the book, there is a missing reference to another class that hasn't even been written yet, so your search begins again. etc, etc.

I have so many examples of this type of frustration. Just when you finish your "code hunt" for a missing function, there is another one that rears it's ugly head.

I am giving it 2 stars because they explain some gaming concepts I wasn't familiar with like Collision detection and Proximity Algorithms. But other than that it has been a headache.

Like a few others who have posted here I was excited to see this book. How disappointed I was to find that the book was a complete mess. I feel for other budding game programmers like me who have struggled looking for the Draw( ) command referred to on pages 36 and 37. I kept searching through the previous pages, sure that I had missed something somewhere.

Turns out there is no Draw( ) command, never was. The correct command is Show( ). If I'm not mistaken the problem does not exist on the CD source code (available with the book), but for those who are typing it in from the book line by line (like me), you can stop looking now.

The mistake has been caught by APress and that plus other errata can be found here:

http://www.apress.com/book/errataDisplay.html?bID=111&sID=1039

I realize now that lots of books have errata pages online, so I guess this is normal in the industry, but it seems obvious to me that nobody at APress actually sat down and tried to USE this book as a layman. I know this because if they had done so prior to going to print, they would have found and fixed this problem!

What is also funny is that Mr. Labao and Ms. Hatton also have apparently not used the book they wrote, either. Kinda scary that as computer scientists they published the book while forgetting the most BASIC concept of computer programming of any kind: TEST, TEST, TEST!!!!