Ian Parberry, Introduction to Game Physics with Box2D, AK Peters Publishers, 2013. [More Information]
Ian Parberry, Introduction to Game Physics with Box2D, AK Peters Publishers, 2013. [More Information]
Fletcher Dunn and Ian Parberry, 3D Math Primer for Graphics and Game Development, 2nd Edition, A.K. Peters, 2011. [More Information]
Fletcher Dunn and Ian Parberry, 3D Math Primer for Graphics and Game Development, Wordware Publishing, 2002.
Ian Parberry, Introduction to Computer Game Programming with DirectX 8.0, Wordware Publishing, 2001.
Such is not the case for this book. Browsing this chapter will, however, help you to get started on the right foot.
Does This Look Familiar?
This book is a short, inexpensive version of the author's book Learn Computer Game Programming with DirectX 7.0. If you already own that book, then don't buy this one. The difference between that book and this is that:
Are You Reading This in the Bookstore?
Are you reading this while standing in the bookstore trying to decide whether to buy this book? If you are, then this section is written just for you. Sit on the floor for a few minutes while I explain what it's all about and how purchasing this book can help you get your start in the computer game industry. If you are in one of those wonderful bookstores that have plush chairs and actually encourage you to sit and browse through the books, you may as well make yourself comfortable instead of skulking in the aisles getting in the way of other customers. A cup of coffee might go down well too. My writing style is highly caffeinated. Just don't spill any on the pages.
I assume that you picked up this book and opened it because you are an aspiring game programmer and the title looked appealing, not because you are male and "Melanie Cambron, Game Recruiting Goddess" sounded attractive. Well, maybe a little of both. Let me tell you right now that she is intelligent and very good at what she does, which is find employees for game companies. If you haven't read her foreword already, I recommend that you do it right now. It contains sensible advice about getting started in the game industry, and a picture of Melanie. Have you done it yet? Good. Now that we've satisfied our curiosity, let's take a more serious look at what this book has to offer.
First, let me tell you what this book is not.
Most DirectX books fall into two categories. Some attempt an encyclopedic coverage of the DirectX API, describing all of the possible permutations of all of the awesome and confusing choices of parameters of almost every DirectX function. You can spot those books by their huge tables listing functions and parameters- tables that often look as if they were cut-and-pasted directly from the DirectX documentation. This book is not like that. It assumes that you are smart enough to look up parameters yourself using the DirectX online help.
The second category of DirectX books gives you a monolithic game engine, essentially a wrapper for the DirectX API, that you can use to make a game of your own. They plunk this huge piece of code "thunk" on the table, and then explain how to go about making it work for you. It is usually a piece of code that attempts to be all things to all people, and even though it contains more than you need to know to get started, it may not end up being exactly what you need. This book is not like that. It assumes that you want to write your own code from the ground up, not customize somebody else's engine.
There is nothing wrong with either of these approaches. I have both kinds of books on my bookshelf. The approach that I take in this book, however, is different. It is the product of seven years of teaching game programming to students of computer science at the University of North Texas. Typically, those students are smart enough to read the documentation that comes with the DirectX SDK, and smart enough to experiment with the code samples. The problem is, all that information is fragmentary and overwhelming in its complexity. There's just so much information that it's hard to know where to begin.
That's where my class comes in. I teach using a series of game demos for a side-scroller called Ned's Turkey Farm. Each demo adds a new feature or set of features onto the previous one, much as a real game is developed. Thus, the class is as much about the process of coding a game as it is about DirectX.
This book is designed to give you a taste of the same experience without having to come to Texas. Admittedly, you lose out on the other things that my class would give you-including the experience of hanging out in my lab and the opportunity to work on a game demo in a group with other programming and art students, but there's not much we can do about that. I will go through the code function by function, line by line, explaining what I am doing and why I am doing it. There's nothing cut-and-pasted from the DirectX documentation, and I won't ever assume that you are a dummy or an idiot. If this sounds good to you, then go ahead and buy this book.
Ian Parberry, Learn Computer Game Programming with DirectX 7.0, Wordware Publishing, 2000. (See also the Foreword by Melanie Cambron, Game Recruiting Goddess.)
Before I answer, let me digress and tell you how I got into game programming. In 1993 I was going through what in academic circles passes for a midlife crisis. In the business world, the recognized panacea for men who go through midlife crises usually involves a red sports car and a young trophy wife. In academia we rarely have enough money or panache for the red sports car and the trophy wife, but we have coping strategies of our own. Part of the typical midlife crisis involves questioning who we are and what we are doing in life. The academic midlife crisis sometimes involves questioning the validity of the typical academic lifestyle, which for a computer scientist like myself involves doing research, publishing the results of that research in scientific journals, and getting grants from federal funding agencies to do more research. Oh, and we teach too.
I had a lot of experience doing all of the above. But that "Oh, and we teach too" attitude was beginning to bother me. And the rising pace of the computer industry, the way it was beginning to transform the economy, and everything about modern life was beginning to bother me. Actually, it was more the fact that computer science as taught at universities just didn't get it, and our students knew it that it didn't get it. We were beginning to see entering college the crest of what was once called the Nintendo generation, the generation of kids for whom computers were a normal fixture of everyday life, as much as a microwave oven or a CD player was to the previous generation. This generation thinks nothing of reformatting their hard drive and installing a new operating system, a process that is still beyond the reach of many Ph.D.-bearing professors of computer science. And yet computer science in college was - and mostly still is - being taught much the way it was taught in the 1970s. The excuse that most academics give is that we are teaching "fundamentals," and leave the cutting-edge aspects of computer science to on-the-job training. "Give them a firm foundation of fundamentals," they say, "And the students will be able to learn the tools they need to get a job."
During my midlife crisis, I underwent what is euphemistically called a paradigm shift. I changed from being a card-carrying theoretician who always quoted the party line on college education to holding the following belief: While I agree that students need a firm grasp of the fundamentals of computer science, I believe that it is now no longer enough. The tools of the trade that they will be using on the job have become too large and too sophisticated, and there are just too many of them to leave it all to "on-the-job-training" (making it Somebody Else's Problem) after college. Students have the right to training in fundamentals, and to have those fundamentals illustrated on at least one real-world application using the same tools and techniques that they will be using in their first job, weeks or days after they graduate.
This poses a challenge for academia. The tools that programmers use change too quickly. Academics don't like to change what they teach, and for good reason. State legislators seem to believe that the average academic is basically lazy, so we are allowed very little time for the preparation of new material. Developing new classes takes time. Computer science professors are typically burned by this already, as they must revamp most of their classes every few years. The prospect of doing this every semester is frightening.
Nonetheless, I was coming to the conclusion that some of us need to do it. We owe it to our students. I was (and still am) under no illusion that I can change academia by talking and writing papers about the phenomenon. Instead, I chose to lead by example - I would just go ahead and do it. After all, I have tenure, and the concept of academic freedom, the freedom of a professor to develop his or her own vision of education, is strong at the University of North Texas.
The question was, what area of computer science should I apply my grandiose scheme to? There are just too many areas to choose from. It should be something new and different, something that captures the imagination of students, territory that is largely untrodden by academic feet. One evening, with these kinds of thoughts on my mind I walked by the General Access Computer Lab on my way out of the building and noticed that the usual group of students playing games was absent. Instead, there was a sign on the wall saying something like "The Playing of Games in the General Access Lab is Banned." This kind of "Dilbert Decision" is one that always annoys me - a rule made by administrators to make their lives easy. The desired result is to make sure that students don't play games when other students are waiting in line for computers to finish their homework assignments, but it is so much easier to ban games altogether than to constantly have to confront students who either by accident or design continue playing into busy periods.
This dislike of arbitrary rules and a general feeling of restlessness drove me to talk to some of these students who seemed addicted to games. After a few minutes' conversation, I quickly learned that, more than playing games, these students wanted to write their own games. The problem was, in 1993 there was almost no published material on game programming - almost no books, and no information on the fledgling World Wide Web. That was a "Eureka!" moment for me. I had found my niche. With hubris typical of a theoretician, I signed up to teach an experimental course on game programming, with the idea that the students would help me research the area and we would learn together. The course was a wild success, and the rest, as they say, is history. The class became more formal and got its own course code, and now my game laboratory is recognized as one of the premier places in the country to learn game programming.
Since then, I have written and published several games and trained hundreds of students in game programming, the very best of whom have gone on to become successful game programmers in major corporations. I have over 16 years of experience as a professor and seven years of experience in teaching game programming. I know how to teach a class, and I know how to structure a book so that people can actually learn from it. That's who I am, and what makes me think I can write a book on game programming.
The kids in the General Access Lab that I mentioned above were playing Dune 2. This was an early RTS released in 1992. The students were interested in how the motion planning worked when they clicked on a unit and sent it to the other side of the map, in particular how they managed to make it work in real time for multiple units simultaneously while rendering at over 24FPS on a 66MHz 486DX2, and why units would sometimes but not always get trapped in cul-de-sacs. That's when it hit me. That was A* in action. These kids wanted to learn A* to use it in games, not as a boring old CS class. That's what got me so excited about teaching game development.
Ian Parberry, Problems on Algorithms, Prentice Hall, 1995.
Ian Parberry, Circuit Complexity and Neural Networks, MIT Press, 1994.
The number of neurons and running time of neural networks are examples of computational resources. Others include memory and hardware in conventional computers. The study of how the demand for computational resources scales with problem size dates from the 1960s with the seminal paper of Hartmanis and Stearns. This area of research is called computational complexity theory, and is one of the richest fields of theoretical computer science. The aim of this book is the examination of how neural networks scale using, for the most part, a branch of computational complexity theory known as circuit complexity.
The reader will notice that the majority of the material in this book is on computation by neural networks as opposed to learning, which is slightly unusual since the balance in the technical literature is tipped in the other direction. Neural network computation is a necessary part of the foundations of neural network learning. Just as a child cannot learn to perform a task unless he or she is physically capable of performing it, a neural network cannot learn to compute a function unless it is physically capable of computing it. "Physically capable" in this context means "possessing sufficient resources", in particular, enough neurons and time. Although this book is aimed at an audience interested in neural networks, some of it consists of background material about computational complexity theory as it applies to conventional computers. This is included because one of the aims of this book is to make a comparison between the complexity of neural networks and the complexity of conventional computers. This comparison is meaningless unless the reader knows something about the latter. I have attempted to present the background in as palatable a form as possible for neural networkers. For example, I have avoided all talk of Turing machines and nondeterminism. Instead, circuit complexity has been used throughout as a unifying theme.
Ian Parberry, Parallel Complexity Theory, in series Research Notes in Theoretical Computer Science, (R. V. Book, Ed.), Pitman Press, London, 1987.
The material contained herei is aimed at advanced Graduate students or researcher in theoretical Computer Science who wish to gain an insight into paralle complexity theory. It is assumed that the reader has (in addition t a certain level of mathematical maturity a general knowledge of Computer Science and familiarity with automata theory, formal languages complexity theory and analysis of algorithms.
Created May 1, 2012. Last updated August 3, 2019.