So, it seems that these triangles are painted in vertical stripes, something like this:
The system iterates through each vertical stripe of pixels, which contains some part of the triangle. It finds the two edges of the triangle which intersect this stripe. It gets the Y-coordinate where each triangle edge intersects the vertical stripe of pixels. It paints all the pixels in the vertical stripe, between those Y coordinates.
Now, the problem is when the system calculates the Y-coordinate where the stripe of pixels intersects a triangle edge. If it intersects the triangle edge at Y=33279, everything is fine... if it intersects the triangle edge at Y=33280, it actually uses the Y value of -32256 (which is 65536 below what it should be... giving a hint about the bug to those who know their powers of 2). If the Y value is above 33279, then the Y value actually used is 65536 less, or 65536*2 less, or 65536*3 less, whatever brings it into the range -32256 to 33279. (This is the range of a signed 16-bit integer, -32768 to 32767, shifted positive by 512). If the Y value is below -32256, then 65536 is added to it until it comes into that range.
So, the Y coordinate of the steep triangle edge gets greater and greater, going down further, until it gets out of range for some internal calculations - like a speedometer rolling over, except it rolls back to a negative number, it begins counting from the other extreme, very high up above the screen, keeps going down, then passes the visible coordinates again so it's off the bottom of the screen, etc.. The greater the Y coordinate of the extreme triangle vertex, the more times the odometer will 'roll over', the more times the calculated intersection Y value will go from far below the bottom of the screen to far above the top, the more stripes there will be.
For the record, I have notified SmileBoom of this bug, giving them the link to this page.
