I remember playing Wolfenstein and Ken's Labyrinth, and Doom, and wondering just how the heck it all was done. Then I came across a copy of this book in a "computer store" I was working at who couldn't (or wouldn't) pay wages. He told me I could have any book in the store for my work that day, and I grabbed this one on impulse.
I remember missing my stop on the bus ride home, because even though it was about flight sims, the algorithms and methods inside were about 3D programming - the very thing I'd been wondering about!
I never built a flight sim, but I _did_ build a rudimentary 3d game with the knowledge I gleaned from this book. There wasn't any collision on the walls, and the sprite-base object pickups with get corrupted randomly after a while, and I never really got the hang of doing matrix multiplications instead of geometric transforms, but this book cemented my love of programming at a point where I may not have really pursued it much more without an in-depth project to spur me on!
This was me only 15 years earlier. My math teacher had a TRS-80 and an early flight sim. For terrain it had a grid, an airport, and a simple, flat, mountain range. It was loaded from cassette.
He didn’t know the math. In fact when he was teaching us matrices in Algebra II, he really couldn’t answer how matrices were used in the “real world”.
But somehow I managed to track down a couple year old Byte magazine that had an article on 3D graphics, and it was all about matrices and points to do rotations and what not.
With that, I got a cube to rotate on a PET 2001. In all it’s 40x24 glory. Well, there were 8 dots. If you squinted in low light, it would look like a cube.
Later, in college I got access to a textronix storage tube microcomputer. It was standalone in contrast to their terminals. That was able to render a cube quite well. And the car I painstakingly created on graph paper and keyed into DATA statements using the machines built in BASIC.
By then, early Foley-Van Dam was the coveted graphics book to get.
Actually the author - Christopher Lampton, has an earlier book just on the topic of this games style. It's called "Gardens of Imagination, Programming 3d maze games" https://archive.org/details/gardensofimagina00lamp
I have both and they've been great resources. I had been wondering for a long time how to add arbitrary height to a raycasting engine, and that book finally showed me how.
It's the kind of stuff that got me into programming. I never worked in this space but it was a huge inspiration. I used to buy cdroms that were dumps of certain website like drdobbs and alike
Wait, why would you do matrix multiplications instead of geometric transforms?
I got a C in "Survey of Physics" in college, and struggled _hard_ with any math that was meant to model physical phenomena. I aced calculus and anything abstract. I dunno what that says about me.
A matrix multiplication is just a handful of multiplications and additions, which are very fast. If your CPU has FMA instructions, that will cut the number of operations approximately in half. If you do raw trig with angles and such, chances are you'll have a bunch of sin/cos/tan and divisions in your code, which are capital-S Slow. The same transformation might be 1-2 orders of magnitude slower than if you had modeled your transformation as a matrix.
They're easier to compose. Easier to reason about. If you have several transformations that you need to do in a row, you can just make one simple matrix for each step, and then shmoosh them all together with a great big matrix multiply.
Matrices have a tendency to collapse floating point inprecision. A 3D model will often be constructed in [-1.0,1.0] coordinates for xyz. The final camera space that your GPU draws will often have no coordinate greater than 10,000 or so. These are easily precisely represented with 32 bit floats. However, if you do a multi-step geometric transformations on them, you will more often than not blow out your floating point precision in intermediates. This means you need to do your entire transformation with doubles. On the other hand, if you're using matrices, you construct each matrix with doubles, compose your complete transformation with doubles, then convert the final matrix to float and everything is fine. When you transform the points of your model from model space into camera space, you'll use the matrix with 32 bit floats.
Good modern compilers (not MSVC) will generally do a pretty good job of optimizing a matrix multiplication to SIMD instructions. In the previous paragraph, you might think, "who care if I have to use doubles instead of floats?" and this is why. Floats are twice as fast as doubles in dense SIMD code.
GPUs will have first class support for matrices. You can just be like "here's my matrix bro" and the GPU will be like "thanks".
Unfortunately I don't know of a good way to learn the subset of linear algebra that programmers need to model the real world. The Gilbert Strang linear algebra MIT courseware is all well and good, but it really focuses on the needs of mathematicians. I feel like everything I know about linear algebra I just sorta picked up through osmosis over the years.
The instructor teaches this material at a university in London and it's obvious to me that he has a lot of experience teaching it. The course has been perfectly paced so far and exactly what it claims to be. After I finish his graphics course I will be taking another course or two from him.
He teaches how to program graphics from scratch using C. The only dependency is SDL2. The first steps of the course are to setup a SDL2 abstraction that allows you to set the color of individual pixels, and then the rest of the course builds on that abstraction. That's what the course teaches, given you can set the color of a pixel, can you then draw the rest of the 3D textured owl? I've been doing the course in Rust, using Rust's SDL2 bindings and nothing else.
I've been enjoying the course and felt it was an honest transaction and a good course, so I wanted to share. I haven't seen much talk about these courses elsewhere.
I remember having this book. I was probably 14 or 15 years old, and I was just getting into aviation after being given my first flying lesson. I had a copy of MS Flight Simulator, and I had taught myself some C++, but of course the content of the book was a bit beyond my capacity at the time. It's nice to relive the excitement of getting this book with the idea of being able to make my own flight sim. Of course, the sim they make in the book, IIRC, was nigh unplayable!
Tricks of the Windows Game Programming Gurus was great too. And tricks of the 3D Game Programming Gurus contains a full 3D engine in C starting from drawing a pixel (a software rasterizer).
Funny. I randomly jumped to page 216 which provides a somewhat rudimentary (but reliable) method for dealing with mapping 3D world coordinates around a sphere, and I just recently read about the completely different No Man's Sky solution for world generation.
I still have the programs I wrote when I went through this book. The experience of bringing a 3D world to life felt like magic: you start with a black screen, draw some lines, and when you move them around in just the right way there’s suddenly a world inside the screen. It’s hard to get that same feeling today.
I think I was gifted this book for my 13th birthday so some of the math was a bit beyond me. But learning assembly and working out some of the more intricate algorithms like polygon clipping were both great training for a new programmer.
It's impressive how many pages are devoted to creating the universe in the book. Back then you didn't just fire up the OpenGL library to initialize the stack. This book starts off with how to set the registers on your VGA card to put it in the right mode, how to read in bitmaps and their palettes from the disk, how to write your own run length encoder to save memory on those bitmaps, what registers to set on the joystick port, and so on.
Yeah, worked through this book (had to make changes since I was on a Mac). Implemented Bresenham's, polygon clipping, rear-face culling ....
Normally the math would have tripped me up with the new-to-me matrices, dot products, cross products, etc. As chance would have it I was taking a summer course on Linear Algebra at college so the book dovetailed rather nicely with the lectures.
IIRC, this book had a 5.25" floppy inside that allowed one to fly the simulator around some pyramid shaped mountains. This brings back fond memories, thanks for posting.
Is it just me, or were so many books from this era just outright bad?
I spent a few years teaching at General Assembly, and in that time I learned so much about pedology, how I often learn, how others learn, and that I can't always assume the way I learn will be appropriate for others, particularly in text format.
I had Teach Yourself Game Programming in 21 Days, by Andre LaMothe when I was an early teen. I made repeated attempts at learning game programming with it, finding only failure each time. Maybe I wasn't cut out for programming? I put it away, and went to school for music instead.
Years later, no thanks to this book, I'm a pretty good programmer. I've looked over it again, and I'm aghast at what I see. It bills itself as needing no real experience. It jumps from "this is a mouse" in chapter 1, to some pretty advanced VGA screen manipulation between chapters 2 and 3. Loops, functions, OOP, data types? Nah - it just throws code at you without concepts. It is shocking if anyone learned from this. I was worse off having read it, and nearly 30 years later kinda salty about it!
I'm good at learning from books too! I taught myself Ruby after reading _why's poigiant guide, Agile Development with Ruby on Rails, the Pickaxe book, POODR, and the Ruby internals book. If a book structures information well, and I can sit and work on practice problems, I can get the concept.
Maybe we learned a lot about how to write programming books around this era? I've generally found books on O'Reilly, Addison-Wesley, No Starch Press, etc to be rather good. They generally consider how to structure learning and information in a way that is progressive and don't make too many leaps. These "Learn in X days" style books in the 90's were basically info dumps, and without Google it was nearly impossible as a kid in the 90's to get help. No adults around me had any idea, and if it didn't work - it didn't work.
I'm curious what the breakthrough was, or what changed. The first decent programming book I ever read was Programming Perl by Larry Wall. I came to it much later, but the ANSI C book made a ton of sense upon first read too.
A good modern intro to game development (and Rust) can be found with Hands-on Rust: Effective Learning through 2D Game Development and Play. It doesn't dive deep into the more difficult parts of Rust, but it also doesn't make you feel like an idiot.
For a look back at 90's games, the Game Engine Black Book: DOOM by Fabien Sanglard really helped me understand the systems and logic of Doom and other similar games.
I agree that many books were bad simply because the authors could not write well and had no idea about pedagogy. I think the number of people who knew something about a particular subject was just smaller and that's why it wasn't questioned much by the publishers.
Another reason may be the fact that a lot of information could not yet be found on the Internet. That is why some authors were more interested in listing the information than in pedagogical communication. The result were books like "Chapter 1: How to start the compiler from command line", "Chapter 2: List of all functions of the standard library", no chapter 3.
Agreed. I think many of these books were written by people who knew the subject themselves, and were just putting their knowledge on the page without much of a feedback and testing loop to see if it was using a method that transferred to a person who didn't already have that knowledge.
Also, far too much simply typing out code that was unexplained or had no basis in prior text to the learner.
Oh! I had the original version ("Flights of Fantasy") and that's where I learned as a teen about matrix multiplication to represent translation and rotation!
No idea sadly, I remember getting it from the university library in probably '91 or '92, and reading through it, but the title evades me, and searching on google and ddg brought no clues.
As to what it was about? I recall it featuring programming flight simulations, BUT it might have been primarily a book about computer graphics, or game dev generally with a section on flight simulations. My memory tells me that the front cover had a sort of callout(*) with a proclamation that it had a section on using quaternions.
Wow I actually remember this. That cover was sharply buried somewhere in my memory. It's a shame websites don't have that same level of tactical and visual information to seed a deep memory.
Great book and great memories, now get off my lawn.
I'd love a book in similar spirit, targeting say OSx/Metal, that started from first principles and built a 3d (flight|space) sim, in a fun language (simple C++). And yeah that means a blank screen, then some lines, then a triangle... etc. I'd take a series of followup books adding more to engine, perhaps targeting different styles of games and their engine tradeoffs.
I guess it would be hard to decide between software/hardware rendering, as software would just teach so much.
For aspiring Mac game developers, from the same area (Macintosh based operating systems) there was another nice book: “The Black Art of Macintosh Game Programming” [0]. Also includes a basic flight sim.
I have Andre LaMothe's "Tricks of the 3D Game Programming Gurus", which in recent years i've been using as a height lift for stuff (like a CRT in this photo[0]) as it is massive :-P
The book is nice but LaMothe needed an editor badly, not only there are endless reams of source code in the book (despite coming with a CD-ROM), he was also often incredibly verbose to the point where by the time i finished some section i forgot how it all began. IIRC the book was so big that it couldn't all be put in print and the last chapter (or chapters) were on CD-ROM. And the parts that were printed were still so physically big that i had a hard time reading it.
Also i think his focus was a bit too lopsided, he spent way too much on some things but barely on others. For example he spent a lot of time for various ways to do slightly different rasterizations (e.g. bilinear filtering - which, ok, it is the only gamedev related book or tutorial i know that mixed software rendering and bilinear filtering) but on the part about optimizing the renderer to not render invisible stuff (which at least IMO would be more important than doing bilinear filtering for a software rendering engine) he largely handwaved things.
I hate trash talking someone's hard work, but Andre's books actively set me back as a programmer and made me feel stupid. I'm glad they worked for some people, but they really shouldn't have sold themselves as for anyone, but rather for people who already knew C/C++ rather well
> This book is for anyone remotely interested in game programming, from the
arcade junkie wanting to test his programming skills to current game program- mers looking for new ways to market their games. This book uses a unique day-by-day approach to teach major concepts, industry terms, and little-known
secrets about game programming.
I had that one in like 9th-grade as a hand-me-down from my brother. Learned so much, from 3D transformation matrices to how to make an 8-bit audio DAC.
Chris Hecker and Jon Blow (among others) wrote good math and physics content for Game Developer Magazine, but the one I most associate with it is Jeff Lander. He's got copies of the articles he wrote throughout the years hosted on his website here: http://www.darwin3d.com/gamedev.htm
I’m not a C++ guy, but this topic fascinates me. Might poke around and try to have an LLM transpile the code from C++ to Rust. I expect it won’t work but worth giving it a shot :)
I remember playing Wolfenstein and Ken's Labyrinth, and Doom, and wondering just how the heck it all was done. Then I came across a copy of this book in a "computer store" I was working at who couldn't (or wouldn't) pay wages. He told me I could have any book in the store for my work that day, and I grabbed this one on impulse.
I remember missing my stop on the bus ride home, because even though it was about flight sims, the algorithms and methods inside were about 3D programming - the very thing I'd been wondering about!
I never built a flight sim, but I _did_ build a rudimentary 3d game with the knowledge I gleaned from this book. There wasn't any collision on the walls, and the sprite-base object pickups with get corrupted randomly after a while, and I never really got the hang of doing matrix multiplications instead of geometric transforms, but this book cemented my love of programming at a point where I may not have really pursued it much more without an in-depth project to spur me on!