Log In  

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:
[8x8]

Running

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

Results in:
[8x8]

Shifting them apart results in this:
[8x8]

When the expected result should be:
[8x8]

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

P#74950 2020-04-19 01:18

3

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
P#74968 2020-04-19 13:10
:: zep
4

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.

P#75084 2020-04-21 00:34 ( Edited 2020-04-21 01:09)

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)

P#75100 2020-04-21 06:00

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

P#75102 2020-04-21 07:51
:: Felice

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)

P#75132 2020-04-21 18:40

[Please log in to post a comment]

Follow Lexaloffle:        
Generated 2020-10-28 08:18 | 0.013s | 4194k | Q:23