1
Support / Re: Sprite Collection Analysis at Run Time
« on: April 10, 2013, 03:24:32 pm »
No dice...ing.
By which I mean, cool, thanks!
By which I mean, cool, thanks!
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1]
2
Support / Re: Sprite Collection Analysis at Run Time
« on: April 10, 2013, 01:54:16 pm »
Sounds a bit like idTech's megatextures! Worked on a project which had that. Yep. A lot of work!
I'm doing pretty well with my tool (although it's super simplistic). It's already highlighted what collections want to get split and what want to be conjoined, so well worth the effort in our case.
I'm currently trying to calculate how big a sprite is in terms of pixels (so that I can calculate the memory wasteage). I'm finding it harder than expected! Must be missing something!
Is it something like (tk2dSpriteDefinition::texelSize.x * Texture::width ) * (tk2dSpriteDefinition::texelSize.y * Texture::height ) to get pixels used? I never fully understood texels. Are they like, 1 texel = the size of the current texture? Like a UV co-ordinate system? I may be confusing myself.
[Edit]: n/m. That made me think of using UVs. Wasn't for sure about UV index order (i.e. bottom left corner vs. top right corner) so I just grabbed the first and last UV from the sprite def's array... something like this:
Not sure if it necessarily works for sliced sprites, because I'm not sure how the verts are arranged.. just *assuming* index 0 is one corner, and index vertList.Length-1 is the opposite corner.
I'm doing pretty well with my tool (although it's super simplistic). It's already highlighted what collections want to get split and what want to be conjoined, so well worth the effort in our case.
I'm currently trying to calculate how big a sprite is in terms of pixels (so that I can calculate the memory wasteage). I'm finding it harder than expected! Must be missing something!
Is it something like (tk2dSpriteDefinition::texelSize.x * Texture::width ) * (tk2dSpriteDefinition::texelSize.y * Texture::height ) to get pixels used? I never fully understood texels. Are they like, 1 texel = the size of the current texture? Like a UV co-ordinate system? I may be confusing myself.
[Edit]: n/m. That made me think of using UVs. Wasn't for sure about UV index order (i.e. bottom left corner vs. top right corner) so I just grabbed the first and last UV from the sprite def's array... something like this:
Code: [Select]
Vector2 spriteUVSize= new Vector2(
Mathf.Abs(spriteDef.uvs[0].x - spriteDef.uvs[spriteDef.uvs.Length-1].x),
Mathf.Abs(spriteDef.uvs[0].y - spriteDef.uvs[spriteDef.uvs.Length-1].y)
);
spriteUseMemory += (int)((spriteUVSize.x *textureSize.x ) * (spriteUVSize.y * textureSize.y));Not sure if it necessarily works for sliced sprites, because I'm not sure how the verts are arranged.. just *assuming* index 0 is one corner, and index vertList.Length-1 is the opposite corner.
3
Support / Sprite Collection Analysis at Run Time
« on: April 09, 2013, 10:26:57 am »
Hi there,
I'm currently on a project which is for mobile, using in the region of 30* separate sprite collections. Due to the nature of the project, this is only likely to increase.
Our sprite organisation has not been based on "what gets used simultaneously", so it's sub optimal. Entire sprite collections may be loaded just to display 1 sprite from them. There might be 8 sprite collections loaded for one scene, with the scene only referencing one or two sprites from each collection (I exaggerate, but you see our problem!) . Not normally an issue, but we're on mobile, and thus have to be extra cautious about hitting iOS's magical memory "fuck you" threshold.
So, we have to reorganize our sprites in order to minimize sprites which aren't being used at any given moment. This is mostly easy for us to do since our game is very menu heavy, so our menu screens seem to split into collections quite easily.
My question/suggestion for a feature is to have some kind of run time analysis tool which tells you what sprites are being used right now, and from what sprite collection. Also, something to tell you what percentage of each sprite collection is displayed at once.
I'm going to have a stab at it in my own bad way, by running through every camera, and every sprite, and doing an "is visible" check, and then putting a little "check!" mark against each sprite collection to say that it's used, and just have a look at that data in the inspector. Pretty slow, but it's analysis so it doesn't have to be in the release. Maybe there's a better way which hooks more directly into tk2d code? Perhaps you could suggest a better approach to the meta-organization of sprites based on common useage.
*2dToolkit: we love you!
I'm currently on a project which is for mobile, using in the region of 30* separate sprite collections. Due to the nature of the project, this is only likely to increase.
Our sprite organisation has not been based on "what gets used simultaneously", so it's sub optimal. Entire sprite collections may be loaded just to display 1 sprite from them. There might be 8 sprite collections loaded for one scene, with the scene only referencing one or two sprites from each collection (I exaggerate, but you see our problem!) . Not normally an issue, but we're on mobile, and thus have to be extra cautious about hitting iOS's magical memory "fuck you" threshold.
So, we have to reorganize our sprites in order to minimize sprites which aren't being used at any given moment. This is mostly easy for us to do since our game is very menu heavy, so our menu screens seem to split into collections quite easily.
My question/suggestion for a feature is to have some kind of run time analysis tool which tells you what sprites are being used right now, and from what sprite collection. Also, something to tell you what percentage of each sprite collection is displayed at once.
I'm going to have a stab at it in my own bad way, by running through every camera, and every sprite, and doing an "is visible" check, and then putting a little "check!" mark against each sprite collection to say that it's used, and just have a look at that data in the inspector. Pretty slow, but it's analysis so it doesn't have to be in the release. Maybe there's a better way which hooks more directly into tk2d code? Perhaps you could suggest a better approach to the meta-organization of sprites based on common useage.
*2dToolkit: we love you!
4
Support / Re: Using tk2dButton Events
« on: December 04, 2012, 02:55:23 pm »
Updating to latest got the events to work for me, also. But I'm having trouble when I have Time.timeScale = 0.0f;
The Down and Up events seem to both fire on release of the button, and only then if i don't move the mouse. This seems similar to the problem i was having before the update, but only for Time.timeScale = 0.0f;
Oh, and this is in Unity 3.5.6f4
The Down and Up events seem to both fire on release of the button, and only then if i don't move the mouse. This seems similar to the problem i was having before the update, but only for Time.timeScale = 0.0f;
Oh, and this is in Unity 3.5.6f4
5
Support / Re: tk2DAnimatedSprite.color in OnEnable()
« on: February 02, 2012, 01:42:49 pm »
Ah! Might be that it's out of date. I'll check and give it a go, thanks!
6
Support / tk2DAnimatedSprite.color in OnEnable()
« on: January 31, 2012, 01:59:27 pm »
I'm trying to set the color of a tk2DAnimatedSprite in OnEnable(), and I'm getting this error:
here's the relevant code:
Any ideas? I change the color later on (for damage effects), and there doesn't seem to be a problem. I wonder if it's something to do with the mesh data not being set up before this object is setup?
..
I'll try putting my script later in the update order to see if that changes anything.
Code: [Select]
NullReferenceException: Object reference not set to an instance of an object
tk2dBaseSprite.SetColors (UnityEngine.Color[] dest) (at Assets/TK2DROOT/tk2d/Sprites/tk2dBaseSprite.cs:169)
tk2dSprite.UpdateColorsImpl () (at Assets/TK2DROOT/tk2d/Sprites/tk2dSprite.cs:71)
tk2dSprite.UpdateColors () (at Assets/TK2DROOT/tk2d/Sprites/tk2dSprite.cs:65)
tk2dBaseSprite.set_color (Color value) (at Assets/TK2DROOT/tk2d/Sprites/tk2dBaseSprite.cs:27)
BaseUnit.OnSpawned () (at Assets/Scripts/Gameplay/Units/BaseUnit.cs:131)here's the relevant code:
Code: [Select]
public public Renderer sprite;//Points to a child of this object with the sprite on it: i always do this to allow for model orientation independence.
internal tk2dAnimatedSprite anim;
void Awake () { Init(); }//Call a virtual for inheritance hacking: can't use overrides on any of unity's built in component functions
internal virtual void Init() //Called first time the object is ever run. Only need to be done once.
{
...
anim = sprite.gameObject.GetComponent<tk2dAnimatedSprite>();
}
void OnEnable() { OnSpawned(); }//just call a virtual version
internal virtual void OnSpawned()
{
...
anim.Play(0);
anim.color = Color.white.Transparency(0.5f);//crashes here. The Transparency call just returns the same color, but with the given parameter replacing alpha.
}Any ideas? I change the color later on (for damage effects), and there doesn't seem to be a problem. I wonder if it's something to do with the mesh data not being set up before this object is setup?
..
I'll try putting my script later in the update order to see if that changes anything.
Pages: [1]