LUA: context:DrawText()

[darthlukan]

It looks like DrawText doesn't like multi-line string literals, it's reading them in as one long line that ends up mostly off of the screen and doesn't respond to escape characters (such as "\n") embedded in the multi-line string in order to try and simulate "wrapping".

 

Either I'm missing some undocumented param or DrawText was only meant to draw a single line of text at a time.

 

Of course, I can write a loop for this, but that incurs a performance penalty, especially with longer bits of text and seems to be a needlessly complex solution.

 

My suggestion is to allow DrawText the ability to handle multi-line strings in LUA or have it renamed to DrawSingleLineText, since that's what it does.

[macklebee]

It looks like DrawText doesn't like multi-line string literals, it's reading them in as one long line that ends up mostly off of the screen and doesn't respond to escape characters (such as "\n") embedded in the multi-line string in order to try and simulate "wrapping".

 

Either I'm missing some undocumented param or DrawText was only meant to draw a single line of text at a time.

 

Of course, I can write a loop for this, but that incurs a performance penalty, especially with longer bits of text and seems to be a needlessly complex solution.

 

My suggestion is to allow DrawText the ability to handle multi-line strings in LUA or have it renamed to DrawSingleLineText, since that's what it does.

 

I would say you are not missing any undocumented parameter. The problem is that glsl has no idea what an escape character is. So for multi-line text, you would have to parse the string looking for these escape characters, determine the number of lines, and send the appropriate vertex positions to a shader (text is drawn across 4 vertices). I recommend taking a look at be06's 'Notes like in Amnesia' to see how complicated it can get to parse text (granted this does come with a lot of useful features) just to send it to a shader to be drawn.

 

If you are asking that LE just have the ability to draw multi-line text inherently so you don't have to do all the background work, then that is a reasonable request. Just do not be surprised to find out that the performance penalty is no different or worse than just using multiple DrawText()'s. And if Josh does make this request a reality, I'd prefer him just adding it as a parameter to the current command DrawText() or create a new command DrawMultilineText() since fellow LE users have been using the command DrawText() for several years.

 

If by chance you are showing a wall of text that does not change, then the best performance would be from just putting that text onto a texture and using DrawImage() to show it.

[darthlukan]

I would say you are not missing any undocumented parameter. The problem is that glsl has no idea what an escape character is. So for multi-line text, you would have to parse the string looking for these escape characters, determine the number of lines, and send the appropriate vertex positions to a shader (text is drawn across 4 vertices). I recommend taking a look at be06's 'Notes like in Amnesia' to see how complicated it can get to parse text (granted this does come with a lot of useful features) just to send it to a shader to be drawn.

 

If you are asking that LE just have the ability to draw multi-line text inherently so you don't have to do all the background work, then that is a reasonable request. Just do not be surprised to find out that the performance penalty is no different or worse than just using multiple DrawText()'s. And if Josh does make this request a reality, I'd prefer him just adding it as a parameter to the current command DrawText() or create a new command DrawMultilineText() since fellow LE users have been using the command DrawText() for several years.

 

If by chance you are showing a wall of text that does not change, then the best performance would be from just putting that text onto a texture and using DrawImage() to show it.

 

I took a look at that. I ran across this situation due to a use-case involving scrolling multi-line text (or at least, that's what I wanted to do). The scrolling isn't the issue, I have that well in hand, I was just trying to avoid using a loop to accomplish the task as, considering the amount of text, the performance penalty would become more noticeable (O(n) vs O(1)).

 

For now, I can use a texture, though that's a bit unwieldy and requires yet more code to implement.

 

Thanks for that bit on GLSL, I didn't realize that DrawText was using that and that it doesn't understand escapes because of it. Now that I think of it, that does make quite a bit of sense.

 

I stand by that it would still be worthwhile having inherent to DrawText (or DrawMultiText) as it minimizes complexity in project implementation (even if it requires more code in the engine) and offers a bit more flexibility with regard to UIs in Leadwerks. That said, I can totally understand if Josh chooses to sit this one out, as it could cause backwards compatibility issues, especially if DrawText is modified for an extra param.