Font functions and fixed width font for llSetText

One problem I'm having lately is that some data would look really good if formatted in columns, but that's currently impossible. Another problem I recently discovered is that while text can be very useful in a HUD, the font size may vary, and I have no way of knowing what is it.

As things currently are, I had to make a HUD be able to resize itself to adjust to the possible font sizes that could be used. However, it's still annoying that I can't make it automatically determine which setting is needed, instead of having to explain why text is overlapping, and how to fix it.

I propose adding at least these LSL functions:

1. llSetFont(font_name, size) for setting the font and size. One of the available fonts should be of a fixed width.
   
2. llGetFontName for getting the current font name.
   
3. llGetFontSize for getting the current font size.
   

Additionally, I would love to have the following as well:

1. llSetFontAlignment(FONT_LEFT | FONT_RIGHT | FONT_CENTER)
   
2. llSetFontOffset(vector).
   

Currently, to make a sort of a clickable button on a HUD I have to use two prims: One to show the text, and another to provide the clickable area due to not being able to control where will the text appear. Being able to use one prim for both things would noticeably cut on the amount of complexity and processing required.

How about this?

llRenderText(string text, integer font, integer color, integer face);

This would pass the parameters to the SL client app, that would apply this text to the face of the prim, by baking a temporary texture onto the texture on that face. This is an efficient operation on the client, and involves a minimum amount of traffic from the server.

Adjusting the size and alignment of the text would be done by adjusting the size and alignment of the prims. It would be like an immensely more efficient XYtext.

(no, 'html on a prim' doesn't cut it. THAT is an expensive operation that passes a lot of information from the server to the client)

I like it, but if we're going to do it that way, how about going the whole way? Add llSetTextPos to set the position where to draw on the texture, so that text can be drawn multiple times on the same texture in different positions, and llClearText to clear it. Then you could use just one texture to do pretty much everything.


Not sure I understand what do you mean here. If you mean text is output left aligned into a texture, then you'd need to be able to find the length of the result to adjust accordingly. That sounds rather nasty. It sounds like it'd have problems with it looking stretched or unaligned until the prim is adjusted properly.

What I was trying to propose was something that was IMO not ideal, but easy enough to do, so that there was actually some chance of it getting implemented

I think if we're going to draw text on textures we might as well go all the way: Make a full set of graphics functions with positioning, text, color, graphics primitives, etc functions. Perhaps throw there functions to indicate when to refresh the output, to make it possible to produce complex output without introducing visible redraw.

I think I must have expressed myself poorly.

This wouldn't modify the texture anywhere. It would mean that when the client rendered that face of the prim, it would create a local temporary copy of the texture that had the rendering on it, and use that for that face. You wouldn't need to provide multiple textures.

As for alignment, once you have the ability to specify a fixed width font (FONT_COURIER) that's taken care of with padding. For example...

llRenderText("Altitude\n 45.6\nVelocity\n 0.23", FONT_COURIER, ...);

Indeed, but that's an inherent part of building in 3d in Second Life. You're always having to tweak textures and prims to look good... but even the slightest tweaking produces something orders of magnitude nicer than llSetText. Look at how popular XYtext is. Even the Lindens use it!

I use llSetText in my HUDs and I would dearly love an efficient alternative.

Me too.

The problem is that anything much more complicated than simple text in a fixed font is going to lead to HTML on a prim, and the overhead in that would be horrible.

No, I got that fine, what I meant that if you're going that way instead of patching up llSetText a bit, you might as well go all the way and allow drawing anywhere on the face, as many times as needed.


Right



Well, for reference, this is what I have so far. For some reason it looks better in SL than on the screenshot. But anyway. What I'd like is to be able to do that, but without horribly slow updates, fixed size font for column alignment, and without requiring stupid prim positioning tricks. Don't think it can be done with XYText.

I'm not completely sure how would that work the way you say though. What I'd essentially like is so that I can display text on a HUD as if I took a screenshot and wrote text over it. If I say Courier 12, it must be Courier 12, with no stretching of any kind.



No need to go so far, I'd be happy enough with what I explained: Control of the font used for llSetText, and control of the offset respect of the prim.

Can you explain how one can do such a HUD?

http://img88.imageshack.us/my.php?image=hudry6.png

It's floating text. it is using hidden prims for each line.

Doing it by hacking llSetText would make some HUDs look a bit nicer, but it's a real kludge... llRenderText would have so many more applications than HUDs and would do so much a nicer job ON HUDs.