Krishty’s Sim Forums

The EF2000 terrain tiles are not semi-randomly rotated, as they are in the original game.

This has been requested since ca. 2015 …

It leads to interesting problems like this one:


I figured out the randomization some time ago; we should finally implement it.

I have a prototype running. Looks much better. Before:


After:


Now the hard part … checking if it actually like EF2000’s, and finding the error if it is not …

Yeah, it was wrong. But now it isn’t any more!

So the random number generator in EF2000 is pretty simple. It has a state of 2×16 bits:

  struct RNG {
    uint16_t a;
    uint16_t b;
  };

It is usually initialized with π as a binary-coded decimal:

  RNG foo = { 0x3141, 0x5926 };

The function to generate the next number is extremely easy in assembler – just two instructions:

  ADD rng.a, rng.b
  ADC rng.b, rng.a

This is, however, add-with-carry-on-overflow on 16-bit numbers, so it’s hard to write in C (or any other language for that matter). Let’s define a function bool addWithCarry(uint16_t * result, uint16_t a, uint16_t b, bool carryIn). It

• adds a and b
• adds 1 if carryIn == true (i.e. carry flag set on entry)
• stores the sum in result and
• returns true iff the addition was overflowing (i.e. the carry flag is set on exit).

Then the function body becomes

  // Returns the next pseudorandom number.
  uint16_t next(RNG * rng) {
    uint16_t a = rng->a;
    uint16_t b = rng->b;
    addWithCarry(&b, b, a, addWithCarry(&a, a, b, false));
    rng->a = a;
    rng->b = b;
    if(0 == (a | b)) { // Burnt through all entropy? Reset!
      rng->a = 0x3141;
      rng->b = 0x5926;
    }
    return a;
  }

The implementation of addWithCarry() can be as simple and inefficient or as complex and efficient as you want it to. I use the _addcarry_u16() intrinsic on MSVC and the code actually compiles to the same ADD-ADC chain found in the disassembly.

Here is a test case for verification: After next(foo), the state should have changed to { 0x8a67, 0xe38d } and then to { 0x6df4, 0x5182 }.

I compared the result with one of damson’s gameplay videos and the little islands now match perfectly.

Of note: This pseudorandom number generator is also used by TAW to encrypt the pilot log, and by ADF to encrypt the Quick Combat high score. And it is used in many more places.

If we search old EXEs for the magic numbers 0x3141 and 0x5926, I’m sure we will find many more uses of it.

Needless to say, this will be in the next update.

Great work!

So, the chances are that TAW's terrain randomization, such as it is, uses the same algorithm.

From what I remember, TAW has 4 or 5 tiles with extra textures for randomization, but those textures are all the same, resulting in a net zero effect.
TAW2.30 has 5 sea tiles, so that would be better for checking..

The randomization works a bit different in TAW than in EF2000 (.lst files instead of .dat) … not 100 % there yet

This turned out way larger than originally anticipated, but the feature has finally landed.

Both EF2000 and TAW seem to be working properly now.

Twelve years after we decided we should do that.

Well, you ve done it properly.

At least for TAW, we could have just used any psuedo-random algorithm.

Now that you mention it:

mikew wrote: ↑2024-Mar-31, 08:33From what I remember, TAW has 4 or 5 tiles with extra textures for randomization, but those textures are all the same, resulting in a net zero effect.
TAW2.30 has 5 sea tiles, so that would be better for checking..

Could this have to do with the moving map? The moving map is not randomized. So if you chose a tile with a different texture in the terrain, it would show up with the original texture on the moving map, possibly leading to confusion.

In EF2000 confusion would be guaranteed, as you would see one single isle on the moving map but three small isles ahead of you.

Maybe that’s the reason EF2000 has rather strong randomization while TAW uses the same textures for everything 🤷‍♂️

Maybe, but TAW doesn't have rotations, and the only tiles that randomized are flat terrain for the most part. Certainly, no tiles with buildings on them are randomized.
The general idea was probably to give a bit more variation when flying over the desert, but not enough variation to affect the map.