Messages

1

Support / Re: Updating old project for Android

« on: August 16, 2019, 02:10:27 am »

Thank you so much for the help! I got it working with that and using Unity 2018.4. Still have some other fixes to do based on general Unity changes in the past few years, but my sprites are displaying.

2

Support / Re: Updating old project for Android

« on: August 12, 2019, 09:50:12 pm »

I'm targeting Android.

3

Support / Re: Updating old project for Android

« on: August 09, 2019, 03:26:38 am »

I gets lots of these errors using Unity 2017.4.

Sorry, I haven't touched C# code in about four years, and haven't kept up with Unity. Is there an edit I can use to replace these operators?

https://imgur.com/bE5nBWl

4

Support / Re: Updating old project for Android

« on: August 07, 2019, 01:47:05 am »

Yes, I'm using version control.

What's the cleanest way to update tk2d? Are there files I should delete from my project, and then install it from the asset store?

5

Support / Updating old project for Android

« on: August 03, 2019, 05:43:03 pm »

I'm trying to update an old project for Android that I haven't touched in a few years.

I last built it with Unity 5.0.1 and whatever the latest tk2d was at the time.

It no longer functions on Android. I assume something in Android broke older versions of Unity, and they must have since fixed that. But if I download the latest Unity, update my project, and import the latest tk2d, I have lots of shader errors and many of my sprites look pure black.

Is there an older combo version of tk2d and Unity I can use to update this "easily"?

I never had more than 50 downloads of this free app, but Google has started sending out notices that old apps must be fixed (even if unpublished) or your developer account can be suspended!!!

6

Releases / Re: 2D Toolkit 1.91 beta 1

« on: February 12, 2013, 02:00:01 am »

Here's some feedback.

I like the new features!

I'm missing the shortcut "Edit..." button in the tk2dSprite inspector window that takes you to the sprite collection.  When I have multiple sprite collections, it gets convoluted to try to find the right collection in the Project view and make little tweaks to a sprite.  That shortcut was very helpful.

In the Collection editor, under Texture Settings, it seems to me like the "User defined" checkbox is reversed. 

Also in the Texture Settings, I'm still unclear on what I should do with it if I just want to use my own shader for custom effects and be sure it won't get overridden.

Thanks!

EDIT: or is it as simple as just finding the material in the Project view, and then choosing a different shader in the inspector's drop down?

Did you put an explanation somewhere of how to use the Platform settings? Should I set Current Platform to the biggest one I want to support (4x for iPad3/4)? And then what do I do with Unity's quality settings?  I think I might want to just ignore this and use Unity's Quality settings and trilinear filtering so I can support a wide range of Androids as well.

7

Support / Re: Understanding draw calls

« on: February 05, 2013, 10:19:57 pm »

Your assumptions are correct. Kinda.
You've ignored what happens when you have more than one sprite collection visible at a time. At this point they are all sorted by Z, and batched according to sprite collection. Eg.
AAA BB AAA = 3 draw calls.
AAAAAA BB = 2 draw calls.
Which is why its always better to group by sprite collection on Z as well, when you can afford to.


About Unity dynamic batching - yes it costs quite a bit on CPU to check this. However, it ends up costing less than multiple draw calls and thus ends up being a win. The batching system tests each sprite, and then puts it into a big buffer to be drawn in one go with other sprites.

Unity Pro's static batching could help, but the static sprite batcher works, does almost the same thing and works in Unity Free too. You also have full control over what gets batched together, and the colliders are merged too, so I would say, in most cases, it would be a win for you to use the static sprite batcher over static batching in Unity.

Draw calls aren't nearly as bad as they used to be... You can have a few more than 10 draw calls on more modern hardware...

Question about the sorting process: is it done in the toolkit code, or does Unity automatically do this for all non-opaque meshes?

Reason I ask is I'm wondering if I mix in opaque meshes that are not toolkit sprites, do I have to somehow force a front to back draw order for them myself to avoid unnecessary pixel draws.

8

Support / Re: Deformable sprites?

« on: February 02, 2013, 06:16:14 pm »

OK, I've been comparing the Jungle Run to Origins, and see that they probably use a similar method of level design, although due to fillrate limitations I assume the one on the phone has to be very limited on extra decorations and doesn't have the six plus background parallax layers.

I found this video of a game engine that produces similar results. Is this basically what you were describing? (skip to one minute in)
http://vimeo.com/276937

I just discovered "Polygon Tool" on the Asset Store which when combined with 2D Toolkit can produce the same setup.

9

Support / Re: Deformable sprites?

« on: February 02, 2013, 05:37:24 pm »

Sounds interesting. Does this allow you to view a wireframe overlay?

Were you analyzing the PC version of Rayman Origins, or the Android version of Rayman Jungle Run?

Not really sure where to start with this program.  I clicked around in the four different apps (System Analyzer, Platform Analyzer, Frame Analyzer, Monitor) and haven't figured out how to connect it to my Android device.

10

Support / Re: Understanding draw calls

« on: January 31, 2013, 02:37:47 am »

That was extremely helpful, thank you!

So when it comes to dynamic sprites, such as enemy characters or particles, we could improve CPU usage potentially by disabling the renderers of groups of sprites that are known to be off screen?  For example, write a component that has a radius value big enough to always encompass all its dynamic sprite children, and check that circle/sphere against the frustrum each LateUpdate to decide whether all its dynamic sprite children's renderers should be enabled or not this frame.

11

Support / Understanding draw calls

« on: January 30, 2013, 12:16:12 am »

I've read in the past (a couple years ago so this probably relates to 3GS era hardware) that you can have up to 10 draw calls per frame before it starts becoming your bottleneck.

So with tk2d, are the following assumptions of mine correct?

• There is one draw call per frame per sprite collection sheet that has at least one sprite at least partially in the camera frustrum. So tk2d batches all visible sprites of each sprite collection sheet into one mesh, which becomes one draw call.
• A sprite is on screen if any part of it is in the frustrum of the camera, or if it belongs to a static sprite batcher that has any part of itself within the frustrum.

Does Unity basically take care of all of this for tk2d using its built in dynamic batching? Or does tk2d handle frustrum checks?

One thing I don't understand about Unity's dynamic batching is: doesn't it bog down the CPU for Unity to be checking every single dynamic mesh against the frustrum every frame?  I know older game engines used the VIS system to block out the maps so only a few large blocks had to be checked against the frustrum. Maybe that old method is analogous to occlusion areas in Unity Pro. I'm still not clear on Unity Pro's static batching. How does it decide whether objects are close enough to each other to group together, or does it even bother with separating objects with the same material into multiple groups to prevent the giant group from always being partially visible?

With tk2d, should we be messing with the "static" checkbox at all, or just use the tk2dStaticSpriteBatcher to handle that kind of thing?

12

Support / Re: Deformable sprites?

« on: January 28, 2013, 02:15:44 am »

Here's a shot from Rayman Origins, I think, where you can see where they seem to have one tile map for all the edges, which is deformable, and an underlying tilemap for the center bulk of the land.  The side/top tile map (or tile strips) fade out in the area I marked with black lines so there isn't an easily noticeable seam. And then they add a few plant sprites here and there on top of everything.

13

Support / Deformable sprites?

« on: January 28, 2013, 02:06:25 am »

I'm wondering how a game like Rayman Jungle Run handles world sprites.  There are lots of curved paths for the ground, but it some areas, I can see repeating patterns if I look closely.

My best guess is that a tile map is used for most of the middle sections, while tile strips are used for the sides and top. These tile strips could be placed on top of the edges of the middle tile map to hide them. But this method would require the tile map edge sprites to be croppable, and the tile strips to be deformable (like how I marked in red).

Are these possible future features for 2D Toolkit, or is that too complicated to work into the system?  Are there other ways to do this?

When I look closely at the screenshot, it looks like maybe only the top surface that you run on uses an overlayed tile strip, and for the rest of it maybe they just used a very high-resolution tile size and came up with many variations of tiles to get all the different edge possibilities. Not sure.

14

Support / Re: Source texture dimensions

« on: January 01, 2013, 06:25:11 pm »

No, the atlas was fine once I clicked Commit.

Here's the problem I had:

• Imported 256x128 png into Unity. Unity stretched it to a square and grayed out the Power of 2 setting in the Advanced mode of the texture import settings for the file.
• Running my own script above created a bunch of errors. Deleted file and imported a new one with a different name but same dimensions. Unity still streteches it to a square.
• Dragged it into my sprite collection. It appears as a stretched square.
• Clicked Commit. Sprite is no longer stretched in the sprite collection or in the Unity editor, although the import settings still show the Power of 2 setting grayed out (but now set to none instead of nearest).

Doesn't really matter since you already have it fixed. I was just curious what you did to get around that issue.

15

Support / Re: Render.enabled = false for offscreen sprites improves performance?

« on: December 31, 2012, 01:31:35 am »

Shouldn't make any difference, unless you can cull your sprites much more efficiently than the highly optimised built in Unity culling code. There are cases where this will be true (where you can make high level decisions and disable a significant amount of them in one go, for instance), but unless you have LOADS of sprites, it shouldn't make much of a difference.

It will make a difference for animated sprites, though.

Does tk2d recreate all geometry for all static sprites every frame, or only for sprites that wouldn't be culled by the camera?  If it's the first one, is this not a problem simply because recreating geometry is trivial compared to actually rendering it?  If it's only recreating some geometry, does it do this for each camera in the scene, or all at once?

If I have a level made up of a maybe a few hundred non-animated sprites, I can get away with not bothering with any of my own manual culling?