Messages

1

Support / Re: Commit sprites using StaticSpriteBatcher in runtime.

« on: June 28, 2013, 12:56:46 am »

@unikronsoftware Ah ha, thanks, I appreciate the link. I think the main thing I was missing was how to use tk2dBatchedSprite. FillBatchedSprite does a lot of stuff but your DynamicCreateBatcher script looks like it does just what is necessary.

2

Support / Re: Commit sprites using StaticSpriteBatcher in runtime.

« on: June 27, 2013, 09:03:42 pm »

Could you go in to more detail on these steps? I'm not sure what to do for step 2 and I'm unable to get this to work. I tried using the tk2dBaseSprite's spriteCollection, but no joy.

I've got an array of tk2dBatchedSprites (made using a set of instantiated GameObjects w/ tk2dSprite components and a copy of the editor's "FillBatchedSprite" static method) but the resulting static sprite batcher does not render anything until I click "Edit" and "Commit" while in runtime.

Should there be a step 5: Destroy all of the tk2dSprites created while creating the tk2dBatchedSprite array?

3

Support / Re: Best way to rotate sprites?

« on: June 18, 2013, 04:01:49 pm »

OK. Thanks. I made the sprite a child of the gameobject. That seems to work OK but it means I have to manually set the box collider (in the parent object) or split out the rigidbody control and collider code in to separate scripts.

4

Support / Re: Best way to rotate sprites?

« on: June 18, 2013, 02:28:20 pm »

Unfortunately that doesn't seem to do it. The object gets rotated such that it is invisible to the player, perpendicular to the camera and rotated kind of weirdly otherwise. I think it's because the object itself has some rotation in order to move in a particular direction.

I should have mentioned this before but I am using the tk2d Camera for the scene. Is there a way to rotate the sprite as displayed in that camera without having to rotate the game object?

5

Support / Best way to rotate sprites?

« on: June 18, 2013, 05:06:23 am »

What's the best way to rotate a sprite with the 2D Toolkit? I am currently rotating by using Quaternions but I'm hoping there's a 2D Toolkit way to do a basic rotation without much fuss.

6

Support / Re: Mesh collider's mesh disappearing on play

« on: June 08, 2013, 06:05:06 pm »

I found a way. Sorta. I added a new menu option to Assets that allows me to save a mesh to a file. So, the workflow is:

* Create the sprite batcher
* Add sprites to it, position 'em
* Click commit in the sprite batcher
* Add a mesh collider to the sprite batcher
* Save the mesh (Select the sprite batcher, then go to Assets -> Save -> Mesh)
* Delete the mesh collider from the sprite batcher
* Add a new empty game object, make it the parent of the sprite batcher. Fix the positions.
* Add a mesh collider to the new parent. Drag the saved mesh to the mesh collider's "mesh" selector.

You'll need to repeat the last few steps every time you change the sprite batcher contents.

I've attached the script I made. It's my first editor script, it may not be right, but it's a start.

7

Support / Re: Mesh collider's mesh disappearing on play

« on: June 08, 2013, 04:52:39 pm »

OK, I'll give that a shot. Do you have tips on how to get the mesh collider to use the child object's mesh?

8

Support / Mesh collider's mesh disappearing on play

« on: June 08, 2013, 02:55:19 am »

I have a sprite batch containing a set of walls and stuff that I want to use as obstacles (ultimately using the A* Pathfinding Project: http://arongranberg.com/astar/docs/getstarted.php). In order to get the pathfinding system to recognize the walls as obstacles, I have to attach a mesh collider. When I attach a mesh collider and re-scan the scene everything seems to work right -- the obstacles are recognized as impassable -- but when I click play the mesh collider's mesh disappears. If I reset the mesh collider the mesh reappears but only until the next time I click play.

I tried this with a sprite batch and with a regular ol' sprite, same result. This doesn't seem to happen with other objects outside of the 2D Toolkit. Any idea what I might be doing wrong? I'm hoping this rings a bell for someone.

9

Support / Re: Tutorials on 2D Platformer style controls/physics? So floaty :(

« on: May 28, 2013, 01:00:46 am »

Thanks for your help. The suggested fix was to increase the size of the collider depth (SpriteCollection -> Open Editor -> Settings (change the value) -> Commit) to something like 100. That does help. It's not perfect, but that ends up being more on Unity.

10

Support / Re: Walking Animation Then Idle Problems

« on: May 26, 2013, 06:40:41 pm »

You've got your anim.Play("idle") code set up as an else only to your test for the a-key input. I think some of the whitespace got lost in the paste (not sure though), but basically here's what I got when I re-indented the code:

Code: [Select]

  void Update () {
    if (Input.GetKey(KeyCode.A)) {
      // Only play the clip if it is not already playing.
      // Calling play will restart the clip if it is already playing.
      if (!anim.IsPlaying("walkLeft")) {
        anim.Play("walkLeft");

        // The delegate is used here to return to the previously
        // playing clip after the "hit" animation is done playing.
        anim.animationCompleteDelegate = HitCompleteDelegate;
      }
    } else {
      if (!anim.IsPlaying("idle")) {
        anim.Play("idle");
        anim.animationCompleteDelegate = null;
        walking = false;
      }   
    }
    if (Input.GetKey(KeyCode.D)) {
      if (!anim.IsPlaying("walkRight")) {
        // Walk is a looping animation
        // A looping animation never completes...
        anim.Play("walkRight");

        // We dont have any reason for detecting when it completes
        anim.animationCompleteDelegate = null;
        walking = true;
      }
    }
  }

I think this makes it more clear that the idle code is only called in one condition. While this would not be the ideal end solution, if you moved your if Input.GetKey(D) up a bit, you'd probably get the result you want for now, like so:

Code: [Select]

  // Update is called once per frame
  void Update () {
    if (Input.GetKey(KeyCode.A)) {
      // Only play the clip if it is not already playing.
      // Calling play will restart the clip if it is already playing.
      if (!anim.IsPlaying("walkLeft")) {
        anim.Play("walkLeft");

        // The delegate is used here to return to the previously
        // playing clip after the "hit" animation is done playing.
        anim.animationCompleteDelegate = HitCompleteDelegate;
      }
    } else if (Input.GetKey(KeyCode.D)) {
      if (!anim.IsPlaying("walkRight")) {
        // Walk is a looping animation
        // A looping animation never completes...
        anim.Play("walkRight");

        // We dont have any reason for detecting when it completes
        anim.animationCompleteDelegate = null;
        walking = true;
      }
    } else {
      if (!anim.IsPlaying("idle")) {
        anim.Play("idle");
        anim.animationCompleteDelegate = null;
        walking = false;
      }   
    }
  }

At some point you'll probably want to change this entirely, so that the walking animation is based on the character's actual movement (based on the speed, direction, change-of-direction, etc) but eh. This'll work for now.

11

Support / Re: Tutorials on 2D Platformer style controls/physics? So floaty :(

« on: May 26, 2013, 04:04:53 pm »

Can you send that test scene + script to support at unikronsoftware dot com? If you're using the built in collections, you won't need to include the rest of the project.

I wasn't using the built in collections (just some of the graphics while learning how to use the collections), so I sent the whole project.

12

Support / Re: Tutorials on 2D Platformer style controls/physics? So floaty :(

« on: May 26, 2013, 03:43:00 am »

It seems as though increasing your gravity above some threshold (I'd say around -40 or so) causes the Discrete collision detection to break down; rigidbodies end up overlapping or getting wedged in box colliders. Is there a better way?

A gravity value of around -98.1 (using default tk2d camera settings) seems to be the right value as far as gravity itself is concerned, at least, and it works mostly fine if your collision detection is set to Continuous Dynamic. I'm just not sure if that's the right solution.

I noticed that the Box Stacking demo script uses a regular ol' Orthographic camera w/ size 10. Would it be possible to create an example scene identical to that one but with the tk2d camera instead? For now I've reverted to using the "default" camera that comes with Unity (as in the Box Stacking demo) and it seems to be working OK with a gravity of -9.81.

Setting up a tk2dCamera scene with Unity physics usually requires the physics settings to be changed. This unfortunately can't be distributed in a unitypacakge or asset store package.

I wrote up a post on how to configure Unity physics to work best with various camera configurations here:
http://unikronsoftware.com/2dtoolkit/forum/index.php/topic,1746.0.html

I switched from the default type of camera to tk2dCamera and then tried changing the gravity to -300. The physics is all jacked up, though. I built a scene that demonstrates the problem: http://bybeardy.com/game/project8/Build.html

The gameobjects are all set up using box colliders built by the sprite collection code. The crates have rigidbodies (mass 1) and box colliders. The player has a character controller and a box collider.

I am a newbie when it comes to Unity, so I could well be doing something horribly wrong, but as far as I can tell increasing the gravity causes tons of problems.

13

Support / Re: Tutorials on 2D Platformer style controls/physics? So floaty :(

« on: May 25, 2013, 12:36:36 am »

It seems as though increasing your gravity above some threshold (I'd say around -40 or so) causes the Discrete collision detection to break down; rigidbodies end up overlapping or getting wedged in box colliders. Is there a better way?

A gravity value of around -98.1 (using default tk2d camera settings) seems to be the right value as far as gravity itself is concerned, at least, and it works mostly fine if your collision detection is set to Continuous Dynamic. I'm just not sure if that's the right solution.

I noticed that the Box Stacking demo script uses a regular ol' Orthographic camera w/ size 10. Would it be possible to create an example scene identical to that one but with the tk2d camera instead? For now I've reverted to using the "default" camera that comes with Unity (as in the Box Stacking demo) and it seems to be working OK with a gravity of -9.81.