Forum Discussion

coredump's avatar
coredump
Visitor
11 years ago

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.
Roku Developer Program

3 Replies

  • RokuMarkn's avatar
    RokuMarkn
    Visitor
    11 years ago
    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
  • EnTerr's avatar
    EnTerr
    Roku Guru
    11 years ago
    "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.
  • RokuMarkn's avatar
    RokuMarkn
    Visitor
    11 years ago
    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