I have now carried out a fairly exhaustive analysis of that part of the assembler code which affects the wind speed, as identified by H.sie.
1. I can confirm H.sie's original finding, that under certain circumstances windspeeds of up to 30 m/s can be reached within this part of the code, due to a strange implementation of wind speed changes. This over-speed is limited by a simple filter to 15 m/s (as H.sie has already explained.)
2. The overflow of wind speed occurs when a high existing windspeed, say 13 m/s, is supplemented with a random result of around 0.8 or higher. (The value of the triggering random number to cause the overflow depends on the previous wind speed, obviously.) I could force overflow windspeeds of up to 29 m/s by artificially altering the start wind-speed value and the result delivered from the random generator.
3. The random generating algorithm creates a floating-point number between -1 and +1. These numbers are generated by the standard Microsoft randomising software algorithm (taking numbers from a published equation), and the results depend rather critically on the seed that is set for the algorithm. I discovered that the generator was providing clusters of similar random results over several calls. The custom is to set this random generator with a time seed at program start time, and then to keep taking subsequent random numbers with each call to the algorithm, so my observation might just have been a coincidence.
4. The wind-speed change code is very peculiar about handling negative numbers from the random generator. Why not just make negative numbers positive? Probably there is a reason, but it is not obvious.
5. The code which calls Microsoft's random generator is set in its own subroutine, and is certainly called by other SH3 routines. Therefore:
*It is essential not to alter this code in the randomising routine* (EnvAct.sim + 3290h). (That is, this subroutine must continue to deliver the same results, however seeded or limited.)
6. The obvious solution to the wind-speed problem is to scale the final output value (esi + 03D4h) before the limiter is reached. The scaling process should take the output value 'windspeed' and - for ALL values - scale it according to the formula:
windspeed = (windspeed * 15.00) / 30.00 ; 30 is the maximum that can be reached.
In other words, just divide the value by 2.
This will not only solve the problem of the overflows, but it will result in generally lower wind speeds, making storms rare. It is also simple to code!
There is certainly another consideration, that the bug occurs only rarely (but it is then persistent, since at 15 m/s already, a much lower random number suffices to cause an overflow of the windspeed). So perhaps use of the scaling factor should be restricted only for when the output wind speed would exceed 15 m/s, before use of the existing limiter.
7. And finally, we should prevent persistent high wind speeds, due to bug or an unhappy coincidence of high numbers from the random generator, with a return to some kind of default value as I have previously described in an earlier post - a 'repeat delimiter' reached after high wind speeds have persisted after too many calls to the general weather code. (I agree with others that a default wind speed of 6 m/s would be better than 0.)
This all looks fairly easy to code (especially for H.sie
). Just a jump from near the end of the windspeed routine (envsim.act + DDBE) to new code placed at the end of envsim.act, and then a jump back to (envsim.act + DDD7), returning the corrected windspeed in the eax register. (Better still, why not store the final new wind speed value in [esi + 03d4h] and jump to the beginning of the next part of the code at (envsim.act + DDDD)?) The same new code can contain the repeat-limiter described in (7) above.
Having said all that, probably the easiest solution of all is to use the repeat-limiter of (7) above all by itself. It rather depends on what users really want - a corrected algorithm or a simpler fudged solution.
Stiebler.