coredump
Visitor
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-16-2015
07:00 AM
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 :
I have used the function HexToInteger3 to fill rectangles and it works and the font is also been used in other applications.
' 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.
3 REPLIES 3

RokuMarkn
Visitor
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-16-2015
08:32 AM
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
--Mark
EnTerr
Roku Guru
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-16-2015
03:09 PM
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"), &hF6F6F6The 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.
16185078 16185078 16185078
That being said, of course hex literal (&hF6F6F6) is preferable when color is known in advance.

RokuMarkn
Visitor
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-16-2015
04:15 PM
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
--Mark