The far pointer

Noctis is full of pointers, which will be familiar to a technical reader as variables whose value is a memory address. But it is also full of far pointers, which might not be. (Sidebar: if you are reading this and remember using far pointers, email me, and I will buy you a beer.)

Far pointers are a relic of a time when a 16-bit pointer was not large enough to point at all the memory available to a program. Sixteen bits can represent 65,536 values, so an ordinary pointer could range over only 64KB at a time. To point outside that 64KB segment, a far pointer carried a second number for the window—which 64KB region am I looking at?—in addition to the location within it. To do so was to point at something far away. Thus the far pointer.

If that seems like a reasonably quaint relic of days gone by (as it did to me), imagine my surprise when I stumbled across a maybe far pointer. This felt like the old joke of adding maybe to your boolean type. It turns out that collaborators later added support for compiling to Windows, a then brand-new operating system that never needed the far pointer. And so maybe far pointer is a kind of shim, resolving to a far pointer if the program is compiling to DOS or a regular old pointer on the newer target. Phew.

Working with memory back in the day was no joke. This was especially true for a program like Noctis, whose ambitions were so much bigger than MS-DOS. One particularly heady header file is NOCTIS-D.h, which sent me into a bit of a cold sweat when I first read it. NOCTIS-D.h reads as a ledger of the game's memory. For those accustomed to garbage-collected languages, where you request memory whenever you like and something else tidies up after you, this file is essentially the opposite of that: a pre-allocated heap where every buffer the game will ever use is declared, sized, and allocated. Because a DOS program gets no virtual memory and no swap, just the machine's 640KB minus whatever DOS and its drivers have already eaten, Noctis budgets itself to exactly 563,200 bytes. Each one of those bytes is carefully used, reused, and recycled as the game progresses.

If dealing with memory pressure is one of the main traits of the codebase, the other is surely its personality. Consider this gem, from the top of PITAGORA.h:

//////////////////////////////////////////////////////////////////////////////
//                                                                          //
//                                    *                                     //
//                                Pitagora                                  //
//                     intelligent triangles renderer                       //
//           * the fastest and final solution to 3d rendering *             //
//                                                                          //
//                        (c)1999 Home Sweet Pixel                          //
//           Born for Noctis - my little darling space program!             //
//                                                                          //
//////////////////////////////////////////////////////////////////////////////

I fear I have never written a file that I loved quite so much as that in my career as a software engineer, although in recent months I have been inspired to rectify that.