The following may be a bug. I’ve found a work-around and I’m lazy so I’m not going to chase it any further ( yeah right! :roll: ).
While trying to port the triangle drawing routines* to BrightScript using drawLine( ) & a color with alpha ( transparency ) I’m getting overlapping lines ( color blending ) at y = 360, when in 1280x720 mode. Sorry, don’t know how to get a screen capture ( easily ).
Sub drawBottomFlatTriangle(v1x, v1y, v2x, v2y, v3x, v3y)
scr = GetGlobalAA().scr
clr% = &h00FF0042
if v2y = v1y then return ' exit before div by zero
if v3y = v1y then return
invslope1 = (v2x - v1x) / (v2y - v1y)
invslope2 = (v3x - v1x) / (v3y - v1y)
curx1 = v1x
curx2 = v1x
' for (scanlineY = v1y; scanlineY <= v2y; scanlineY++)
for scanlineY = FIX(v1y) TO FIX(v2y)
scr.drawLine(curx1, scanlineY, curx2, scanlineY, clr%)
'scr.drawRect(curx1, scanlineY, curx2-curx1, 1, clr%)
curx1 = curx1 + invslope1
curx2 = curx2 + invslope2
end for
end sub
The work-around is to use drawRect( ) instead.
I’m still curious if it is a bug. I spent quite some time trying to track it down. Please do not sing “Let it go”!
“dev42” wrote:
Sorry, don’t know how to get a screen capture ( easily ).
You can take screenshots from the Utilities page on the side-loading web interface.
Thanks for the tip about screen capture! ( try not to envy my awesome ms paint skillz! )
[Edit: tried to place it inline a few times. dunno what I’m doing wrong.]
[Edit2: hopefully the photo link site will keep it live long enough for us to solve these pressing issues and save the world.]
“dev42” wrote:
“solved” because there’s a simple workaround.
…
drawLine() appears to be doubled at y = 360, while drawRect() with a height of 1 is not.
I see, so the issue with DrawLine() is still there and likely to manifest in other cases too, where it cannot be substituted with DrawRectangle(). The catch is if you label posting that way, odds are no RokuPerson will look at it. Or if you say you found a workaround, they’d eagerly ignore the rest. First one, because in here we often get questions by inexperienced developers, which are solved by RTFM or learning the fine difference between intrinsic type (by-value) and object (by-reference). Second, because they have better things to do (presumably).
You probably should have given complete code snippet with exact coordinates and loops, to be easy to reproduce. On the image i see, shouldn’t the two lines be matching against each other at about the middle 360 (out of 720)? That image is resized does not help - but i am guesstimating the offset between the lines is about 143px if it were 720 tall?
I won’t be surprised behavior to be different depending on the platform; i.e. players with OpenGLES (3xxx, 4xxx) vs linux framebuffer (27xx) for a “no can do to fix”. OTOH if it persists, issue is likely in RokuCo-written code and not library.
The triangle code given isn’t production ready. Meaning, the current use of drawRect( ) draws an extra “line” … but amazingly it doesn’t overlap in the middle… hmmm. Anyway, check the ranges etc.
Also, if memory serves, triangles should always draw in one direction and start at the point given and not reach the end. [Edit: OK OK “one direction” plug or not, what I mean is that one must decide if smaller “x” will be drawn to and bigger “x” won’t or vice versa.] That way there won’t be overlap when 2 triangles share an edge. Again, possibly a simple fix, but it was easier to type this than to look at the code.
… and “special case scenarios” to be dealt with too: triangles that are vertical / horizontal lines.
