Translating a Fortran F-16 Simulator to Unity3D • Hacker News Board

Re: Translating a Fortran F-16 Simulator to Unity3D

#111

Post by HeyLaughingBoy » Fri, Sep 26, 2025, 6:59 PM UTC

throw0101c wrote: post #34

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…

I remember the opposite also. We used to play a lot of Robotron on my roommate's 8086 PC clone. Then he was so excited to upgrade to a '286. Robotron became unplayable. My guess is that it was coded with a lot of busy loops because it was so insanely fast on the 286 that a human simply didn't have time to respond.

I guess they probably came up with a new version, dunno.

Re: Translating a Fortran F-16 Simulator to Unity3D

#112

Post by somat » Fri, Sep 26, 2025, 7:40 PM UTC

On the subject of coordinate axis.

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.

Re: Translating a Fortran F-16 Simulator to Unity3D

#113

Post by evntdrvn » Fri, Sep 26, 2025, 8:36 PM UTC

danbruc wrote: post #29

JSR_FDED wrote: post #6

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

.NET supports this because [Visual] Basic supports it. This can be used from C# - and other languages - but there is no nice syntax supporting it. // This also supports multidimensional arrays, that is why the parameters are arrays. var array = Array.CreateInstance(elementType: typeof(Int32), lengths: [ 5 ], lowerBounds: [ -2 ]); // This does not compile, the type is Int32[*], not Int32[]. // Console.WriteLine(array[…

TIL thanks!

Re: Translating a Fortran F-16 Simulator to Unity3D

#114

Post by pmarreck » Fri, Sep 26, 2025, 8:52 PM UTC

reactordev wrote: post #52

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 pliabl…

I was going to say this! Why not just convert all the constants and units once since the mathematical relationships are the same?

Re: Translating a Fortran F-16 Simulator to Unity3D

#115

Post by saltcured » Fri, Sep 26, 2025, 9:19 PM UTC

HeyLaughingBoy wrote: post #111

throw0101c wrote: post #34

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…

I remember the opposite also. We used to play a lot of Robotron on my roommate's 8086 PC clone. Then he was so excited to upgrade to a '286. Robotron became unplayable. My guess is that it was coded with a lot of busy loops because it was so insanely fast on the 286 that a human simply didn't have time to respond. I guess they probably came up with a new version, dunno.

This is actually the reason we had "turbo" buttons on PCs back then. It wasn't to overclock. Instead, it was to underclock to some backward-compatible CPU speed that would allow legacy software like that to hopefully work OK.

However, I'm not sure how many different compatibility models were being targeted.

Re: Translating a Fortran F-16 Simulator to Unity3D

#116

Post by HeyLaughingBoy » Fri, Sep 26, 2025, 9:33 PM UTC

arnsholt wrote: post #5

kataklasm wrote: post #3

Earlier quoted context omitted.

The whole imperial/British side has tons of ugly and weird units of measure. Reading old engineering documentation will give you headaches and nightmares from all the inconsistent systems of units.

My favourite one was when I learned about the existence of US survey feet.

My property is very irregularly shaped with the longest straight dimension being 6" shy of a quarter mile. The really scary thing is that I recognized that immediately the first time I looked at the property survey map.

Re: Translating a Fortran F-16 Simulator to Unity3D

#117

Post by burnt-resistor » Sat, Sep 27, 2025, 12:13 AM UTC

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.

Re: Translating a Fortran F-16 Simulator to Unity3D

#118

Post by dghlsakjg » Sat, Sep 27, 2025, 1:17 AM UTC

kjellsbells wrote: post #53

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.

Re: Translating a Fortran F-16 Simulator to Unity3D

#119

Post by dghlsakjg » Sat, Sep 27, 2025, 1:21 AM UTC

imp0cat wrote: post #2

The "UNITS" part is wonderful. I had no idea slugs even existed. You want to measure how much air mass is in a given volume? That’s gonna be slugs/ft3.

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.

Re: Translating a Fortran F-16 Simulator to Unity3D

#120

Post by hdkgijtkr » Sat, Sep 27, 2025, 2:48 AM UTC

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.