Tic-80: textri seems to be off by one on x axis

[ddelemeny]

Compiled from bbf4c6e on ubuntu

Expected behavior :

textri should not draw a tri outside of its edges plotted by line

Actual behavior :

it does

-- title:  Bug #1059
-- author: ddelemeny
-- desc:   off by one textri
-- script: lua

mytri = {150,50,185,55,163,120,8,0,15,0,15,8}
cls(0)
textri(table.unpack(mytri))
line(mytri[1],mytri[2],mytri[3],mytri[4],3)
line(mytri[3],mytri[4],mytri[5],mytri[6],3)
line(mytri[1],mytri[2],mytri[5],mytri[6],3)
function TIC() end

-- <TILES>
-- 001:7777777777777777777777777777777777777777777777777777777777777777
-- </TILES>

-- <PALETTE>
-- 000:1a1c2c5d275db13e53ef7d57ffcd75a7f07038b76425717929366f3b5dc941a6f673eff7f4f4f494b0c2566c86333c57
-- </PALETTE>

The following patch fixes it, but I'm not sure it's the best place to do it. Fixing ticTexLine would probably be better, but I haven't completely wrapped my head around the algorithm yet.

diff --git a/src/tic.c b/src/tic.c
index 152a3c1..6ac09bf 100644
--- a/src/tic.c
+++ b/src/tic.c
@@ -1134,7 +1134,7 @@ void tic_api_textri(tic_mem* memory, float x1, float y1, float x2, float y2, flo
                     const u8 *buffer = &ptr[tile << 5];
                     u8 color = tic_tool_peek4(buffer, (iu & 7) + ((iv & 7) << 3));
                     if (color != chroma)
-                        setPixel(machine, x, y, color);
+                        setPixel(machine, x+1, y, color);
                     u += dudxs;
                     v += dvdxs;
                 }
@@ -1150,7 +1150,7 @@ void tic_api_textri(tic_mem* memory, float x1, float y1, float x2, float y2, flo
                     const u8 *buffer = &ptr[((iu >> 3) + ((iv >> 3) << 4)) << 5];
                     u8 color = tic_tool_peek4(buffer, (iu & 7) + ((iv & 7) << 3));
                     if (color != chroma)
-                        setPixel(machine, x, y, color);
+                        setPixel(machine, x+1, y, color);
                     u += dudxs;
                     v += dvdxs;
                 }

Edit : another patch option:

diff --git a/src/tic.c b/src/tic.c
index 152a3c1..0e66dcd 100644
--- a/src/tic.c
+++ b/src/tic.c
@@ -1106,8 +1106,8 @@ void tic_api_textri(tic_mem* memory, float x1, float y1, float x2, float y2, flo
         {
             s32 u = SidesBuffer.ULeft[y];
             s32 v = SidesBuffer.VLeft[y];
-            s32 left = SidesBuffer.Left[y];
-            s32 right = SidesBuffer.Right[y];
+            s32 left = SidesBuffer.Left[y]+1;
+            s32 right = SidesBuffer.Right[y]+1;
             //  check right edge, and CLAMP it
             if (right > machine->state.clip.r)
                 right = machine->state.clip.r;

[ddelemeny]

Interestingly enough, this bleeding out of edges also happens with tri.

The weird thing is that tri uses ticLine to walk the sides, which is the rasterizer for line, so there shouldn't be a discrepancy here. Except there is (and it weirds me out)

x1,y1,x2,y2,x3,y3= 50,50, 185,55, 190,120
cls(0)
tri(x1,y1,x2,y2,x3,y3,7)
line(x1,y1,x2,y2,3)
line(x2,y2,x3,y3,3)
line(x1,y1,x3,y3,3)
function TIC() end

[nesbox]

It's weird, we have to fix it in .80
Thank you

[StinkerB06]

Why do you say it as .80, when the version number is called 0.80?

On Mon, Apr 27, 2020, 10:33 PM Vadim Grigoruk [e-mail]
wrote:

It's weird, we have to fix it in .80
Thank you

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/nesbox/TIC-80/issues/1059#issuecomment-620390693, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AHFK2N5CURAX2T6RAFGEJNTROZTELANCNFSM4MQ34F6Q
.

[ddelemeny]

I tracked down the weird tri behavior to ticLine.

x1,y1,x2,y2= 50,50, 190,120
cls(0)
line(x2,y2,x1,y1,9)
line(x1,y1,x2,y2,3)
function TIC() end

In it's current version, the rasterizer is sensitive to the order of parameters (p1->p2 does not light the same pixels as p2->p1). A naive fix for this would be to sort the points, but I don't know if it can have undesired consequences on primitives that depend on it.

[nesbox]

So tri() and line() were fixed by @ddelemeny.
We just need to fix textri() in the issue.

[JettMonstersGoBoom]

Surely adding 1 to the X inputs at the beginning of the ttri function is faster than during the scan functions ?

[nesbox]

I made a quick fix 0d5b5ed and it looks correct now

but it's not ideal, we have to fix the noisy edges in the next version

@JettMonstersGoBoom, do you know the reason?
thanks :)

[nesbox]

I see the problem, the reason we see this offset is that line() func uses the Bresenham algorithm while textri() doesn't.
I reverted my textri() changes here 946d910 and we have to decide what to do, decline Bresenham using for the line() or not.

[nesbox]

Seems the issue is deeper than I expected, let's fix it in the next version.