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

31–40 of 129 posts

Re: Translating a Fortran F-16 Simulator to Unity3D

#31

Post by CaptainOfCoit »

chillfox wrote: post #28
zabzonk wrote: post #18

Earlier quoted context omitted.

I'd agree with 1-based indexing problems, but not 0-based, which seems very natural. And if you have -2-based, I'd argue that perhaps you don't want an array.

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 wonder how many of the "off by one" issues/bugs we encounter in the wild are because of arrays typically using 0-based indexing vs 1-based indexing.

Re: Translating a Fortran F-16 Simulator to Unity3D

#32

Post by Karliss »

ForHackernews wrote: post #13

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?

Author is at least partially reusing Unity physics engine instead of using physics integrator from original simulation. It is not a mechanical 1:1 translation of Fortran code to C#. Once you start mixing the two sims units and other constants matter. Also the unity physics engine is finetuned for operating at certain scale with certain units. You could operate it in different units, but that will potentially require readjusting not just major physics constants but also a bunch of poorly documented magic parameters designed to prevent Unity sim from exploding or wasting resources.

Re: Translating a Fortran F-16 Simulator to Unity3D

#33

Post by arethuza »

chillfox wrote: post #28
zabzonk wrote: post #18

Earlier quoted context omitted.

I'd agree with 1-based indexing problems, but not 0-based, which seems very natural. And if you have -2-based, I'd argue that perhaps you don't want an array.

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 think encountering C arrays and pointers rewrote my brain so that 0 based indexing made more sense even though up to that point (~40 years ago) I'd only used languages that used 1 based indexing (Basic and Pascal).

Re: Translating a Fortran F-16 Simulator to Unity3D

#34

Post by throw0101c »

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.

* https://vtda.org/docs/computing/SpectrumHolobyte/Falcon_3.0_...

* https://en.wikipedia.org/wiki/Falcon_3.0

"Wow!" we thought at the time.

Re: Translating a Fortran F-16 Simulator to Unity3D

#36

Post by ForHackernews »

Karliss wrote: post #32
ForHackernews wrote: post #13

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?

Author is at least partially reusing Unity physics engine instead of using physics integrator from original simulation. It is not a mechanical 1:1 translation of Fortran code to C#. Once you start mixing the two sims units and other constants matter. Also the unity physics engine is finetuned for operating at certain scale with certain units. You could operate it in different units, but that will potentially require…

That makes sense, then. If he's porting between two different physics engines, not just putting a visualization layer on top of an existing simulation translated from Fortran to C#.

Re: Translating a Fortran F-16 Simulator to Unity3D

#37

Post by ForHackernews »

lloydatkinson wrote: post #25
ForHackernews wrote: post #23

Earlier quoted context omitted.

Ok but if you did a global find-replace for "meters" with "smoots" do you think that the simulated plane would crash?

Ah but smoots would still follow the same maths as a meter right?

Yes, that's how numbers work. 10 smoots + 1 smoot is 11 smoots.

That's the point of my question.

Re: Translating a Fortran F-16 Simulator to Unity3D

#38

Post by throw0101c »

alephnil wrote: post #19
jan_g wrote: post #4

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.

> 1 nautical mile equals to one minute in the 90 degrees hemisphere arc The nautical mile is not an SI unit, so it is not defined by a single organization, Your definition used to be the common definition, but it seems like the relevant organizations has updated the definition to be exactly 1852 m. If the original definition of the meter applies, then it would have been 1851.85 or 15 cm shorter, but with newer measur…

> The nautical mile is not an SI unit, so it is not defined by a single organization

"In 1929 the International Hydrographic Bureau obtained an agreement from a large number of countries to adopt a value of 1852 metres for the nautical mile, the unit thus defined to be called the International Nautical Mile."

* https://usma.org/laws-and-bills/adoption-of-international-na...

* https://en.wikipedia.org/wiki/International_Hydrographic_Org...

But there was no treaty or anything with a fancy ceremony, just a 'handshake', and so it was up to each country to adopt it with a domestic law or regulation, which (e.g.) the US did in 1954:

* https://usma.org/wp-content/uploads/2015/06/Nautical-Mile.pd...

Previously in the US it was 1853.25 m (because the US is actually metric "officially": all of its customary units (ft, oz) are defined in terms of metric equivalents):

* https://usma.org/laws-and-bills/mendenhall-order

Re: Translating a Fortran F-16 Simulator to Unity3D

#39

Post by flohofwoe »

mrheosuper wrote: post #21
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!

not sure why would i want that. Now to get the 3rd element from array, you have to know the start index, so another parameter to pass to function.

You might want the element at "position" 0 though (which with the origin at -2 would be the 3rd element). E.g. treat the array index as a coordinate in a 1D coordinate system with user-defined origin.
Post reply on HN