Board Thread:Questions and Answers/@comment-25526539-20150226010925/@comment-24577221-20150228230315

Interesting. I wonder if anyone over there actually understood what was going on? It appears that Myles didn't.

I'm afraid that it's rather obvious to an experienced programmer.

For starters, please note that the number 2,147,415,557 is displayed just fine. The problem has nothing to do with a leading '1' being thinner than a leading '2'.

The "number" displayed in that MSM game was ".,/,),-'*,./'".

The variable used to store the number of coins is a signed 32-bit value. After the value goes past 2,147,483,647 it essentially rolls over to a negative value, such as — in the case of that MSM game image — -2,147,396,219.

When the number is being displayed, the code that draws the digits calculates each digit in succession by getting a remainder by dividing the previous amount by 10. Then each remainder digit is added to the character '0'. If the remainder is 1, that added to the character '0' gives the character '1', and so on, in the most common character representations used at present.

After the value rolls over into negative values, by the calculation they're doing, each remainder comes out negative. Then that negative value is added to the character '0', giving the characters that precede '0'... which are the punctuation symbols you see. -2 added to '0' gives the period/decimal point. -1 added to '0' gives the '/' character. -4 added to '0' gives the comma, and so on.

The problem could be postponed by using an unsigned 32-bit value, instead of a signed value, for the number of coins. Then the maximum value would be 4,294,967,296, before rolling over to 0. It could be solved completely (apart from the displayed font getting too small for good display on low-resolution devices) by switching to a 64-bit value.