Messages

1

Support / Re: 3.5, and the drawcall inflation effect.

« on: April 06, 2012, 03:46:43 pm »

The unity draw call batching doc goes into detail of how many polys get batched. A quick test shows a textmesh will batch up to about 75 characters.

This was massively helpful, thank you. I was running into a draw call nightmare (not really causing performance issues since I was only hovering about 14 - but it should have been closer to 3 so it was bothering me). My strings were all set with a max length well over the batchable limit - didn't realize the polycount was important there.

2

Releases / Re: 2D Toolkit 1.60 final

« on: March 28, 2012, 05:32:21 pm »

Absolutely love the new editor. So much faster for making bulk edits, it's not even funny. Thank you for your continued efforts in making tk2d by far the fastest/easiest 2d solution for Unity!

3

Support / Re: Sliced Sprite?

« on: March 21, 2012, 05:37:36 pm »

It's for creating 9-slice-scaled boxes. Below is a pretty good writeup that explains how the concept works (not tk2d specific).

http://rwillustrator.blogspot.com/2007/04/understanding-9-slice-scaling.html

4

Support / Re: What next?

« on: March 21, 2012, 05:36:35 pm »

No problem... By the way, I must have been on my 18th our when I wrote that and totally spaced out with the "GetComponent<>() == false" lines. I would replace "== false" with "== null" for the sake of your own sanity.

(note: == false will work, but unlike null it's possible a script will return false when it is not, in fact, null. I highly doubt you're overwriting the == and =! logic of your components, but may as well do it the right way )

Must have spaced out and the lack of compiler error + it works fine won out for the night.

5

Support / Re: What next?

« on: March 21, 2012, 02:14:52 pm »

Actually the problem of a MonoBehaviour to attach manually kills the purpose of automation
Some nested sprite prefabs can contain a lot of different sprites, and can even be multiplied by the number of scenes. So for maintenance, it's overkill to attach it by hand and could take forever to prepare, as opposed to an automatic registration by code, whatever sprite is built on the scene. Hence the insertion in tk2dSprite/tK2dTextMesh/etc Awake functions (just after it's been built).

If you really want to, you could always create an extension script and wrap the "create -> tk2d -> Sprite" buttons with "create -> tk2de -> Sprite" that calls the "create a sprite" function and then automatically adds the component to it. Your workflow wouldn't have to change at all, and it wouldn't have to be part of the base project. For auto-adding to already created sprites, you could write a simple editor script that does so. I have one for one of my own components you can copy:

Code: [Select]

[MenuItem("KS/tk2d/Add tk2dTransformExtension (Selected Objects)")]
static void AddTransformExtensionSelected(){
GameObject[] gos = Selection.gameObjects;

foreach(GameObject go in gos){
if (go.GetComponent<tk2dTransformExtension>() == null){
go.AddComponent<tk2dTransformExtension>();
}
}
}

[MenuItem("KS/tk2d/Add tk2dTransformExtension (Scene Sprites)")]
static void AddTransformExtensionScene(){
Object[] gos = FindObjectsOfType(typeof(tk2dBaseSprite));

foreach(Object go in gos){
if (go is tk2dBaseSprite){
GameObject goo = (go as tk2dBaseSprite).gameObject;
if (goo.GetComponent<tk2dTransformExtension>() == false){
goo.AddComponent<tk2dTransformExtension>();
}
}
}

gos = FindObjectsOfType(typeof(tk2dTextMesh));

foreach(Object go in gos){
if (go is tk2dTextMesh){
GameObject goo = (go as tk2dTextMesh).gameObject;
if (goo.GetComponent<tk2dTransformExtension>() == false){
goo.AddComponent<tk2dTransformExtension>();
}
}
}
}

Just replace the "tk2dTransformExtension" with whatever your component ends up being named (and replace the menu list, as I don't imagine you want it under "KS").

6

Support / Re: What next?

« on: March 11, 2012, 03:34:12 pm »

The two things I would really love to see (in addition to that list; editing the parameters for multiple sprites at the same time is going to be epic).

1: In-string color formatting for text meshes (so you can say something like textMesh.text = "[#000000]This is black and [#FFFFFF] white [#000000] text."
2: A "clipping area" that automatically clips any meshes underneath it (so that only parts of them within the area are displayed. This would make it much easier for us to roll our own GUI elements (like scroll lists/areas and what have you).

Whatever you decide, keep up the awesome work!

7

Support / Re: gameObject.SetActiveRecursively() will fail tk2dButton

« on: March 10, 2012, 07:02:58 pm »

If the button is currently animating when it gets disabled it breaks. Adding this fixed it for me:

Code: [Select]

void OnEnable(){
buttonDown = false;
}

You probably want to run some cleanup too, to ensure your buttons appear correctly after the disabling if you do any sort of scaling. I ended up just writing my own button script (I'll share it eventually, not in a great state atm though - and it depends on the "FingerGestures" plugin anyway).

8

Support / Re: Collider Unset - Safe to use?

« on: February 15, 2012, 12:17:33 am »

Okay excellent; thanks for the quick response! Just wanted to make sure I wasn't going to shoot myself in the foot by using Unset.

9

Support / Collider Unset - Safe to use?

« on: February 14, 2012, 08:28:32 pm »

Hello,

I have a couple of sprites that are significantly smaller than their trigger area - so I'm setting up the colliders myself the usual Unity way. However, at runtime they always set themselves to position 0,0,-100000 with 0,0,0 extends.

I looked through the source to find the area where this was happening and found it in sprite base.

Code: [Select]

else if (sprite.colliderType == tk2dSpriteDefinition.ColliderType.Unset)
{
// Don't do anything here, for backwards compatibility
}
else // in all cases, if the collider doesn't match is requested, null it out
{
if (boxCollider != null)
{
// move the box far far away, boxes with zero extents still collide
boxCollider.center = new Vector3(0, 0, -100000.0f);
boxCollider.extents = Vector3.zero;
}
}

I then set the collider type for the sprites in question to "Unset" and it fixed the issue. I'm just curious if this is the correct/safe way to handle this moving forward (as the code suggests it's legacy support and the conditional may be removed in the future) - or if there is a better way to handle this.

Thanks!

10

Releases / Re: 2D Toolkit 1.57 beta 1

« on: February 13, 2012, 04:09:02 pm »

Quick question; is there any important reason that the default far clipping plane is 20? Or can I safely increase that number?

Thanks!