Messages

1

Support / Re: Collision and collider problems (triggers)

« on: October 15, 2012, 12:25:28 am »

1.76 Final + patch 1.

2

Support / Re: Collision and collider problems (triggers)

« on: October 15, 2012, 12:11:28 am »

God damn it. OnTriggerEnter did it. Strangely it only triggers when I move the main character sprite, not when the generic ones hit it on their own, but I'll look into that.

Any idea why the collider depth isn't being properly set?

3

Support / Re: Collision and collider problems (triggers)

« on: October 14, 2012, 11:29:37 pm »

Giving the generic car prefab a rigidbody (and kinematic) didn't generate collisions. I also tried removing the movement from the generic cars but there was still no trigger message sent.

I set the collider depth to 100 in the SpriteCollection settings and committed, but still found all the box colliders to be a depth of 0.2. It's really strange. I set a breakpoint in tk2dBaseSprite - by the time it hit UpdateCollider, it was already a depth of 0.2. I stepped through CreateCollider out of curiosity also. When I delete the collider manually and press play, it creates a collider as I would expect but then UpdateCollider gives it a z of 0.2, despite the collider depth setting.

I could actually care less about the depth of the collider, as long as collisions worked (especially since the main character sprite and the generic sprites are all on the same Z). But they don't

Probably not this but is it possible that I've placed my onTriggerEnter function in the wrong place? It shouldn't be... it's in a script placed on the main character sprite.

4

Support / Collision and collider problems (triggers)

« on: October 14, 2012, 04:35:49 am »

Hey,

I'm trying to detect when two sprites are colliding, and decided to use triggers as this was recommended in the Unity documentation as a very simple way to do collisions. I couldn't figure out how to make 2D Toolkit generated (box-trimmed) colliders to be triggers, so I simply switched the sprite colliders to "Unset" and committed the sprite collection.

I then dragged an instance of my main character (the player's car) sprite into the world and gave it a box trigger collider and gave it a rigidbody (and checked IsKinematic). I also have a prefab of a tk2dsprite called generic_car that I generate multiples of using Instantiate(). I placed a box trigger collider on that prefab. When I run the game, everything looks good (almost).

I placed a script on the main character sprite and put an onTriggerEnter(Collider other) function in there with a simple Debug.Log("Collision!") call.

Issue 1: The debug log never gets called, so collisions aren't working.
Issue 2: Something funky is going on because when I set the z-value of the main character sprite's box collider to say, 100, it shows up all nice and thick - until I press play. After running the game, it switches back to 0.2 and I cannot say why. I thought it was because 2D Toolkit was overwriting the collider component but I double checked my SpriteCollection and every single sprite has it's collider to 'Unset'.

Could use some help figuring out what's going on. AFAIK the Unity collision matrix says a rigidbody trigger collider (kinematic or not) will collide with any kind of box collider.

Thanks!

5

Support / Re: Poor Performance when moving a grid of sprites?

« on: August 14, 2012, 07:16:01 pm »

So I looked through the class and it seems like a lot of work for the scope of the project I'm going for - not to mention I don't really understand how your sprite batcher works. I ended up just settling for 32x32 tiles and that got my framerate up to 30 on the phone, even scrolling at 500px/sec and cutting all the while. That'll have some negative impacts on how my game operates but I can think of a few hacks to alleviate the problem.

I appreciate all your help, at the very least I understand what's going on behind the scenes in Unity/2D Toolkit just a bit better. You have a great product, and thanks for supporting it so well!

Eshan

6

Support / Re: Poor Performance when moving a grid of sprites?

« on: August 11, 2012, 04:25:43 pm »

I'm not sure I understand what you're recommending in your first paragraph - moving away from 2D Toolkit and using just simple quads as I had tested with? Seems like I'd lose important functionality that 2D Toolkit would provide.

I can describe it for you but a webplayer will have to wait a bit. Essentially there is a grid of 16x16 tiles (TK2DSprites) with a simple texture on them. They fill up the screen, forming a grid of size 60x40 (2400 tiles) on a Retina iPhone screen.

The important piece here is that the camera is moving at a fixed pace (i.e. sidescroller) to the right. Accordingly, the tiles are "treadmilling" to keep up. In other words, as the camera moves 16 pixels, the last column of tiles to go off the left side of the screen is simply moved to the right. This creates the illusion of an endless grid of tiles. There isn't much more happening there than that.

Code: [Select]

void spawnInitialTHINGY() {
for (int i = 0; i < (initGridWidth + numTHINGYColsTreadmillAtOnce+1); i++) { // 2 screen-lengths of THINGY tiles
List<tk2dSprite> THINGYCol = new List<tk2dSprite>();
for (int j = 0; j < gridHeight; j++) {
tk2dSprite temp = Instantiate(THINGYTile, new Vector3(THINGYSize*i, THINGYSize*j, 15.0f), Quaternion.identity) as tk2dSprite;
THINGYCol.Add(temp);
}
THINGYTileCols.AddLast(THINGYCol);
}
}

// Update is called once per frame
void Update () {
float dt = Time.deltaTime;
float cameraMoveX = scrollSpeed*dt;
cameraMoveX = Mathf.Round(cameraMoveX * 100f) / 100f;

treadmillTHINGY(cameraMoveX);
treadmillBacking(cameraMoveX);
camera.transform.Translate(new Vector3(cameraMoveX, 0, 0));
}

private void treadmillTHINGY(float cameraMoveX){
THINGYTileMoveCounter += cameraMoveX;
// if camera traveled one THINGY col's width, treadmill leftmost col
if(THINGYTileCols.Count != 0){
if(THINGYTileMoveCounter >= xDistanceToTreadmill){
float leftOverTHINGYX = THINGYTileMoveCounter - xDistanceToTreadmill; // how far past the desired distance did the camera go?
xDistanceToTreadmill = THINGYSize*numTHINGYColsTreadmillAtOnce - leftOverTHINGYX; // set next desired distance before treadmilling again

List<tk2dSprite> firstCol = THINGYTileCols.First.Value; // leftmost THINGY col
List<tk2dSprite> lastCol = THINGYTileCols.Last.Value; // rightmost
float firstColX = firstCol[0].transform.position.x;
float lastColX = lastCol[0].transform.position.x;
// treadmill THINGY tile col(s)
for(int i = 0; i < numTHINGYColsTreadmillAtOnce; i++){
foreach(tk2dSprite currTile in firstCol){ // treadmill all tiles in col
currTile.transform.Translate(lastColX-firstColX + THINGYSize, 0.0f, 0.0f);
currTile.renderer.enabled = true;
currTile.collider.isTrigger = false;
}
THINGYTileCols.AddLast(firstCol); // move col to back of linked list
THINGYTileCols.RemoveFirst();
firstCol = THINGYTileCols.First.Value;
firstColX = firstCol[0].transform.position.x;
lastCol = THINGYTileCols.Last.Value;
lastColX = lastCol[0].transform.position.x;
}
THINGYTileMoveCounter = 0.0f;
}
}
}
Each one has a collider on it used for cutting, but that entire process can be ignored for now probably because drawing itself is taking up so much processing power. If you want to know, I basically raycast at every touch and see where I'm colliding - I then use Physics.OverlapSphere to grab the tiles around that tile and then I turn their renderers and colliders off. When a column is "treadmilled" to the right, I turn everything back on. But, as I said before, even with colliders off the thing lags like nuts.

How can I optimize dynamic batching and drawing itself? I'm not entirely sure what culling is (I think it's the removal of objects that are not in view from being rendered/processed?) but are there ways to optimize that as well? I wonder if moving the camera as opposed to moving the tiles under a fixed camera is causing the issue?

P.S. I've sent a webplayer to your support address.

7

Support / Re: Poor Performance when moving a grid of sprites?

« on: August 10, 2012, 09:53:58 pm »

Sorry! I didn't look into the breakdown. Basically, most of it is being taken up by Render.TransparentGeometry and other alpha based operations. I'm not sure what they all mean and I'm sure you have a better idea, but if my sprites are all using opaque textures and shouldn't have any transparency to them, why is there so much work being done on transparent geometry? Is the map not being generated properly?

Here's a screenshot:

8

Support / Re: Poor Performance when moving a grid of sprites?

« on: August 10, 2012, 01:55:54 am »

Okay I finally figured out how to hook up the Unity profiler to the game while it's running on the phone. Basic results were basically this from CPU, with colliders on:

Avg Frame Rate: 4-5 FPS.
Physics.Simulate - 65%-75% Total Usage, 114ms-175ms.
Camera.Render - 25-30% Total, 50-90ms.

The rest doesn't compare to those two all that much performance wise. I then turned off colliders, and noticed at least some improvement in performance:

Avg Frame Rate: 12-15 FPS.
Camera.Render - 93% Total, 55ms
Physics.Simulate barely registered.

Obviously the colliders are a problem but I will screw around with them in a bit. The much bigger problem is that I'm not even able to render and move a grid of 60x40 physics-less tiles on an iPhone 4 at a rate better than 12 FPS. I've also tried locking Unity's Application.targetFrameRate to 30, but no noticeable improvement.

Any thoughts on why it's going so slow?

9

Support / Re: Poor Performance when moving a grid of sprites?

« on: August 09, 2012, 01:34:54 am »

So I ended up actually trying it with something more efficient than all - a simple plane rendered out of maya composed of two triangles. That's it. I ended up getting my tiling and cutting code to work with it. It's actually marginally better than 2D Toolkit - I get 5k vertices and 3 draw calls vs what I was getting using TK2DSprites (10k verts and 8 draw calls), but the framerate on a phone is still around 4-7 FPS. Really bad Also, these are not animated sprites.

Agh! I really need this to work smoothly. What are some next steps?

P.S. I will update to the newest version as soon as I get approval for the usergroup.

10

Support / Re: Poor Performance when moving a grid of sprites?

« on: August 09, 2012, 12:51:15 am »

I'm trying to do it with a plane but running into really strange rotation issue. I suppose I'll try it with the box!

11

Support / Re: Poor Performance when moving a grid of sprites?

« on: August 08, 2012, 11:50:22 pm »

I'll look into that! I'm trying to implement your first suggestion - how would be the best way to go about replacing sprites with native Unity objects? Should I use a plane with a texture on it?

12

Support / Re: Poor Performance when moving a grid of sprites?

« on: August 08, 2012, 11:19:12 pm »

Just kidding. I experimented in scene view and it looks like the TK2D camera preview isn't accurate or scaled properly at all. I had to move and scale the text mesh in Scene view to make sure it was the right scale and position for the camera. Let me know if there's a better way to do that.

13

Support / Re: Poor Performance when moving a grid of sprites?

« on: August 08, 2012, 11:09:01 pm »

I'll test those out within the hour and let you know. Quick side question: I'm having trouble getting a text mesh to show up. It's Z-value is above that of the tiles and according to the camera preview it's positioned properly, but it won't show up. Any ideas? I wanted to make a quick FPS counter.

14

Support / Poor Performance when moving a grid of sprites?

« on: August 08, 2012, 08:35:24 pm »

Hey there!

I keep reading reports of great performance on iOS using 2D Toolkit leading me to believe I'm doing something incredibly performance intensive without knowing it, but I was hoping someone could see my problem. Basically all I'm trying to do right now is generate a grid of tiles with a texture on them. Each tile is 16x16, so on a retina iPhone there are 60x40=2400 tiles on screen. Kind of a lot, but hey. The simple goal here is to be able to drag my finger and make tiles that I collide with disappear, kind of like 'cutting' a path through them. There's one more important bit: the tiles all move. The camera itself (and I'm using a TK2D camera) moves to the right, and as it does so columns of tiles are all 'treadmilling' - i.e. disappearing from the left and reappearing on the right, giving the illusion of sidescrolling. As I "cut" through tiles, they get turned to inactive. Once they get treadmilled, they're turned back on. Each tile has a collider on it that I use to help out with that 'cutting' detection and that I'll need for collisions later.

In other words, all that happens is:

• Simple for loop generates a grid of TK2DSprites that cover the iPhone 4 screen.
• Move the camera at a steady rate.
• Move tiles that the camera moves past to the front of the dirt grid.

What's bugging me is that even if I turn colliders off completely on the tiles, the framerate on an iPhone 4 is atrocious. I don't know what it is because I haven't put in a framerate display script yet, but I know it's probably lower than 10 FPS. My question has a few parts:

• Is the very fact that I'm moving the camera over 2400 tiles at once the root cause of the problem?
• If so, what is a better way to approach this? Should I move the tiles instead of the camera, etc?
• Are there any texture or sprite or sprite collection optimizations I need to do that are obvious? I just followed the tutorial - I have one sprite collection with one sprite in it that I use for the tiles.
• Will those colliders add a whole new layer of complexity to the problem or do I not really need to worry all that much about those?

Thanks!