Log In  


tline3d misses sub-pixel precision and generate incorrect samples at borders.

note: tline3d adheres to the (correct) rule of filling [x0//1;x1//1[

how to reproduce:

  • run attached cart
  • left: per pixel
  • right: tline3d
  • notice border artifacts & texture wobbling

Cart #satanebika-2 | 2024-04-11 | Embed ▽ | License: CC4-BY-NC-SA
8

8


1

tline3d also doesn't sample from the UV properly when the UV's size isn't a power of 2. Recreation cart below:

Cart #sotugifoyu-0 | 2024-04-13 | Embed ▽ | License: CC4-BY-NC-SA
1

Explanation of what you're seeing:

  • drawing a 8x8 sprite with 8 tline3d calls (one call per row)
  • drawing a 5x5 sprite with 5 tline3d calls (one call per row)

the second sprite is not sampling the UV properly because the extents of the sprite are not a power of 2.


5

Very nice, thanks @freds72 -- I've added a flag 0x200 for 0.1.0f as the last argument tline3d() to perform that correction for horizontal or vertical spans. I'm using 16:16 ints in the inner loop, but it is almost pixel-identical to your example.

It might become default behaviour later on when I can get into it deeper, or at the very least it will be possible to specify the default flags value (e.g. tline3d(0x300) -- similar to setting PICO-8's tline precision). There is already a flag in 0.1.0e to do the [x0//1;x1//1[ fill, which was added to address related shortcomings. Again, that might also become the default -- I haven't come across a situation yet where using the same fill behaviour as line() is really needed, except that it superficially seems more intuitive that tline() and line() match in that regard.

@fletch_pico n^2 texture sizes is a limitation of tline3d; although I might consider a slightly slower path for arbitrary sizes if that limitation proves too annoying. (And of course, it will be in the manual soon to avoid that confusion!)


thanks - these gaps were haunting me at night 😜



[Please log in to post a comment]