Completely NSFW, but I worked at a company where we frequently needed to measure distance in approximate meters. I don't know the full origin, but at some point, after a night of drinking, one of the managers discovered that an elephant penis was approximately one meter.
From then on, any estimated distance was done in EDs.
A nautical mile is ~6,076 feet or exactly 1,852 meters (???).
That is actually defined by distances on Earth (which is of course an approximation, but still ...). So, 1 nautical mile equals to one minute in the 90 degrees hemisphere arc. It's approximately 10k km from equator to the pole, so 10,000km/90/60 equals 1.852km.
> Note that Fortran supports arrays with an arbitrary starting index, in this case -2. So this table supports indices in the range [-2, 9].
That is such a useful feature! Surprised I haven’t seen that more often. So much fiddly code exists that’s just fixing offsets to conform to 0 (or 1 for Lua) -based indexing!
This seems like a really reasonable implementation looking at the actual physics loop. From a game design perspective, lookup tables can be a very powerful way for artists to interact with the physics. For example, it makes balancing 2 different vehicles a lot easier in conversation. You could say things like "I think we need to reduce the performance of XYZ between 1000 and 8000 feet to balance with ABC". Inserting a new band into the table is an obvious exercise in Microsoft excel.
I'm somewhat surprised the physical units matter in a computer simulation. As long as the simulation is internally consistent (which I would assume the original code is) it seems odd to me that the nominal units are important at all.
Is that video game character walking 100 yards? Or maybe the character is 500 feet tall and he's walking 50 leagues?
I saw slugs and I immediately had PTSD from my days in aero engineering.
Imagine trying to keep track of pounds in a single set of equations using subscripts m and f to differentiate between the units’ use for both mass and force.
When I was growing up computers were getting faster by leaps and bounds, and I remember a video game that was so 'sophisticated' that it needed a math (FP) co-processor (80387) to play some parts of it:
> The program requires a minimum of a 12MHz 80286, 1MB RAM, DOS 5.0 or DR DOS, one 1.2MB 5 1⁄4" or 1.44MB 3 1⁄2" disk drive, hard drive with 11MB of free disk space, and VGA graphics. In addition, Falcon3.O supports a joystick, a joystick with a throttle, dual joysticks, rudder pedals or the ThrustMaster controls. The game also supports a mouse and various sound cards, including the Ad Lib, Sound Blaster and Roland. The 80x87 math coprocessor is supported for the HighFidelity flight model.
> Optimal system requirements are a 20MHz 80386 system or faster, 80x87 math coprocessor, 4MB RAM with EMS (expanded memory), DOS 5.0 or DR DOS, one 1.2MB 51⁄411 or 1.44MB 31⁄2" disk drive, hard drive with 11MB of free space, a 16-bit VGA card, a mouse and a joystick.
My Mom was a FORTRAN programmer for a defense contractor from the late 50s to the mid 90s. She spent her career doing things like that F16 simulator. The last thing I remember her talking about was one of the B1 or B2 bombers.
When I was elementary school age in the late 70s, I'd go into her office with her sometimes on school holidays that were not work holidays. She'd let me play Colossal Cave Adventure on a terminal in her office. I remember looking at printouts of code she was working on, and seeing a wireframe diagram of some futuristic plane. I think it must have been one of the first Stealth fighters. I wonder how many security protocols she broke by having me there... :)
She passed a way many years ago, but I think she would have been excited to see work like this.
Awesome read except I have one nit. Instead of writing translating functions to convert everything from US Customary units to Unity, Metric, and the rest of sanity, you should have converted everything to metric in the formulas. Rewritten the math. It's not that hard, it's not that difficult, saves you all those function calls, improves performance, and simplifies the math a whole bunch.
Air density can become pliable, controllable. Thrust velocities match projectile spec velocities (m/s) making calculating intersect a breeze. Trust me, you want to convert the FORTRAN math into standard metric. They didn't believe in Base10 back then so do the math.
I wanted to keep the data tables exactly the same in the C# translation. While formulas can be converted to metric easily, the data tables do not actually have units defined for any of them, so translating them to metric is non-trivial. And the way data is mixed from multiple tables is very complex. So verifying that the calculations have equivalent results in metric is well beyond my ability.
Or rather, the best way to verify it would be to write a flight model that uses customary units (what I describe in the article), and then use that to verify that the metric flight model is equivalent.
At the end of the day, only the inputs and outputs of the flight model need to be converted, which is just handful of multiplication operations. The flight model is very cheap to run, even with conversions at runtime.
Awesome achievement but I have to say the units stressed me out. I hope that in the real world there's some kind of dimensional analysis code linter that verifies no one is comparing slugs to feet or something, and that altitude doesn't go below zero.
You actually need the altimeter to be capable of reading below 0 in the real world.
Aircraft altimeters are based on air pressure. The reference pressure is variable based on atmospheric conditions and is decided by controllers, or in the case of uncontrolled airspace, the matching the altimeter of the known altitude that you took off from.
All that is to say, on my home (uncontrolled) airport which is ~10 feet above sea level, I occasionally land at a negative altimeter value since the weather conditions have changed while I am in the air.
Assuming that an altimeter reading must be positive is a bad assumption.
In my experience in both the aerospace industry and the video game industry, there are no tools like this in use. In aerospace specifically, errors like that are caught by manual human review, including third-party validation companies. Unit tests are used to sanity check every calculation. And finally, everything is run in a flight simulator before ever going onto a real aircraft.
In video games however, it's the wild west. Math errors there are funny, not deadly.
In keeping with the discussion here a few days ago, this article demonstrates exactly my point about developer types not being the target for computational codes. Their interpolation routine looks extremely verbose already, I cannot imagine them attempting to solve or compute any other more complex formula like that beyond a mere 2d interpolator writing so verbosely like that. The result would be unreadable, to my eyes.
Modern fortran has a bit more modern flavour to it, but formulae being so verbose would make the "formula" aspect of a code disappear.
The fact that this person put a snarky (???) next to the concept of measuring airspeed in knots makes me wonder just how familiar they are with aerospace in general. A knot is a standard measurement in part because one nautical mile is equal to one minute of latitude. Which is useful until the day we decide to start measuring lat/long in radians.
I know it's fashionable in some circles to dump on everything non-metric, but these things are they way they are because of reasons, and airspeed is generally measured in either knots or Mach.
As someone who works in flight simulation I was also taken back hard by this. We are internally metric all the way, but even so the knot is not a weird unit in this space at all. I also never heard about those coordinate conventions.
Hi author here, I have worked in the aerospace industry on flight control systems. I'm very familiar with knots as a unit.
I'm just annoyed that so many educational resources and even flight code still use customary units for everything. I believe that metric should be used for all internal calculations and knots should only exist at the UI layer for the pilot.
When I play flight games though, I only have intuition for speed in terms of knots. Like 150 kts is takeoff speed and 400 kts is the corner speed.
I just think that the pilot letting out a spool of knotted rope from their plane is a very silly practice to defend :)
I am pretty firmly in the Z-up camp, I mean I understand the Y-up camp, take a normal picture, or perhaps a side-scroller game, Y is up and down, the logical extension to three dimensions is to push z as depth. But I can't do it, I see X and Y as a in a map where the obvious Z direction is up and down. yes minecraft triggers me so hard, don't even get me started.
In the late 90's, I worked on porting a FORTRAN reactor simulator to Windows 95/NT/XP. On the order of 30 MLoC for an industry/research joint project that was around 40 years old at the time. It took a long time to compile, but even longer to run. It turned out that disabling swap on Windows was the single biggest runtime performance improvement on machines with around 128-258 MiB of RAM. Windows would cheerfully page out the working set when there was no other non-system source of memory pressure.
PS: The time for SMRs was 40 years ago. Renewables radically transformed the economics such that only fusion reactors, geothermal, and tidal are part of a short list of viable alternatives because fossil fuels and fission need to go the way of whale oil and hunting passenger pigeons.
I’d heard at least one FBW system was written in Lisp or an interface for it was. I don’t remember which aircraft, but I think the one of the F-15s. It seems like that it was used at that time for some flight system development.
31 comments
[ 1.6 ms ] story [ 92.0 ms ] threadFrom then on, any estimated distance was done in EDs.
That is such a useful feature! Surprised I haven’t seen that more often. So much fiddly code exists that’s just fixing offsets to conform to 0 (or 1 for Lua) -based indexing!
Is that video game character walking 100 yards? Or maybe the character is 500 feet tall and he's walking 50 leagues?
I'm hoping they know that the language's name comes from FORmula TRANslator...
Imagine trying to keep track of pounds in a single set of equations using subscripts m and f to differentiate between the units’ use for both mass and force.
> The program requires a minimum of a 12MHz 80286, 1MB RAM, DOS 5.0 or DR DOS, one 1.2MB 5 1⁄4" or 1.44MB 3 1⁄2" disk drive, hard drive with 11MB of free disk space, and VGA graphics. In addition, Falcon3.O supports a joystick, a joystick with a throttle, dual joysticks, rudder pedals or the ThrustMaster controls. The game also supports a mouse and various sound cards, including the Ad Lib, Sound Blaster and Roland. The 80x87 math coprocessor is supported for the HighFidelity flight model.
> Optimal system requirements are a 20MHz 80386 system or faster, 80x87 math coprocessor, 4MB RAM with EMS (expanded memory), DOS 5.0 or DR DOS, one 1.2MB 51⁄411 or 1.44MB 31⁄2" disk drive, hard drive with 11MB of free space, a 16-bit VGA card, a mouse and a joystick.
* https://vtda.org/docs/computing/SpectrumHolobyte/Falcon_3.0_...
* https://en.wikipedia.org/wiki/Falcon_3.0
"Wow!" we thought at the time.
When I was elementary school age in the late 70s, I'd go into her office with her sometimes on school holidays that were not work holidays. She'd let me play Colossal Cave Adventure on a terminal in her office. I remember looking at printouts of code she was working on, and seeing a wireframe diagram of some futuristic plane. I think it must have been one of the first Stealth fighters. I wonder how many security protocols she broke by having me there... :)
She passed a way many years ago, but I think she would have been excited to see work like this.
Air density can become pliable, controllable. Thrust velocities match projectile spec velocities (m/s) making calculating intersect a breeze. Trust me, you want to convert the FORTRAN math into standard metric. They didn't believe in Base10 back then so do the math.
I wanted to keep the data tables exactly the same in the C# translation. While formulas can be converted to metric easily, the data tables do not actually have units defined for any of them, so translating them to metric is non-trivial. And the way data is mixed from multiple tables is very complex. So verifying that the calculations have equivalent results in metric is well beyond my ability.
Or rather, the best way to verify it would be to write a flight model that uses customary units (what I describe in the article), and then use that to verify that the metric flight model is equivalent.
At the end of the day, only the inputs and outputs of the flight model need to be converted, which is just handful of multiplication operations. The flight model is very cheap to run, even with conversions at runtime.
Aircraft altimeters are based on air pressure. The reference pressure is variable based on atmospheric conditions and is decided by controllers, or in the case of uncontrolled airspace, the matching the altimeter of the known altitude that you took off from.
All that is to say, on my home (uncontrolled) airport which is ~10 feet above sea level, I occasionally land at a negative altimeter value since the weather conditions have changed while I am in the air.
Assuming that an altimeter reading must be positive is a bad assumption.
In rust I'm familiar with https://docs.rs/uom/latest/uom/ and typescript I've seen safe-units https://jscheiny.github.io/safe-units/ used.
In my experience in both the aerospace industry and the video game industry, there are no tools like this in use. In aerospace specifically, errors like that are caught by manual human review, including third-party validation companies. Unit tests are used to sanity check every calculation. And finally, everything is run in a flight simulator before ever going onto a real aircraft.
In video games however, it's the wild west. Math errors there are funny, not deadly.
Modern fortran has a bit more modern flavour to it, but formulae being so verbose would make the "formula" aspect of a code disappear.
I later added the high fidelity flight dynamics model by translating C code.
https://github.com/kristoffer-dyrkorn/flightsimulator
In the words of Jerry Maguire: "You had me at hello."
This early sentence really hooked me:
My favourite part: The image comparing X/Y/Z axis between different 3D modelling products: https://vazgriz.com/wp-content/uploads/2025/05/EmVSW5AW8AAoD...Plus the comment below can make you laugh hard enough to get Coca Cola up your nose!
I know it's fashionable in some circles to dump on everything non-metric, but these things are they way they are because of reasons, and airspeed is generally measured in either knots or Mach.
I'm just annoyed that so many educational resources and even flight code still use customary units for everything. I believe that metric should be used for all internal calculations and knots should only exist at the UI layer for the pilot.
When I play flight games though, I only have intuition for speed in terms of knots. Like 150 kts is takeoff speed and 400 kts is the corner speed.
I just think that the pilot letting out a spool of knotted rope from their plane is a very silly practice to defend :)
A serious spacecraft simulator. Likewise developed from ancient FORTRAN code, in this case ported to C.
I am pretty firmly in the Z-up camp, I mean I understand the Y-up camp, take a normal picture, or perhaps a side-scroller game, Y is up and down, the logical extension to three dimensions is to push z as depth. But I can't do it, I see X and Y as a in a map where the obvious Z direction is up and down. yes minecraft triggers me so hard, don't even get me started.
PS: The time for SMRs was 40 years ago. Renewables radically transformed the economics such that only fusion reactors, geothermal, and tidal are part of a short list of viable alternatives because fossil fuels and fission need to go the way of whale oil and hunting passenger pigeons.