It's difficult to be (at all) certain without looking at the code, but it kind of sounds like it's implementing fixed-point arithmetic, with 12 bits before the decimal point, and 20 bits after.
When/if you multiply two of these together, you need to do a right shift to get the result back to the right representation. That is, each input is a total of 32 bits, so when you multiply them, the result will obviously be 64 bits, and you want to keep 32 bits of that. But you need to keep the correct 32 bits. Since you started with 20 bits of fraction and 12 bits of mantissa in the inputs, you'll get 40 bits of fraction and 24 bits of mantissa in the result. So you right shift by 20, and then keep the bottom 32 bits to get a 12:20 formatted result (and the more significant bits in the result had better be zero, or you've just overflowed what the result can represent).
Many people find it easier to think in terms of decimal. So let's consider a decimal representation where we can handle (say) -999.999 to +999.999, but store and manipulate them as integers.
So, to store a number, we start by multiplying it by 1000, so if we had (say) 123.456, we get 123'456. Now, if we add numbers like this, we don't have to do anything special. So, if we add 123'456 to 234'567, we get 358'023, which represents 358.023 (which is the right answer).
But if we multiply two of these numbers together, our result is a not what we'd want. For example, let's consider 2.2 x 2.3. In our format, that becomes 2'200 x 2'300. When we multiply those, we get 5'060'000, which converts to 5'060.000. Our result is too high by a factor of 1'000 (the same factor we're applying to a value to get it into our notation). So, to get the right answer following a multiplication, we need to shift it to the right by 3 decimal places, so we get 5'060, which converts to 5.06.
It sounds like the code you're looking at does pretty much the same thing, but instead of using a multiplier that's nice and even in decimal, it uses a multiplier that's nice and even in binary. That makes it easy for a binary computer to "fix" the result after a multiplication, by simply doing a right shift (whereas, dividing by a power of 10 would be relatively slow).
Looking a step further: why would they do this? I can see two obvious possibilities. The first and most obvious is sheer speed. Especially on a lot of older processors, it was fairly common for integer math to be substantially faster than floating point math.
The second possibility would be predictability. With fixed-point, you'd fundamentally doing integer math. Integer math is fairly simple and understandable. By contrast, if you use floating point math instead, you get into an area many people find somewhat mysterious. When people start out, they tend to think of floating point is being like a Real number in mathematics--but they quickly learn that the two aren't really the same, and the differences can be difficult to understand and often difficult for a beginner in the area to predict. By using fixed point (scaled integers) they can simply avoid that stuff that's unpredictable and hard to understand.