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


A member registered Jul 23, 2014 · View creator page →

Creator of

Recent community posts

I can send a zip thru email if you need it, but you can see it happening on the palm trees in my game: https://kaiclavier.itch.io/hammerspace

Even when I tried applying the doodleAnimationFile to a different renderer, stuff stayed in sync? I even just tried adding some numbers to the animation frames to make sure it wasn't my brain playing tricks on me, and it's all synced. And yes, it seems to be consistent across all sprites. I'm in Unity 2017.4 btw, if that makes a difference!


I have a bunch of the same object in my scene, and they all have "Random first frame" enabled on their doodle animators, but they always seem to be in sync no matter what I do. Is there something I'm missing? I could swear I didn't have issues with this before but I could be doing something wrong.

Still looking into this, because I'm still not too sure what I could have changed that could cause a difference in this between any version? I might be able to add a padding variable or something if it persists?

This behaviour should be working correctly as of v1.8!

Sorry for the late reply! I am currently commissioning a new shader for STM, when it's good to go I can send you the beta if you drop me an email. Hopefully the shader update will fix this issue, it would be great to get your feedback to check that it actually works. The new shader will work more similarly to unity's built-in text shaders, so hopefully this will just be fixed.


Reviewing this again as I'm fixing bounding box issues, STM is actually supposed to use a character's advance when deciding on the width of a box, so I will be changing this behaviour to work the way it should! Sorry about all this, but thank you for catching this.

Just updating this to let you know that this has been implemented for the next update. It's still going to take just a bit longer since I'm working out other bounding box issues, but I now have variables that track text bounds as the mesh reads out, the final bounds that text will have when it finishes reading, as well as an OnPrintEvent() that gets invoked every time a new character is drawn, so that can be used to update the size of a mesh.



In an upcoming update, I'm actually commissioning a shader update to combine all the shaders into one variable shader, so I'll forward this to my shader guy to see what can be done!



Since it's effecting the default Unity text too, could you post a screenshot of STM and the default text with the same font & text & size next to eachother so I can confirm it's exactly the same issue with both?

Assuming it is the same between both, the only idea I have for sharpening the text is to try out generating an SDF font (there's a guide in the docs), but the SDF shader doesn't support UGUI currently, but that might be possible with the shader changes in the next build?

Anyway, since it happens with both the standard text and STM, it might just be something unavoidable with aggressive antialiasing? Would it be possible to use a thicker font, or make the text larger?


What font are you using, so I can try to reproduce this? Also, can you send a screenshot of your full STM inspector, specifically the "Materials" section, if you can.

By "when the game is played", do you mean it looks different in play mode? What does it look like in edit mode vs play mode?

This screenshot is cropped close, so I can't tell what the context of this is,...so I'm unsure if this is STM's fault, or if it's just basic pixel aliasing. Does the same thing happen when using Unity's standard "Text" object on your canvas? Do you have anti-aliasing enabled in Unity's quality settings? Do you have any post-processing effects enabled?

A screenshot of the full unity editor window will be helpful for me to understand the full issue!



If your text is middle/lower anchor aligned, this bug is the same one as this: https://itch.io/t/156485/solved-text-alignment-like-zelda-botw-mario-odyssey (near the end of the thread)

I've already fixed the alignment changing as text reads out for those anchor points, but I'm still in the middle of making the text react to being cut off correctly in those scenarios. If you want the current beta, send me an email thru my website/the asset store page! Otherwise, if you set the text's anchor to top left/right/middle, this bug shouldn't happen.

Okay yep, I'm able to repro it now. (I'm testing this with courier btw. Top mesh here is STM, bottom is UGUI)

I think this is caused by... the middle alignment only takes the width of the letter into account, not the width + advance. When I right-align a UGUI Text component, the text is not flush with the right side of the box, but with STM it is. This is a great catch, but I'm worried about changing this, since it would effect all text meshes, not just monospace fonts. I'll have to come up with a way for this behaviour to only effect monospace fonts automatically, somehow.

I'll write this down for sure, but if you align stuff to the left, it should work for your purposes for now?

Hmm... I'm having trouble reproducing this, could you post a screenshot of your editor window, including STM's inspector?

(2 edits)

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.

(1 edit)


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!


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!


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.


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!


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?


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!


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


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.


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?

(1 edit)

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.

(1 edit)

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!

(1 edit)


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.

(1 edit)

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!