XyText v1.0 - It it normal to get slow rendering time?

The inside face is only ONE character.

1. Outside face 1
2. Cut face 1
3. Inside face
4. Cut face 2
5. Outside face 2

One character per face, 5 characters total.

Hi Kermitt - thanks for posting the 5 face, single texture. Can I asked a few things:

a) I was just about to go from the original 6 char to 3 char version of xytext for responsiveness - now that you've posted this I assume I should really go to 5 face single texture? i.e. less prims but still good responsiveness no?

b) are there any probs outstanding in your script (i.e. did you have a bug fix coming out that I should wait for). Just checking

c) just wondering if you've already hooked a number of the 5 face prims together already into a screen .... an if so whether there is a chance you could drop me a copy?
Hopefully I'm not being too cheeky but I still don't seem to be too good with aligning/spacing stuff inworld (wish there was an "align" or "equally space" build function). Actually we share code in the forum, but how do we share prims/objects (through slex perhaps?).


Cheers
Greg

That's odd... I posted a reply to this just b4 I left work, and now I've got home and checked the thread again, and the post isn't there. Must've hit a wrong button or somethin when I went to submit it. Oh well... try again...


Definately. The 5 char version should be just as responsive as the 3 char version with the bonus of 2 extra chars per prim. (Although in saying that I'm sure there will be situations where the 3 char version will still suit the job better.)


I've tested most of the basic functionality and eveything seems to be working fine. I've never used some of the more advanced functions though so I haven't tested *everything*. Pretty sure I got all the necessary changes though. Besides... my code is always bug free


Nope... I've never had a use for a large link set of XyText. If you're gonna head down that path I'd suggest you have a close look at the SET_CELL_INFO function described in this post of the original XyText thread. I'll probably have a go at linking 2 or 3 together sometime this weekend though, just to make sure it works ok.


Do you ever manually enter x,y,z positions in the edit window? Doing it that way should make it heaps easier to align stuff than trying to drag them with the mouse. SL does have a snap to grid type functionality too, but I never use it cause it never seems to act quite how I expect. As for sharing objects, well you can just drop stuff on an av if you're in world, or go to their profile and there's a little box to drag things into in there. Keep in mind that "next owner" permissions will apply when you transfer stuff to other avatars though.

The 10 character version of XyText is now working (or workable) see my updated post above for Prim Setup Script and XyText 1.0.3 file.


UPDATE: Fixed...... remember not to code when tired.. missed one number change...

Good point, I hadn't tried this. Perhaps the easiest would then be to:

1. set the size of a basic 5 face prim to a width & height of 1 (or some integer - to make it easier later)
   
2. then duplicate and manually set position
   
3. link them in the correct order (dont' think there's an easy way to do this)
   
4. then with them all link STRETCH the whole structure wider/taller as required - hopefully all the prims would stretch in a way that one would need assuming its a display
   

What do you think?

That's all pretty much it. As for the linking it's the order u select them that matters. Say u have 3 prims called A, B, C...

If you select A, then B, then C, then link them. The link order will actually become...
1 = C (root)
2 = B
3 = A

So if u select them in reverse order, C, then B then A. You'll get the link order u probably want which is....
1 = A (root)
2 = B
3 = C

I find I have enough trouble keeping track of the root prim. Keeping track of multiple linked objects and remembering to always relink the object in order seems like a lot of work.

Wouldn't something like this be easier?

list LINK_NUMBERS = [ 0, 0, 0, 0, 0, 0 ]; // link numbers of the 6 text prims, in order.

patch_link_numbers()
{
  integer np = llGetNumberOfPrims();
  integer link;

  for(link = 1; link < n; link++)
  {
     integer id = (integer)llGetLinkName(link) - 1;
     if(id >= 0 && id < 6)
       LINK_NUMBERS = llListReplaceList(LINK_NUMBERS, [link], id, id);
  }
}

Call this from state_entry() and changed(), and then name the prims "1" through "6" (1-offset because you'll get 0 for non-numeric names or prims not in the link-set (the latter shouldn't happen, but one day someone's going to manage to unlink a prim while this script's running (don't you hate nested comments))). Then to target prim named "3" you'd use integer link = llList2Integer(LINK_NUMBERS,2);.

Might be easier, but the way I see it you're just using up memory to do something that can be done manually at build time. Probably fine for small jobs or temporary things, but I wouldn't use anything like that in a product I was gonna sell.

Kermitt - got a display hooked up with the 5face single texture xytext mod. Its 6 prims across & 9 prims down, so 30 x 9 chars. Much more responsive then the original 6char/prim (3 faces) version hey.

Tks

Seems like a false economy to me.

How many active prims do you have in your objects? Unless you're doing something like a scoreboard, we're talking about a single list with half a dozen integers that's never modified after the object is first rezzed. You're using up more memory just on the unused spaces in your font images.

If your control script is THAT close to the limit, use a relay script. If you've got enough active objects that it matters, one more script isn't going to make a difference.

Do you mostly sell no-mod objects? For anything that's mod, you oughta consider it as insurance against support hassles. I mean, it's hard enough to keep people from losing the root prim, let alone keeping all the prims in the right order.

Finally, after thinking about it, it'd may make more sense to have the control script broadcast the whole text and let each prim figure out what part of the text to display independently. If you're going to be updating large chunks of text, it's certainly the way to go to avoid the llMessageLinked delays building up and getting the updates out of sync.

state_entry()
{
  my_offset = llGetName() * 5;
}
link_message(integer from, integer offset, string text, integer id)
{
  if(offset >= my_offset + 5) return; // efficiently ignore text after me
  integer len = llGetStringLength(text);
  if(offset+len < my_offset) return; // efficiently ignore text before me
  //... now chop out the characters I'm responsible for and display them...
}

I overhalled and recombined both the 6 & 3 letter versions of XyText for a project called TLTP & TLML. When Xylor wrote XyText, SL didn't support unicode, but since it does now, you can remove the remap code and just use unicode characters in the map. Which greatly simplifies the code of XyText.

I say we all hound cory until he puts these font TGAs fixed in our caches as defaults so they don't have to load.

Seriously. HTML on a prim isn't going to be a solution, and this would be cool if we never had to see the blurry.

You guys are my heroes.