Roku Developer Program

Developers and content creators—a complete solution for growing an audience directly.
cancel
Showing results for 
Search instead for 
Did you mean: 
dev42
Level 7

[not really solved] drawLine alpha bug [possible workaround]

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"! Smiley Wink

peace & 42

* http://www.sunshine2k.de/coding/java/TriangleRasterization/TriangleRasterization.html

[2014-10-30 Edited title.]
0 Kudos
6 Replies
TheEndless
Level 7

Re: [solved] drawLine alpha bug

"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.
My Channels: http://roku.permanence.com - Twitter: @TheEndlessDev
Instant Watch Browser (NetflixIWB), Aquarium Screensaver (AQUARIUM), Clever Clocks Screensaver (CLEVERCLOCKS), iTunes Podcasts (ITPC), My Channels (MYCHANNELS)
0 Kudos
EnTerr
Level 8

Re: [solved] drawLine alpha bug

I am confused. If there is a bug in DrawLine(), how does this get label "[solved]"?
0 Kudos
dev42
Level 7

Re: [solved] drawLine alpha bug

"solved" because there's a simple workaround.

Attachment: drawLine.jpg<= inline img?

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.]

REM ' fillBottomFlatTriangle
scr.drawLine(curx1, scanlineY, curx2, scanlineY, clr%)
scr.drawRect(curx1+100, scanlineY, curx2-curx1, 1, clr%)

REM ' fillTopFlatTriangle
scr.drawLine(curx1, scanlineY, curx2, scanlineY, clr%)
scr.drawRect(curx1+100, scanlineY, curx2-curx1, 1, clr%)

In this example, each triangle function draws both versions side by side.

drawLine() appears to be doubled at y = 360, while drawRect() with a height of 1 is not.

peace & 42
0 Kudos
EnTerr
Level 8

Re: [not really solved] drawLine alpha bug

"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.
0 Kudos
dev42
Level 7

Re: [not really solved] drawLine alpha bug [possible workaro

Thanks for your response! ( ... and for not being too brutal about my "ps" skills )


No editing this time. That is the unedited screen cap.
Left 4 Tris = alpha off, Right 4 Tris = alpha on
Of each 2 Triangle "group":
* Left Triangle is using drawLine()
* Right Triangle is using drawRect()

source\drawLine-bug.brs:
function Main()
? "drawLine Bug"

scr = CreateObject("roScreen", true, 1280, 720) ' double buffer
if type(scr) <> "roScreen" then
? "Unable to create roScreen."
STOP ' stop exits to the debugger
end if
GetGlobalAA().scr = scr

msgport = CreateObject("roMessagePort")
scr.SetPort(msgport)

font_registry = CreateObject("roFontRegistry")
f = font_registry.GetDefaultFont(25, false, false)

black = &h0FF
white = &hFFFFFFFF

' clear both screen buffers
scr.clear(black) ' RGBA, but A is ignored
scr.swapbuffers() ' on background planes
scr.clear(black)
scr.swapbuffers()

' draw*FT(v1x, v1y, v2x, v2y, v3x, v3y, color)
drawTFT( 50, 50, 350, 50, 200, 650, &h00FF0042)
drawBFT(475, 50, 325, 650, 625, 650, &h00FF0042)

scr.SetAlphaEnable(true)

' draw*FT( v1x, v1y, v2x, v2y, v3x, v3y, color)
drawTFT( 600, 50, 900, 50, 750, 650, &h00FF0042)
drawBFT(1025, 50, 875, 650, 1175, 650, &h00FF0042)

scr.DrawText("Press a button to continue", 100, 610, white, f)

scr.swapbuffers()
while true
msg=wait(0, msgport) ' wait(0 == wait forever
' ? "hi"
if type(msg)="roUniversalControlEvent" then exit while
end while
end function

' fillBottomFlatTriangle
Sub drawBFT(v1x, v1y, v2x, v2y, v3x, v3y, clr%)
scr = GetGlobalAA().scr
if v2y = v1y then return
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) ' +1
scr.drawLine(curx1, scanlineY, curx2, scanlineY, clr%)
scr.drawRect(curx1+100, scanlineY, curx2-curx1, 1, clr%)
curx1 = curx1 + invslope1
curx2 = curx2 + invslope2
end for
end sub

REM ' fillTopFlatTriangle
Sub drawTFT(v1x, v1y, v2x, v2y, v3x, v3y, clr%)
scr = GetGlobalAA().scr
if v3y = v1y then return
if v3y = v2y then return
invslope1 = (v3x - v1x) / (v3y - v1y)
invslope2 = (v3x - v2x) / (v3y - v2y)

curx1 = v3x
curx2 = v3x

' for (scanlineY = v3y; scanlineY > v1y; scanlineY--)
for scanlineY = FIX(v3y) TO FIX(v1y+1) STEP -1
curx1 = curx1 - invslope1
curx2 = curx2 - invslope2
scr.drawLine(curx1, scanlineY, curx2, scanlineY, clr%)
scr.drawRect(curx1+100, scanlineY, curx2-curx1, 1, clr%)
end for
End Sub

manifest:
title=drawLine() Bug?
subtitle=Possible Alpha bug in horizontal drawLine()

You bring up many Q's that I have and gave me more! Could it be my TV? Can of worms going there? After some thought I believe the answer is "No!" because of the screen capture, right? The Screen Capture bypasses anything the TV is doing and pulls the image directly from the Roku itself, correct?

Roku stats: Roku 2, Model number 3100X, SW ver 5.5 * build 410
HDTV Running in 1980x1080 with Roku set to "1080p HDTV" and the call:
scr = CreateObject("roScreen", true, 1280, 720)  ' double buffer

... problem persists with Roku set to "480p"
... problem persists with Roku set to "16:9"
... problem persists with Roku set to "720p"

I did my best to cycle all HTDV "picture sizes" As in Normal, 16:9, Movie expand, Zoom, Wide, Full

Where's the Roku dump? ( Off topic, but are there any memory usage / available memory functions? )

The whole by-reference / by-value is a discussion I very much need, but another thread. Another time. FWIW, I ported the pseudo code from the blog post as I totally missed the link to his code. I ported it to javascript first and then to Roku and in both ports I had a hard time trying to get the Swap( ) function to work. [Note: I took that out in this test so it is not a factor at all.]

peace & 84 lines of code Smiley Very Happy
0 Kudos
dev42
Level 7

Re: [not really solved] drawLine alpha bug [possible workaro

Quick follow up... ( no change to issue )

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. Smiley Tongue

... and "special case scenarios" to be dealt with too: triangles that are vertical / horizontal lines.

peace & 42
0 Kudos