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:
Shifting them apart results in this:
When the expected result should be:
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.
[Please log in to post a comment]