Interesting. I know this is a purely academic question as these constraints are something of the past, but was it really necessary to have 16 bits for the velocity? Was the ratio between the quickest and the slowest objects more than 256 times?
As kevin_thibedeau noted, the bit twiddling instructions available were limited. The Intellivision used a GI 1600. Here's a copy of the manual [1] and a Wikipedia article about it [2]. It can shift or rotate by 1 or 2.
But you are right--a game might not need 16 bits for velocity. Suppose a game needed a maximum of just under 4 pixels/frame X velocity and needed a minimum of 1/64 pixel/frame.
It could have stored velocity in one byte like this FFFFFFII where the Fs are the bits of the fractional part of the velocity in units of 1/64 pixels/frame and the Is are the integer part in pixels/frame. By putting the fractional part in the upper bits and the integer part in the lower bits no shifting will be required--just AND and OR.
Then updating X would be something like this:
X += Vx % 0x0003
if Vx > (random_unsigned_byte() | 0x0003)
X += 1
You probably could even skip the OR. It makes no difference if the integer portion of velocity is 0. If the integer part is 1 skipping the OR in effect increases the velocity by 1/256 pixels/frame. Similarly if the integer velocity is 2 or 3 skipping the OR increase it by 2/256 or 3/256 pixels/frame, respectively.
I don't think anyone would notice. For two objects in a race all the way across the screen with the same Vx, with one including the OR and one not, my back of the envelope calculation says that the speed boost would only get that one to the finish line less than half a millisecond earlier.
On 8-bit micros without a barrel shifter you'd naturally want to constrain number formats to byte boundaries. Much better to have excess fractional precision than deal with extra bit twiddling. Even with 16-bit Intellivision, the scarcity of RAM would drive the use of the smallest practical representation.
