Build Your Own Flight Sim in C++ (1996)
archive.org
archive.org
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!
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.
Then you just need multiplies and adds to apply the transformation to each vertex.
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.
https://archive.org/details/msdos_Ultima_Underworld_-_The_St...
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.
And sounds like the original Sublogic flight sim:
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.
https://www.polygon.com/2017/3/2/14790028/no-mans-sky-was-fl...
BTW, the ePub link can't download:
https://ia904505.us.archive.org/epub/index.php?id=build-your...
> No valid doc name could be determined
Bummer, but I'll settle for the PDF. Unfortunate that IA's webviewer sucks.
Working PDF link: https://archive.org/download/build-your-own-flight-sim-in-c-...
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.
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.
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.
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.
Also, far too much simply typing out code that was unexplained or had no basis in prior text to the learner.
Was this it?
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.
(*) Callout, splash, burst, sticker, badge, seal, bastard, pick your favourite graphic design term.
This was the book that opened my eyes to big projects. Until I found this it had been mostly just keying in monster basic programs.
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.
———
[0]: https://www.macintoshrepository.org/18735-black-art-of-macin...
I recycled my collection... I should check to see if I kept the included CD-ROMs.
Loved the games and the "opening a gateway to cyberspace" premise.
> 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 said more about it in this comment:
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.