Messages

1

Releases / Re: 2D Toolkit 1.60 final

« on: March 28, 2012, 12:32:46 am »

yay !

2

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

« on: March 22, 2012, 12:18:44 pm »

Ok, so the whole drawcall behaviour is confirmed to be a Unity bug. Thanks.

3

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

« on: March 22, 2012, 11:47:48 am »

I'll put that in the TODO for after the tilemap editor. I don't believe its that big a job.

ps. I dont know how I managed to delete the image before I clicked submit

Thanks, that's great news

Also,  I made another experience, disabling everything ingame except tk2dSprites. Drawcalls skyrocketted to 18
Then I disabled and re-enabled some of these sprites, and drawcalls went to 4. As weird as it is, it would seem like overlapping causes total random batching results, but I made another test in this situation : still having nothing but tk2dSprites, except I separated all of them in order for not having a single overlap. Drawcalls stayed at 7. I don't understand ...

4

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

« on: March 22, 2012, 11:24:19 am »

Hi,

great feedback as always.

Ok, after applying your advices, here are my scene analysis :
- no textmesh goes above 20 chars. Most are 4 chars max.
- no textmesh is sandwiched between 2 sprites. the only overlap is texmeshes over some sprites (inevitable background frame).
- I'm already creating a separate HUD camera of course :-) I'm also disabling several groups of HUD as long as they're not used. I'm also keeping things organized by using the Anchor system (very neat feature btw, I tried every possible resolution, it always fits, great job).

Actually, I would take anything that could reduce the drawcalls, as the HUD cannot be tweaked like a background complex gameObject, or a shader. Even on a 3G, the HUD is vital.
I made my font atlas to fit inside 256x26, so they could totally fit inside my HUD atlas. If you're 100% sure that merging text atlases inside sprite atlas can drastically reduce drawcalls, I'm totally in for such a solution :-)

p.s : the attached png is 0 kb.

p.s 2 : I attached a screenshot of the HUD

5

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

« on: March 21, 2012, 03:49:36 pm »

Tried to add another TextMesh -> getting another additional drawcall 

I'd like to know, what are the expected results with multiple text meshes (from the same font) ? When you tested tk2d, or even the games you're in which using it, are you following some particular guiderules to prevent from such random drawcall inflation ?

6

Support / Re: What next?

« on: March 21, 2012, 02:31:36 pm »

Thanks a lot Kyle, that will come in handy for sure :-)

7

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

« on: March 21, 2012, 12:47:57 pm »

Ok I wrote a very detailed repro case, with FBX this time (to highlight the fact that it's not tied to 2DToolkit).

Here it is : http://forum.unity3d.com/threads/123664-Lightmap-Directional-Light-Drawcalls-went-up-SOLVED?p=869108#post869108

I'll be looking at these over the weekend if thats OK with your timescale? I can shuffle things about if you need it looked at sooner.

Thank you for your dedication, really. But here I feel it's a Unity bug. The only tie with TK2D I can think of is that I'm using tk2dCamera, which is multiplying all corrdinates to huge numbers, and could cause the batching to fail (as it's mentionned that objects need to be "close", but close how ? visually close ? or coord ?).

I'm a bit upset by Unity huge lack of feedback on this drawcall 3.5 problem, I admit. The only move they made was to put a [SOLVED] in my thread title and link it to a problem with lights hitting lightmaps in 3.5 but not in 3.4. Or a bug with projectors in 3.5. But there were some other threads where the case was not involving projectors at all, or not having lightmaps at all, but still having higher drawcalls than in 3.4 ....

So well, I'll just try to wave hands and make some noise in the Unity forums, so that maybe we would at last have a glimpse of a bone from the staff.

8

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

« on: March 21, 2012, 11:49:31 am »

Ah, unfortunately I'm using FBX that contains a ton of NDA elements :/

But you can 100% reproduce that with the scenario above, may it be with tk2dSprites or just FBX imported textured quads.
edit : sorry, I forgot one precision in the repro case. I'm writing a clean one for the FBX method in 5 minutes.

9

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

« on: March 21, 2012, 11:05:49 am »

Another interesting test :

I have 2 x 2 overlapping sprites on a given place. If I put sprite1A and sprite 1B on the same Z, but sprite2A and sprite2B on another different same Z (0.1 instead of 0), it displays an overall 10 drawcalls.
Now from that situation, if I put sprite2A (or 2B) on the exact same Z than sprite1A (or 1B), and leave the other one on a 0.1 Z, it gives 11 drawcalls.

wtf ? There's clearly an internal problem on Unity's part here, isn't it ?
(reminder : all 4 sprites are belonging to the same atlas)

edit : made another very simple to repro case :
1) create 4 tk2dSprites, and 2 textMeshes
2) put 2 sprites (overlapping themselves) on the left of the screen, 2 on the right
3) put spriteLeft1 on Z = 0, spriteLeft2 on Z = -0.1. Same for spriteRight1 & 2
4) now put one textMesh on the left sprite pack, at Z = -0.1, same for the right
- it displays 2 drawcalls, as expected.

5) then put the left testMesh at Z = 0 (same Z as the underneath spriteLeft1, in fact).

- it displays 4 drawcalls.

edit 2 : I tried to reproduce the same scenario with FBX imported textured quads (same shader). Exact same scenario, exact same Z position tests, except here it's 2 different FBX with 2 different atlases (to emulate the tk2d sprite + textMesh different atlas).

Guess what ? I have the same drawcall rising in the exact same conditions. As long as I separate each sprite from a different Z pos, it batches correctly. But as soon as I put a sprite on the same Z level as another, drawcalls rise up.

10

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

« on: March 21, 2012, 10:29:29 am »

Ok, here we go :

1. 7 drawcalls on one level, 5 on another (sampled at the exact same time, so nothing changed in the HUD)

2. only Vector3.one scaling (but I got some scripts which use such scaling on one gameObject hosting several sprites, is it ok ?)

3. tris : 174, verts : 348

4. oh crap, that's what I'm doing in 4 places .... how can this increase DCs ? isn't dynamic batching supposed to pack everything from one atlas, whatever Z overlap it has ?

edit : ok I checked this out, disabled all overlapping text, and drawcalls are displaying the expected number (3). So how are we supposed to use HUD text ? :/

edit 2 : correction, I'm not doing HUD - TEXT - HUD, but just HUD - TEXT, at 4 places.
Why does it happens with text, not with sprites ? (I have a lot of overlapping sprites btw).

edit 3 : something's really strange ... I made the same test again, under the exact same conditions (disabling everything but the hud), and now it displays 10 drawcalls... and on another run 12 drawcalls ... the only thing I changed was turning a static textSprite into a sprite (baked the text).

11

Support / 3.5, and the drawcall inflation effect.

« on: March 20, 2012, 06:37:54 pm »

I already had some drawcall rising problems with 3D objects, as mentionned in this thread.

But Joachim said it was because of projectors, and lighmapping now being taken by dynamic lights.
Except .... I'm now experiencing this filthly famous drawcall rising with .... my HUD.
I'm counting a difference of 9 drawcalls instead of 3 in the Editor (HUD + 2 fonts), whenever I activate/deactivate the HUD.

This HUD is entirely managed by 2DToolkit, and is using 1 Atlas + the builtin PremulVertexShader, so it should really be only 3 drawcalls.

I'd like to know if anyone is experiencing the same, or if the problem is reproduced at Unikron Software.

Thanks.

12

Support / Re: What next?

« on: March 16, 2012, 05:56:14 pm »

Actually, I think I am beginning to understand what your requirements are - something else I have planned might be a much better solution simply pooling sprites, etc. Could you email me with more specific info on what you're trying to pool and spawn, and I will try to explain what I'm planning if it will be a suitable fit to what you're doing.

Cheers,
unikron

Hey thanks for your continued attention, really. I admit my actual need is not that unworkable on my part (I've already worked it in fact), I was just asking for a pooling solution to avoid having to update each TK2D framework component with each update, so if you're not so much interested in such a feature, I guess the thing doesn't deserve the burden of implementing it in TK2D. At least I would have tried ^^


So for the release of my game I will work with my custom solution, don't worry it's not that much a problem, but still I think I would be ultra interested if you brought an advanced builtin pooling solution in the future (that would also manage the need for pooling or not, as you mentionned earlier). For reference, this asset store product seemed to go deep into pooling concept : http://forum.unity3d.com/threads/104320-PoolManager-2-Released!-By-Path-o-logical-Games

(I insisted because I feel such a level of pooling management would be an awesome addition to TK2D)

13

Support / Re: What next?

« on: March 16, 2012, 03:10:23 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).

14

Support / Re: What next?

« on: March 16, 2012, 02:21:49 pm »

It would be possible to implement something like that, but should it REALLY be part of the sprite system? You can actually achieve the same thing by adding a second MonoBehaviour with a register function like you described into a pool somewhere. That way it wouldn't need to be tied in to anything in particular and would just work with any other scripts attached to it too.

What are your thoughts on this?

Of course, it can be worked around, just like any other feature
But I thought that pooling was so inevitable that such a function could be baseline, instead of having to insert the same Register() functions in all 3 classes for every 2D Toolkit new build.

@nikolic : about the weight, I mentionned it as an option (set on false by default), so your memory overhead won't change at all unless you decide to tick that cache box. And about the 2DToolkit framework, I don't really think adding 6 or 7 lines of code (it is that much really, just an Add to a Dictionary + a bool checkbox in Inspector) would make it that much heavier. It doesn't force you to use any architecture at all, it just gives an optional memory database for easier handling.

So yes, I think such vital feature as caching should be in by default, therefore in for next builds (to stay on topic), but if you don't feel it like that, well nevermind, I'll just work around

edit : this proposition is just a surface scratch of what should be a support for pooling. But I admit the whole idea could weigh far much more if it wasn't just dictionary caching. Anyway it's a start ^^
And as memory management is the core of mobile development, I guess it could be a real advantage over other 2D solutions to implement a really good pooling structure

15

Support / Re: What next?

« on: March 16, 2012, 10:21:59 am »

Addendum :

A very much needed feature, for pooling purposes (which I think all devs are using to an extent), would be to give an option per Sprite Collection/TextMesh to store each created instance in a static Dictionary on Awake().

Actually we have to hunt down sprites manually for pooling, with transform.Find(spriteInstanceName), which can be very slow on complex intricated prefabs.
With a static Dictionary, we would just have to call the said instance by its name (ex : tk2dSpriteCollection.pool["enemy1"]) to use it. This would be undoubtedly way faster for load times than transform.Find().

I'm using a hack for now in the Awake() functions of tk2dSprite, tk2dTextMesh and tk2dAnimatedSprite, using a Dictionary.Add(sprite.gameObject.name, sprite), but it's not optimal.

Would it be possible to implement such a thing ? It would really not be long, but would help a ton :-)