texture offset for a number display

[Arun Muhindra]

Hello. I did a texture with numbers 0-9 and other letters. 4*4 fields. I like to have 3 digits on a HUD shows my data as integer.

My idea was split the data integer in digits. Get the texture offsets for each digit from a list (stored before) list[0] is offset for 0, list[1] offset for 1 and so on. Get the data with (vector)llList2string from the list. Then i set the texture with llSetLinkPrimitiveFast [PRIM_TEXTURE]...

Is there a way do this with using less effort, less script time consumption?

[Qie Niangao]

Overall approach seems reasonable. This part is strange though:
   (vector)llList2string
because you can store vectors in the list directly, so just llList2Vector should work with no typecast needed.

(I've seen this elsewhere recently too. I wonder if it's left over from handling lists created by llParseString2List, like from link message strings or something.)

Otherwise, maybe the actual code would reveal other savings, once you've got it ready. Want to set all digits in a single call to llSetLinkPrimitiveParamsFast, for example, but it's hard to guess what might be a useful suggestion before seeing the code.

[Frionil Fang]

5 hours ago, Arun Muhindra said:

Is there a way do this with using less effort, less script time consumption?

There's little reason to build a list of offsets if your texture is arranged in an orderly grid, like I understood you to have, the math is not complicated to calculate the offsets and repeats on the fly.

Long answer:

integer rows = 4;
integer columns = 4;
float cell_width = 1.0/columns;
float cell_height = 1.0/rows;
integer x_position = num%columns; // calculate the cell position in the texture
integer y_position = num/columns; // integer division, rounds towards 0
// offset 0, 0 is in the middle of the texture, -0.5, 0.5 is the upper left corner, so we base the offset from there
// the +0.5 addition is to position in the middle of the cell, not the corner
vector offset = <-0.5+cell_width*(x_position+0.5), 0.5-cell_height*(y_position+0.5), 0>;
// repeats are equal to cell width and height
llSetLinkPrimitiveParams(LINK_THIS, [PRIM_TEXTURE, ALL_SIDES, texture, <cell_width, cell_height, 0>, offset, 0]);

Short answer for a 4x4 case, with temporary variables and constants eliminated and expanded, and division/modulo turned into binary operations:

llSetLinkPrimitiveParams(LINK_THIS, [PRIM_TEXTURE, ALL_SIDES, texture, <0.25, 0.25, 0>, <-0.375+0.25*(num&3), 0.375-0.25*(num>>2), 0>, 0]);

Optimized math for arbitrary grid layouts other than 4x4 left as an exercise for the reader. You can't use binary operations as easily unless the rows/columns are a power of 2, but division and modulo don't really make that much difference unless called thousands of times in quick succession. 

 

3 hours ago, Qie Niangao said:

I've seen this elsewhere recently too. I wonder if it's left over from handling lists created by llParseString2List, like from link message strings or something.

That's correct, llParseString2List returns a list of strings, and for some reason llList2Vector and llList2Rot do not do an implicit conversion unlike llList2Integer and llList2Float so you have to get them as a string and perform an explicit conversion instead.

[Quistess Alpha]

3 hours ago, Frionil Fang said:

the math is not complicated to calculate the offsets and repeats on the fly.

Not complicated, but from the few time's I've done it from scratch, there are a good few gritty details to debug (half tile offset might only be needed for even # total columns/ rows; the need to use both negative and positive offsets to avoid literal edge cases). Thanks for posting an example!

[Frionil Fang]

3 minutes ago, Quistess Alpha said:

Not complicated, but from the few time's I've done it from scratch, there are a good few gritty details to debug (half tile offset might only be needed for even # total columns/ rows; the need to use both negative and positive offsets to avoid literal edge cases). Thanks for posting an example!

Well, yes, not complicated in the sense that it boils down just a few quick math operations at the end, but I can tell you I've had to reinvent this code many times and it's rarely gone smoothly!

I think the formula above should hold for odd numbers of rows and columns too, though, e.g. assume 7 columns, symbol 3 offset = -0.5+1/7*(3+0.5) = -0.5+0.5 = 0, as it should be, symbol 0 offset = -0.5+1/7*(0+0.5) = -0.5+1/14 ~= -0.429 which checks out too. Should probably make sure to bound the symbol between 0 and width*height first, since I didn't check what exactly happens if you try to display -1 or 317 when you have symbols 0 to 15...

[Arun Muhindra]

Thank you for all the answer and the code. I will try to understand and implenemt ingame. This looks really cool and i'm happy others got 'more math' then i did!  ty