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: 
coredump
Level 7

2D API - DrawText not rendering

I am trying to draw text to the screen but for some reason it is not appearing, Here is a code snippet :


' RGBA converter
function HexToInteger3(hex_in)
bArr = createobject("roByteArray")
if len(hex_in) mod 2 > 0
'fix for fromHexString() malicious silent failure on odd length
hex_in = "0" + hex_in
end if
bArr.fromHexString(hex_in)
out = 0
for i = 0 to bArr.count()-1
out = 256 * out + bArr[i]
end for
return out
end function

' Define font
reg = CreateObject("roFontRegistry")
reg.Register("pkg:/fonts/SourceSansPro-Regular.ttf")
sansFont = reg.GetFont("Sans Pro", 42, false, false)

' Draw Menu
whiteColor = HexToInteger3("#F6F6F6")

screen = CreateObject("roScreen")
screen.DrawText("Item 1", 64, 155, whiteColor, sansFont)
screen.DrawText("Item 2", 64, 218 , whiteColor, sansFont)
screen.DrawText("Item 3", 64, 281, whiteColor, sansFont)
screen.DrawText("Item 4", 64, 344, whiteColor, sansFont)
screen.DrawText("Item 5", 64, 407, whiteColor, sansFont)
screen.finish()


I have used the function HexToInteger3 to fill rectangles and it works and the font is also been used in other applications.
0 Kudos
3 Replies
RokuMarkn
Level 7

Re: 2D API - DrawText not rendering

This code works fine for me, using GetDefaultFont rather than GetFont. First thing to check is that sansFont is a valid font. Possibly you have the wrong name for the font in your GetFont call. Also, the color value you're using is strange -- it is only 6 digits long rather than 8, so the red value is zero and the alpha is F6. I'm not sure if that's what you intended. There's also a bug in either your HextToInteger3 function or the call to it, since it doesn't account for the # at the start of the string (it ends up parsing the string "0#F6F6F6"). Unless you're not showing your actual code, there's no reason to say HexToInteger3("#F6F6F6") rather than the simpler and faster &hF6F6F6. Finally, you should almost always use a double buffered roScreen to avoid image tearing, which means you should use SwapBuffers not Finish.

--Mark
0 Kudos
EnTerr
Level 9

Re: 2D API - DrawText not rendering

"RokuMarkn" wrote:
... There's also a bug in either your HextToInteger3 function or the call to it, since it doesn't account for the # at the start of the string (it ends up parsing the string "0#F6F6F6"). Unless you're not showing your actual code, there's no reason to say HexToInteger3("#F6F6F6") rather than the simpler and faster &hF6F6F6.

There is no bug in HexToInteger3 nor in the way he calls it:
BrightScript Debugger> ? HexToInteger3("#F6F6F6"), HexToInteger3("0#F6F6F6"), &hF6F6F6
16185078 16185078 16185078
The reason why/how this works can be seen here viewtopic.php?f=34&t=66327&p=424467#p424655 - "turning lemons into lemonade" at the end.

That being said, of course hex literal (&hF6F6F6) is preferable when color is known in advance.
0 Kudos
RokuMarkn
Level 7

Re: 2D API - DrawText not rendering

No, I don't buy that this is intentional behavior. The function clearly expects a string of hex digits, and is prepending a zero only to avoid problems when the string is not well formed (odd length). The caller for whatever reason thinks the string can or should begin with a #. The caller clearly thinks it's passing a well formed 3 byte string. The function however thinks this is not well formed and sticks a zero in front of the # producing the bizarre FOUR byte string 0#F6F6F6 that neither the caller nor the callee would call well formed. If the caller passed "#12345678", the function would be parsing the FIVE(!) byte string "0#12345678". IMHO rejoicing in the fact that the code nevertheless works is not the best response to this mess.

--Mark
0 Kudos