Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Translating a Fortran F-16 Simulator to Unity3D

vazgriz.com

Post reply on HN
Print view View original

61–70 of 129 posts

Re: Translating a Fortran F-16 Simulator to Unity3D

#61

Post by q3k »

ForHackernews wrote: post #60
q3k wrote: post #50

Earlier quoted context omitted.

Gravity doesn't scale this way. Earth's gravitational pull (~10m/s^2) is a constant that ties distance to time, so if you want to observe the same gravitational effects in the same gravitational pull on a small dimensional scale, you need to adjust the time scale to compensate. This is why scale model sets for practical VFX in cinema were always recorded at higher frame rates and then played back slower.

That's only a problem if you're dealing with real gravity shooting real models in a real physical world. In a simulation, you can set G to whatever it needs to be. The acceleration defined to simulate gravity in this Fortran code is presumably already proportional to everything else defined in the simulation.

Right, but that's more effort than just using real units in the first place.

Re: Translating a Fortran F-16 Simulator to Unity3D

#62

Post by gsck »

teamonkey wrote: post #42
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!

Lua actually has arbitrary indexing, it's just that some iterator functions in the standard library assume arrays begin at 1.

It does and doesn't. You can have any arbitrary index, but that changes the table from being an array to being both an array and a dictionary, some real weird Frankenstein stuff

Re: Translating a Fortran F-16 Simulator to Unity3D

#63

Post by noobermin »

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.

Re: Translating a Fortran F-16 Simulator to Unity3D

#64

Post by JunkDNA »

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 have fond memories of playing the original Falcon on my Amiga 500. It felt like magic after years of playing F15 Strike Eagle on the Apple IIc. Hearing real sound effects kicking in the afterburner and getting too close to the ground ("Pull Up! Pull Up!") were all so satisfying.

I remember being so excited when Falcon 3.0 came out. But it just felt like a let down. The graphics were amazing for the time and it seemed so realistic, but for me the realism is what killed all the fun. As a kid, I didn't actually want to BE an expert F16 pilot. I just wanted to feel like I was. I didn't want to have to learn all the systems and controls.

Re: Translating a Fortran F-16 Simulator to Unity3D

#66

Post by bentt »

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…

Yeah the HIGH FIDELITY FLIGHT MODEL required that math co processor. When you turned it on it felt like you had tapped into the WOPR from Wargames!

Re: Translating a Fortran F-16 Simulator to Unity3D

#67

Post by Joker_vD »

zabzonk wrote: post #54
chillfox wrote: post #28

Earlier quoted context omitted.

I think it's down to personal preferences/how you think. I haven't actually used any languages that didn't have 0 based indexing, but I remember it being very painful and super unintuitive to learn, it just didn't make sense at all (still doesn't, but it's not a problem for me anymore). I always thought 1 based would make a lot more sense and be way easier to learn.

I would say it is sensible. Given that an array index is an unsigned integer, what are you going to do with an index of zero? Perhaps I've been influenced by writing a lot of code in assembler, way back when, but zero-based has always seemed completely natural to me, to the extent that I find it very hard to understand algorithms expressed in non-zero based code.

An array index can be signed with no problem. If you're worried about the address calculations, well, the address of an array doesn't have to be the address to its initial element, does it? It can be the address of the element with index 0 (even if an array does not have such an index at all):

    arr: array[-2..10] of integer;

    pointer(@arr) == pointer(@arr[0])
Or you can use descriptors (dope vectors), but that involves quite an overhead. The books on compilers from the 70s (e.g. Gries's "Compiler construction for digital computers") have rather extensive discussions on both approaches.

Re: Translating a Fortran F-16 Simulator to Unity3D

#68

Post by qmr »

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…

Falcon 4.0 source code leak led to Falcon BMS, still actively developed today.

Re: Translating a Fortran F-16 Simulator to Unity3D

#69

Post by colechristensen »

noobermin wrote: post #63

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

Math or engineering people do not have problems with short symbol names, that's it. Also our formulas are complex. If you wrote out many of our formulas with long descriptive variable names the structure and relation between the variables would no longer be readable, there would be many more mistakes.

We were educated doing these things on paper with pages and pages of math with these symbols.

20 years later I can still read just this fortran code and guess most of what's going on with no context needed.

I have problems reading "developer code" that boil down to "where the hell is the part of the code that actually does something?!" being perpetually lost in layer among layer of abstraction with the relevant connecting pieces far far apart.

Re: Translating a Fortran F-16 Simulator to Unity3D

#70

Post by colechristensen »

btrettel wrote: post #57
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.

In practice, unit checking is almost never done on actual code, though it should be done. From what I recall, some Fortran folks have been trying to get unit checking into the Fortran standard itself since the 1970s without success. I was able to coerce Fortran's type system into checking units, but it comes with quite a few downsides: https://fortran-lang.discourse.group/t/compile-time-unit-che... An approach based…

Elaborate typing is what Ada was for.
Post reply on HN