#687 DRAW doesn't remember subpixel positions

[Matthew]

As seen in http://www.freebasic.net/forum/viewtopic.php?f=17&t=21380.
Example:

DIM i AS INTEGER
DIM drawcmd AS STRING

drawcmd = "bm320,240"

FOR i = 0 TO 359
  drawcmd = drawcmd + "ta" + STR$(i) + "u"
NEXT i


SCREEN 12
DRAW drawcmd
SLEEP

With this code, QB draws a circle but FB draws a rough octagon.
In general, QB remembers the subpixel position within and between DRAW calls, unless another drawing routine resets the pen position. FB always stores the integer pen position in pixels, and forgets the subpixel position immediately after a drawing command.

[dkl]

Fixed by [1fc09b]

[dkl]

It looks like the fix introduced a regression (or exposed another issue):

http://www.freebasic.net/forum/viewtopic.php?p=201990#p201990

screen 12

draw "BR20 BD20 G4 H4"

line (20, 36) - (16, 40)
line (16, 40) - (12, 36)

sleep

The DRAW's G and H commands (for drawing diagonal lines down+left and up+left) seem to have rounding issues; they produce "steps" instead of a clean diagonal line of pixels. For comparison, the two LINE commands show what the DRAW should have produced.

It seems to be context-sensitive; for example, with this DRAW, G works ok, but H still has the issue:

screen 12

draw "BM20,20 G4 H4"

line (20, 36) - (16, 40)
line (16, 40) - (12, 36)

sleep

[Matthew]

The regression was caused partly by the inefficient way DRAW drew such lines, and partly I think by the way "BMx,y" added 0.5 to the coordinates, which could easily round either way given slight subpixel fluctuations. Both are fixed now in [e39293].