Original code bug object animation hash

[Pyrdacor]

There is a bug in original code where the hash for random object animations is precalculated. Instead of reading the map width with Map_width(a0), it just directly uses Map_width as a value which is an offset and has value 4. See:

https://github.com/jhorneman/ambermoon/blob/52e36804e1f211330d884a79ecc5559138c4974d/src/MAP/3D_MAP.S#L2500

[Pyrdacor]

Not sure if this matters or what influence this actually has. Just found it while investigated stuff for AA.

[Pyrdacor]

Some background. For normal 3D objects (non-NPCs) there is some hash value which is used for random animations (if the flag bit is set). The hash is first calculated as tileX + tileY * mapWidth (at least after the fix). This is done per tile to have some base value.

Then for each object, to this base value the relative object X, Y and Z values are added.

Based on animation type (wave or circle) there are some lists of words. The first word is added to the total hash value and then ANDed with $f. This is then used as a bit index to check if the bit is set in the second word. And if so, the frame is changed.

Hard to determine the effects.

[a1exh]

Do you think it might correspond to any of the previously reported graphical bugs in the Amiga version of Ambermoon?

[Pyrdacor]

I don't think so. This just is a hash used to decide if the frame is increased or not. The frames themselves are intact. It just influences how fast or often animations happen.

I am not sure if this is notable at all. Most likely not.

It was just a lucky catch.