tline() seems to behave differently than line(), and the default delta seems to not work. It seems that the ending y coordinate is off by one pixel, but I'm not sure if there's more wrong than just that. I would expect line() and tline() to make the same line, though. On top of that, it seems that it's using 0,0 for the default delta instead of 1/8,0 like the manual specifies.

For example, with this tile at 0,0 on the map:

	[0x0]

Running

 tline(32,32,39,35,0,0)
 line(32,32,39,35,7)

Results in:

	[0x0]

Shifting them apart results in this:

	[0x0]

When the expected result should be:

	[0x0]

You can get the expected tline() result instead with tline(32,32,39,36,0,0,1/8,0)

It’s not documented AFAIK, but tline() understands sub-pixel coordinates. If you need to reproduce line() behaviour you’ll need to position the start and end points at the centre of the pixel. The following code works for me:

function tline2(x0,y0,x1,y1,sx,sy,dw,dh)
  tline(x0\1+.5,y0\1+.5,x1\1+.5,y1\1+.5,sx,sy,dw,dh)
end

This is indeed the reason for the difference in behaviour, but I think I made a mistake here.

The original reason for it was just to be low-level and to give authors that option, but I'm getting the feeling there's not much utility in having it available, and so not worth the extra confusion / messiness. The powerful part of tline is being able to specify arbitrary texture position and delta (unlike sspr). And when doing sub-pixel texturing for example, you'd normally tweak the texture coordinates; not the screen ones. In an example like this (2:1) for rendering isometric tiles and whatnot, you don't really want to have to grok or work with an additional coordinate scheme.

So, I'm considering to reverting to line()'s behaviour in 0.2.0d (which is arriving shortly). I haven't seen anyone using the subpixel coordinates, and can't imagine a compelling use-case example, so I think it's unlikely to cause breakage.

I do use subpixel but didn’t rely on tline to do so.
For 3d, you need to shift also the z part so in any case doing that in user code is better.

That said, having a sub-pixel line alternative is interesting (ex for a wireframe game)

I think we’ll be fine without subpixel-aware tline(); if really necessary it can be emulated using clip().

I'd also agree that having a sub-pixel version of line() is useful. People moving from line() to tline() already have to have a certain level of knowledge and can probably deal with the difference, as long as they are forewarned by the docs. (hint, hint)