CIRCLE has a spike

[alochmann]

Test Environment

• Platform: MEGA65, xemu
• ROM Release: 920414, 920413, but not 920395
• Core Commit: fc8e361

Describe the bug
A solid CIRCLE shows a pronounced spike on 920414 and 920413, but not 920395.

To Reproduce
Run a program like the following:
10 SCREEN 320, 200, 1
20 CIRCLE 100, 100, 50, 1
30 GETKEY A
40 SCREEN CLOSE
The left and right side are not symmetric, and the asymmetry is much more pronounced than in 920395:

Expected behavior
The circle should be symmetrical.

Additional context
This bug is very similar to the previous bug report "CIRCLE does not cover its border" (issue #225), but technically it must be a different bug, because it did not appear in 920395, in contrast to "CIRCLE does not cover its border". However, both bugs can probably be fixed with the same commit. Sorry if I should have written this as a single report, I was really unsure.

There is one more interesting observation: While a CIRCLE border still is symmetrical and looks okay, its shape slightly changed between 920395 and 920413: The circle drawn by
CIRCLE 100, 100, 50, 0
is flat on its sides in 920395; but in 920413, it has single pixels on its left, right, top, and bottom sides. While still okay, I think the 920395 version looks more circular.

[dansanderson]

The differences between the ROM versions are likely explained by the fact that INT() was fixed recently. CIRCLE uses trigonometric functions, which expect INT() to act like floor for negative numbers. This was broken a few years ago and didn't get noticed until recently.

I have doubts that every circle drawn by this command could be perfectly symmetrical given inherent inaccuracies in floating point math and the quantization of circle coordinates to pixels. Ideas welcome.

[alochmann]

I agree with your hypothesis that INT() is at work again.

A perfect rotational symmetry cannot happen, you are right. I meant symmetrical about the x- and y-axis, and the two diagonals. Given that the circle border exhibits these symmetries, the solid circle should easily be able to do this too. I suggest to first take a look at rounding, to recreate the state of 920395 (with border and body of the circle). Then to analyze why border and body are drawn differently on their right sides in the first place (issue #225, maybe just some off-by-one?), and "copy" the calculations of the border to the solid circle. In theory, this should fix both issues.

[dansanderson]

See #225 for a demonstration that the filled circle is coming up a tad short on the right side, producing the asymmetry. It does not exactly cover an unfilled circle of the same dimensions and position, which is getting the edge correct.