🤑 Indie game store🙌 Free games😂 Fun games😨 Horror games
👷 Game development🎨 Assets📚 Comics
🎉 Sales🎁 Bundles

KaiClavier

124
Posts
5
Topics
206
Followers
35
Following
A member registered Jul 23, 2014 · View creator page →

Creator of

Recent community posts

(Edited 2 times)

Oof, good catch. Yeah, when custom events are invoked, it references the "info" array, and the "tacked-on" events as I call them have an info with no matching character in the string to reference.

You're right, a zero-width space added to the end of "hyphenedText" should be the easiest way to fix this.

if(info.Count > myText.Length){
    //add extra char to myText for tacked-on event
    myText += "\u200B";
}


I added this code to the end of the ParseText() event, right before return is called, and everything seems to work fine, now!

Oh oops, nice catch. I'll flip that!

I can't think of anything that would make STM use more performance than UGUI text when rendering the same thing, both are just meshes being rendered with specific materials in the end.

That's a good catch - the UI shader in specific is the cause for the shader rework as it has another edge case issue.

Surely enough, swapping out the shader with unity's default shader removes the two extra drawcalls, so it looks like the shader is the cause.

If you want to use the shader I just used, it's "GUI/Text Shader" in Unity. The new shaders will be built to work similarly to that one so it should be compatible! The only thing its missing from the future updated shaders are the dropshadow/outline effects.

(Edited 1 time)

Hey!

The way STM currently works, I believe it batches materials for each individual mesh at the moment. It creates a new material using the "material" variable as a base because each font will need a new material. But at the moment, these generated materials are only shared between the mesh they exist on, not all meshes in the scene. I'll see what I can do about this, as this would be a pretty good performance boost for a scene with multiple materials.

That said... I've had customers ship mobile games and never tell me about performance issues, period? So I don't think performance will be affected, but I'll still see if I can do anything to batch materials per-scene instead of per-mesh.


The next patch going up already cleans up GC to practically be gone, so that's already a big performance boost, if any!


Edit: also, this might be caused by shader passes, and I'm having my shaders optimized for a future patch... I'll let you know if that fixes this!

Hey!


I was thinking about this the other day - this is a bit of a janky solution but it should work...


superTextMesh.info[superTextMesh.latestNumber].bottomRightVert should give you the equivalent of superTextMesh.bottomRightBounds, but for whatever the current letter being read out is. So if you keep track of this value and use Mathf.Max like this:


Vector3 furthestPoint = Vector3.zero;

//as mesh reads...

Vector3 point = superTextMesh.info[superTextMesh.latestNumber].bottomRightVert;

furthestPoint.x = Mathf.Max(furthestPoint.x, point.x);

furthestPoint.y = Mathf.Min(furthestPoint.y, point.y);



I'll try to add a variable for keeping track of this automatically in the next update!


-Kai

Sorry for the late reply, but yeah yikes, I'll see what I can do to add back the old behaviour for edge cases such as this. I think adding back the booleans for text wrap during UI mode should do it.

Hey!

Yeah, autowrap/vertical limit control the width/height. I'm considering changing those two separate float values to be a Vector2, but I'm not sure if that makes it any more useable? 

If you add a super text mesh component to an object with a RectTransform, STM should automatically switch to UI mode, and use the RectTransform's bounds as the autowrap/vertical limit. Right now, the presence of a rectTransform is the only thing telling STM to act differently when on a canvas, so... that's actually a really good point. I'll see what I can do to make it so autoWrap/verticalLimit can be set with a rectTransform component while managing uiMode in a different way, but it'll be a bit delayed, as I have some bugs to fix first, sorry!


As for vertical best fit, try playing around with different "vertical limit modes" for now? I'll see what I can do to add a best fit mode that considers the vertical limit as well as the autowrap value!

-Kai

Oh yikes, nice catch! Yeah the text's position is always supposed to be pre-calculated, so I'll make not of this... I'm guessing this is the result of a hotfix I did in 1.7.1. I think I have a lot of reverting to do, switching from lineCountLimit to verticalLimit is a bit tougher than I anticipated

I don't actually use Unity UI myself, but I could swear it was just... if the child has the mask shader, it'll clip to be within the parent?

Take all the time you need, I won't be able to do any proper debugging for about 2 weeks or so anyway!

The UIMasked shader is a bit... strange. A friend of mine figured out you can use stencil masks to work with unity UI masks, so it uses that to work, not the intended "MaskableGraphic" method most UI elements use. Either way, I don't think it should have changed in this update, even with the shader cleanup? Another user on twitter was using the UIMasked shader not too long ago, so I'm trying to figure out what could be causing different behaviour this time around?

Hey!

Hm, this is similar to a bug that happened in 1.7 that I thought I fixed in 1.7.1, but I must not have fixed it fully. I think I fixed it for text that was done reading but never tested it for text that's in the middle of reading out. I won't be able to work on this for about 2 weeks or so, so I'm really sorry about this, I think I know exactly what's causing this though, so thank you for pointing it out!

Hey!

In 1.7 I started making it so STM will act more naturally like Unity's Text component, but I'm starting to regret doing this... it's supposed to use the Content Size Fitter or other layout elements to determine the size, so I'm not too sure what to do here? I could try adding back the old methods in the next update under a bool maybe? Right now it works like... Unity UI text always assumes autoWrap is set to the rectTransform's width, and verticalLimit is set to the rectTransform's height, so those properties are always on and the content size fitter just expands the rect to fit all potential text.

Sorry for the mess this has caused, I won't be able to fix this for about 2 weeks or so, but I really would like to solve this issue of how STM should behave with Unity UI once and for all.

Oh, since it's appearing black and pixelated, you're probably using a normal shader with UI text? Try creating a new material for your text mesh, and assigning one of STM's UI shaders to it!


STM and Unity UI text should use the same type of code to work, could you show me the code you're using? I'm not 100% what could be causing the dialogue box to empty and sit blank when you assign text to it vs Unity UI

Hey!

I'm using STM with my own dialogue system right now and messed around with yarnspinner for a bit before that, so it should be possible. That error you mentioned pops up when you try to call a non-static member thru a class directly... so basically it means this:


public TempClass myTempClass; //an instance of TempClass
class TempClass{
    public static void StaticMember(){
        //this can be called directly thru the class, with TempClass.StaticMember()
    }
    public void NonStaticMember(){
        //this has to be called thru an instance, like myTempClass.NonStaticMember(), in this situation
    }
}


Within STM, Rebuild() is what makes the mesh get info from whatever string was typed into it, and redraws the mesh. So the Rebuild event is invoked when the mesh is told to rebuild. The OnCompleteEvent is invoked when the mesh finishes reading, and the OnUndrawn event is invoked when the mesh finishes Unreading (You have to call Unread() to make the mesh unread)


Hopefully this info helps for now? I have an incredibly basic dialogue box within the sample scene if you want to give that a look, but I'm not sure how much that can help with hooking it up to YarnSpinner.

Hey!

Actually, this is being optimized right now! I'm taking a 2 week break from STM to work on a personal project, and handed off STM to a pal to optimize and clean up some garbage. STM was originally made for smaller lines of text like dialogue boxes or UI, but for larger fields or several instances of STM I can imagine this starting to cause problems on some devices.

Either way, Rebuild() being called under OnEnable() is kind of just a failsafe, I suppose it doesn't actually have to be there? I can just imagine it causing unintended behaviour if it wasn't there, so... that's why it's there. I'll forward this to my pal who's working on the GC optimization right now!

Figured it out, I think!

On line 2701 of SuperTextMesh.cs, change "latestNumber = info.Count-1;" to "latestNumber = hyphenedText.Length-1;"

Please let me know if this works for you!

Hey! Was able to repro by just adding a </c> tag to the end, and it looks like that's the cause? I'm finding weird alignment issues when using any closing tag at the very end and an even weirder one when using quads at the very end... Looking into how to fix this, now.


For now, you don't actually have to close off tags at the end of a mesh, so you can leave the </c> out and it should work fine?

(Edited 1 time)

Yeah, STMTextContainer is a new class  in 1.7, so those new scripts wouldn't work w/o it. I really wish Unity's importer would tell you when a file no longer exists in a new .unitypackage, but it just keeps adding/replacing even if a file's name has changed.

If you got it from itch, I just updated the store page to allow a download of v1.6.3 again. If you got it from the asset store, please DM me with your invoice number and I'll send the .unitypackage. This is very good debugging info btw, I'll try to figure out what changed between the two versions! The only thing that *should* have changed was the addition of overridden index quads, but that shouldn't be effecting this... sorry for the inconvenience!

Yeahhh apologies for that! I'll keep looking into it, but I'll take note of this in the docs for now! Thank you so much for your patience.

(Edited 1 time)

Yes, that's what I meant!

The way the math is working is... It takes the sprite sheet and uses the columns/rows setting to know how many boxes to slice the texture into. So, if there's 1 row and 3 columns and you want to read index 1 (the second image), the UV used would be... (0.3333,0), (0.66667,1)

...I think that might be it. Can you try making it so your texture is 4 units long instead of 3? (So the UVs would land on multiples of 0.25 instead of 0.3333 repeating) The UV math's float rounding might be what's pushing it over the edge? I think I might also be able to fix this by taking the far right UV (0.66667 in that example) and subtracting a very small number like 0.0001 from it. I'm away from my work computer atm, but I'll figure out exactly what line that would need to go on in just a bit!

(Edited 1 time)

Hey!

Please make sure the quad texture is being imported as a texture, not a sprite. Not sure if that would be the exact cause, but that's a start. You've already tried resizing the sprites on your texture to give some space between quads, but can you try shrinking the texture even more? Quads are essentially just manual UV maps, so I think the first quad is reading info from the second and so on.


That said, there might be an issue with insanely big sprite sheets for Quads that I haven't solved yet, so this might be related to that? Hopefully shrinking the texture even more solves it, but I'm hoping it's just a certain import setting somewhere on the texture.

(Edited 1 time)

Updating this publicly so I don't forget:


Turns out there's an issue with the current UI shaders where if your scene/canvas has too many elements with different alpha shaders on em, this bug happens (I think that's the cause, anyway). Unity's included GUI/Text Shader seems to render fine so that can be used for now, but I'm going to have to update the current shaders to work a bit more like unity's GUI/Text Shader.

So... until I rewrite the shaders, you can either use unity's included GUI/Text shader, reduce the amount of alpha elements/shaders in your UI, or don't use Unity UI with STM altogether. Thank you for your patience, everyone!

Hey!

I don't use FMOD myself, but I'm looking up a few tutorials on in, and I think it should be doable? I'm not 100% about the implementation of it, but I think if I were to add a delegate event that got invoked every time the audio source is supposed to play and you hooked that up to a script that interfaces with FMOD, that might work? 

You could also modify the source code and cut out the audio source entirely and replace it with FMOD I think, but I wouldn't be able to debug something like that!

-Kai

Hmm, never seen this myself personally, and I was experimenting with different canvas modes last week. Please email me through my website w/ your invoice no., and I'll send you the latest development build I have! There's a chance this problem is already fixed in the most recent version, but either way I'll only be able to debug it from that most recent version anyway!

Okay this feature is in for the next update! I should have done this faster, but I was afraid of how using best fit on multi-line text would work, but it works great!




There's now 3 options for best fit... 

"Off" (which is just how STm behaved before, no changes)

"Always" which will always make text be as wide as the autowrap limit.

and "Over Limit" which will make text fit within the autowrap limit, but only shrink it to fit, not enlarge it to fit.

(Edited 2 times)

Hey!


I was just thinking about this the other day, I might have a solution.

If this were an actual text input field, just adding the cursor to the end of the string would be fine, but this is just for animation purposes, so you might be able to do it like this:


using UnityEngine;
using System.Collections;
public class STMFakeCaret : MonoBehaviour {
    public SuperTextMesh stm; //the mesh to follow
    public Vector3 offset;
    void Update(){
        if(stm != null && //if there's a defined text mesh...
            stm.info.Count > 0 && //and it has textinfo to follow...
            stm.latestNumber > -1 && //and it's either drawing or done drawing...
            stm.hyphenedText[stm.latestNumber] != '\n'){ //ignore line breaks
            STMTextInfo myInfo = stm.info[stm.latestNumber]; //all info for this one character...
            //put the caret in the right place!
            transform.localPosition = myInfo.pos + myInfo.Advance(stm.characterSpacing, stm.quality) + offset;
        }
    }
}

If you put this on a gameobject that's the child of an object with your referenced Super Text Mesh on it, the object will follow the last drawn character! So I put this on a gameobject with a spriterenderer. You *will* have to modify Super Text Mesh's code just a bit to make this work, as the "info" list in STM is currently private, but I've changed it to be public to make this work.


Hope this solution works! I might add a custom event so you can call this function only when a new character is drawn, instead of putting it on Update.

Ah sorry, the docs really need to be updated a bit with some info from the forums. In the new version of STM I'm working on right now, there's a "Create New Material" button next to the material field that should make the usage a bit more obvious? But I'll try to update the tooltip and the docs!

(Edited 1 time)

Super Text Mesh is just a text renderer, not a text editor, so it doesn't have a caret it keeps track of by itself. To edit text at a certain position, you have to keep track of the "caret" with a variable.

Here's some pseudocode of how you can do this:


public int caretPosition = 0;  public SuperTextMesh stm; public void InsertTextAtCaret(string newText){      //add the string to super text mesh's text variable at the caret's position     stm.text = superTextMesh.text.Insert(newText, caretPosition);


To reiterate, this type of code can run in any string, not just Super Text Mesh's "text" variable!

Super Text Mesh is just meant to be a text renderer, so the type of code that would make this work for Unity's standard mesh will also work for STM.


If the caret is currently at index 3, then... 

superTextMesh.text = superTextMesh.text.Insert("***", caretPosition);

should insert a string at the caret's position.


-Kai

Hey!

I'm not 100% sure what you mean, so I'm guessing you're making a text entry field in your game?

Ignoring rich text, the position of a character relative to the object's origin should be just superTextMesh.info[indexOfCharacter].pos; You can use this to draw a caret in the right spot!

-Kai

Taking care of this on your other thread: https://itch.io/t/190198/quadsimages-arent-displaying-at-all

From your other post, it seems that you're using Unity 5.4. I'm taking a wild guess and guessing that you're using STM with Unity UI. Unity UI didn't support multiple materials until Unity 2017.1, so quads are disabled in earlier versions. Sorry about that, but there just seemed to be no way around that in earlier versions, and it would always cause a crash.

I'm going to have to suggest either upgrading to 2017.1 or avoiding Unity UI. If you really wanted, you could set something up with custom events to place UI elements to imitate Quads, but that should just be a last resort.

Oh huh, I don't /think/ there should be a reason for that, so that must be it? I could swear it was getting registered under both? I sent you an email with the beta, but I'll get on this in just a bit, sorry!

Let me know what you find!

It's always a weird combo of relief and fear when a bug manages to "fix" itself...

I really should download 2017.3 to see if I can repro this, cause I've had no luck doing this in 5.3.4 or 2017.1.

The only real things I can think of that will solve this are...

In SuperTextMesh.cs, if you ctrl+F "OnFontTextureRebuilt", you'll find a function that should be getting added to an event called Font.textureRebuilt... this event should be getting added under Init(), and removed under UnInit()... Maybe the problem is that it's getting added too many times, and if the textbox is being enabled/disabled, the event handlers are getting confused?

Send me an email through my website, and I'll send you a beta build! I'll try making it so these handlers are only called once no matter what.

(Edited 2 times)

Hey!

I can't believe this bug is back once again... I've been using 2017.1 myself so maybe it's something with 2017.3...?

You're right in the cause of it, it's caused whenever the font atlas gets updated, but STM doesn't rebuild for some reason. STM is subscribed to an event that gets invoked to call Rebuild() whenever its font atlas updates, but for some reason it doesn't always call Rebuild()...? I thought I fixed this 100% before, but I've learned a lot about events in the past few months, so I'll revisit that code and see if it's something to do with that. I am curious if it has something to do with that name box having bolded text, though.


In the meantime, you can avoid font atlas updates altogether if you set your game's font to be non-dymanic. (Go into your font's import settings and change that there) The only downside to non-dynamic fonts is that you can't adjust their quality, and they dont do bold/italics. You can change this in the font's import settings.


I'll look into this again shortly, sorry for the inconvenience!