Coordinates and Rects

How exactly does the default coordinate system work?

I would expect integer coordinates to refer to between the pixels. E.g. (0,0) would refer to the bottom left corner of the screen and the bottom left pixel is a rectangle from (0,0) to (0,1).

However, when I draw a rect with integer coordinates, I get a dim line of pixels around the edge. I assume this is because my rect is not actually pixel-aligned and antialiasing is affecting nearby pixels.

So, what should an integer coordinate refer to? Between a pixel? Or the middle of a pixel?

I find the latter choice to be quite inconvenient but I can always start drawing by doing translate(-0.5, -0.5) to get everything pixel-aligned again.

Also, if I draw two rects as follows:

noStroke()
rectMode(CORNER)
rect(0,0,8,8)
rect(8,0,8,8)

I’d expect the two rectangles to abut andtherefore to see a single rectangle 16 pixels wide.

However, Codea leaves a pixel of space between them. I have to pad my widths/heights by one to get rectangles to abut properly.

Is there a fencepost error in the rectangle drawing routine?

The coordinates refer to the outer border of the antialiased edge of the rect.

From a technical perspective the coordinates define the positions of the vertices of the quad that are then shaded with the appropriate shape. So a smooth() rect() will use the antialiased rect shader, which will antialias in from the edges of the quad.

I’m open to adjusting this in future versions, i.e. padding out the vertex locations to make things adjoin properly with antialiasing.

Ah, so for pixel-aligned axis-aligned rects, I should turn smooth off?

Yes, that will fill them all the way to the border (they are also faster to render). See the Noise example project for an example of rects tiling the screen with no gap.