dev42
Visitor
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-29-2014
04:51 PM
[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 ).
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"! 😉
peace & 42
* http://www.sunshine2k.de/coding/java/TriangleRasterization/TriangleRasterization.html
[2014-10-30 Edited title.]
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"! 😉
peace & 42
* http://www.sunshine2k.de/coding/java/TriangleRasterization/TriangleRasterization.html
[2014-10-30 Edited title.]
6 REPLIES 6

TheEndless
Channel Surfer
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-29-2014
05:54 PM
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)
Instant Watch Browser (NetflixIWB), Aquarium Screensaver (AQUARIUM), Clever Clocks Screensaver (CLEVERCLOCKS), iTunes Podcasts (ITPC), My Channels (MYCHANNELS)
EnTerr
Roku Guru
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-29-2014
11:36 PM
Re: [solved] drawLine alpha bug
I am confused. If there is a bug in DrawLine(), how does this get label "[solved]"?
dev42
Visitor
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-30-2014
04:48 AM
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.]
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
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
EnTerr
Roku Guru
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-30-2014
10:44 AM
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.
dev42
Visitor
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-30-2014
02:24 PM
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:
manifest:
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:
... 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 😄

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 😄
dev42
Visitor
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-03-2014
08:41 AM
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. 😛
... and "special case scenarios" to be dealt with too: triangles that are vertical / horizontal lines.
peace & 42
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.
peace & 42