Books by Ian Parberry

Introduction to Game Physics with Box2D (2013)

Thumbnails.

Ian Parberry, Introduction to Game Physics with Box2D, AK Peters Publishers, 2013. [More Information]

3D Math Primer for Graphics and Game Development 2e (2011)

Thumbnails.

Fletcher Dunn and Ian Parberry, 3D Math Primer for Graphics and Game Development, 2nd Edition, A.K. Peters, 2011. [More Information]

3D Math Primer for Graphics and Game Development (2002)

Primer 1e strip.

Fletcher Dunn and Ian Parberry, 3D Math Primer for Graphics and Game Development, Wordware Publishing, 2002.

From the Introduction

If you want to learn about 3D math in order to program games or graphics, then this book is for you. There are many books out there that promise to teach you how to make a game or put cool pictures up on the screen, so why should you read this particular book? This book offers several unique advantages over other books about games or graphics programming:

Author's Comments

Fletch deserves 99.9% of the credit for this book. I'm responsible for goading him into more and more informality by, for example, chronicling the invention of the natural numbers by counting dead sheep, and adding obscure Douglas Adams references. As a result this book is loved by its intended audience and hated by my mathematically inclined colleagues. Fletch was concerned about this, but I am not: My job here is done.

Introduction to Computer Game Programming with DirectX 8.0 (2001)

DX8 book image.

Ian Parberry, Introduction to Computer Game Programming with DirectX 8.0, Wordware Publishing, 2001.

From Read This First

Have I got your attention yet? "Read this First" reminds me of the purchase of my first home computer in the 1980s. It came with no less than seven documents that said "Read This First" in big bold letters at the top of the page and they all threatened dire consequences if I failed to do the things listed on that particular piece of paper first . I did my best to follow the instructions, but bad things happened anyway. I suspect that bad things would have happened no matter what I did.

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.

Author's Comments

The publishing company asked for a slimmer version of the DirectX 7 version of this book, and along the way asked me to update it to DirectX 8. I did, but using legacy code, which led to mostly bad reviews in spite of my clear warnings in the Preface.

Learn Computer Game Programming with DirectX 7.0 (2000)

DX7 book image.

Ian Parberry, Learn Computer Game Programming with DirectX 7.0, Wordware Publishing, 2000. (See also the Foreword by Melanie Cambron, Game Recruiting Goddess.)

Preface

I am constantly amazed by the politeness of students in Texas. Not one of the students in my game programming classes has ever, in seven years, asked me the obvious question, which is, "Who are you, and what makes you think that you know anything about game programming?" with its equally obvious corollary, "If you're so good, why aren't you out in the game industry earning the Big Bucks?" The answers to those questions apply to you, the reader, too. Why should you buy a book on game programming from just anybody?

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.

Author's Comments

This book sold quite well, over 10,000 copies in fact.

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.

Problems on Algorithms (1995)

Thumbnails.

Ian Parberry, Problems on Algorithms, Prentice Hall, 1995.

From the Preface

The ability to devise effective and efficient algorithms in new situations is a skill that separates the master programmer from the merely adequate coder. The best way to develop that skill is to solve problems. To be effective problem solvers, master-programmers-in-training must do more than memorize a collection of standard techniques and applications - they must in addition be able to internalize and integrate what they have learned and apply it in new circumstances. This book is a collection of problems on the design, analysis, and verification of algorithms for use by practicing programmers who wish to hone and expand their skills, as a supplementary text for students enrolled in an undergraduate or beginning graduate class on algorithms, and as a self-study text for graduate students who are preparing for the qualifying (often called "breadth" or "comprehensive") examination on algorithms for a Ph.D. program in Computer Science or Computer Engineering. It is intended to augment the problem sets found in any standard algorithms textbook.

Circuit Complexity and Neural Networks (1994)

Images from Book

Ian Parberry, Circuit Complexity and Neural Networks, MIT Press, 1994.

From the Preface

One of the basic problems with neural networks is that they do not always scale well. Early research has shown that they work adequately on small problems (those with a small amount of input data), but when they are scaled up to larger problems they often need more neurons than current technology can provide or take more time than users are willing to wait. The standard defense against this criticism is that technology is constantly improving, so it will eventually catch up with our needs. However, our needs are not static: as time progresses we will want to solve larger and larger problems. The important question is how well neural networks scale, that is, how fast does the computation time and number of neurons grow as the problem size increases. If they grow too fast, then it may not be feasible to expect that advances in technology can keep pace.

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.

Author's Comment

I remember the editor at MIT Press being annoyed that the manuscript I turned in was a lot shorter and did not contain what he was expecting. I had to argue quite a lot before they would go ahead and publish it. It has been cited well over the years, so I guess I was right.

Parallel Complexity Theory (1987)

Images from Book

Ian Parberry, Parallel Complexity Theory, in series Research Notes in Theoretical Computer Science, (R. V. Book, Ed.), Pitman Press, London, 1987.

From the Preface

Parallel complexity theory, the study of resource-bounde parallel computation, is surely one of the fastest-growin areas of theoretical Computer Science In the light of this, it would be foolish to attemp an encyclopedic coverage of the field. However it is the belief of the author that its foundation are becoming increasingly clear and well-defined. This Monograp is an attempt to present these foundations in a unified an coherent manner

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.

Author's Comments

This is the book version of my thesis with a few additions, including an integer version of Mike Paterson's treatment of the AKS sorting network.

Created May 1, 2012. Last updated August 3, 2019.