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.
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!