In addition to giving SM2 its own thread (since SM1’s thread is now 37 pages long!), I’m proud to announce that SpriteManager 2 RC2 is now available. As before, SM2 makes working with 2D sprite-based graphics in Unity FAR, FAR easier (everything can be setup in-editor visually). And this latest version features improved performance (now almost 2X faster than RC1 for large numbers of animated sprites), new features and enhancements have been added, and for those of you doing your work in Unity 2.6, you no longer have to manually set all your source textures’ import settings.
I’ve been using SM2 RC1 for a few days now and it has really helped speed up my dev time! Thanks!
I haven’t updated to RC2 yet, is there any trick to updating? Should I just import the new .unitypackage directly over the top of the existing install in my project or should I clean out the old folders first?
I believe just re-importing the package should work fine as I think Unity will detect the newer file dates and should notify you that it is replacing the files. You can verify that the correct versions were written by checking the headers of BuildAtlases.cs (in the Editor folder), SpriteBase.cs, PackedSprite.cs, and Sprite.cs. Each of them should say “RC2” after the version number at the top of the file.
But I suppose it wouldn’t hurt anything to remove the old ones.
I’m glad it’s helping you out! Thanks for using it.
Bought it with RC1 and can only agree, it saves you really time if you are doing 2D work and lets you focus on the important thing instead of messing around with more or less complex constructs either of 3D model data with bones or alternatively longwinded code constructs with SM1 / SpriteUI
Any plans to hook this up with some sort of GUI manager? I don’t do any sprite based games, but I would love some of this tech being leveraged into a more optimized and versatile GUIManager for GUI-heavy games. Specifically I am interested rollover buttons and text.
Rollover buttons in the current GUIManager are kinda goofy in that they don’t return to the up state when you push down and then drag away from the button. Some hacky work-arounds make them function most of the time, but they aren’t nearly as effective as native Unity GUI buttons despite their draw call savings. They also have problems with pixel-perfect rendering.
As for text, in the past it has been impossible to do text as a sprite sheet due to non-uniform character size, but with the new SM2 doing non-uniform sprites I bet you could cook up something clever and fancy
Mattiumus, you make some good points. I’ll definitely have to do some more thinking about this… I’ve had a lot of requests along these same lines. Thanks for the input! I really appreciate it, and it helps me decide which direction to go in the future.
a) single seat license, does this allow installing it on a PC AND a Mac version of Unity (for one person)?
b) Will the original sprite manager be moving to a paid license version?
c) Is there a speed increase over SM1? I’m a month or so away from releasing an iphone game using SM1 and am just wondering the benefits of upgrading, or if it would be better to just wait until the next game to start using SM2
Also after watching the videos having a visual indication of your sprites without having to have the game running is so awesome - thanks Brady
Thanks for your interest, jbury. These are actually great questions:
a) Yes, you may use it on as many computers as you need to get your work done, it’s more about the number of people in your team than the number of tools you use.
b) No, SM1 will remain free, and would have to since everybody and their brother has a copy of it anyway.
c) I haven’t run any side-by-side comparisons with SM1, but I would venture to say they’re probably both about the same. There may be some differences however depending on how you’re using it. For example, SM1 had to “manually” transform the sprite vertices in script, whilst SM2, when used with Unity iPhone, takes advantage of dynamic batching, which gets performed using native code which should be much faster.
Now I don’t know if 1 month is a significant portion of your total development time, or if you’ve just recently started your project. I would say, if you’re getting really close to completing your game (i.e. pretty much all the sprite setup code is already done), my advice would be, if it ain’t broke, don’t fix it. Unless you still have some ways to go in finishing the setup of your in-game sprites, and therefore you can really benefit from the dramatically increased ease of use offered by SM2 (and the time savings it offers), I’d use SM2 in your next game and finish your present one with SM1. But that’s just me. If, however, you still have lots of sprite work left to do, it might be worth it to save time now by using SM2.
UPDATE: I have released RC3 to address a bug discovered by field testing RC2. This bug had to do with the new animation pump. Sometimes, setting a particular sprite’s .active property to false could kill the animation pump for all sprites. This has been fixed by moving the animation pump to an external class that is automatically instantiated by the first sprite object at runtime - so no changes to the workflow, it “just works”.
I apologize for having to release an update so quickly after the previous release, however, I’d rather my customers have the best possible code I can deliver.
Thanks everyone, and thanks to those who helped discover this issue.
I’ve just being playing with SM2 RC3 and I noticed that after creating a new sprite (PackedSprite) it will automatically create a new game object in the hierarchy named “New Game Object”. This object seems to be disabled and has the “SpriteAnimationPump” script attached to it. Is this normal with RC3? At the moment I’ve created a new scene and created one sprite using the “PackedSprite” script, … ATM I have three (3) “New Game Objects” in the Hierarchy and they wont go away even after I stop playing the scene. At one stage I had about 25 of them in the Hierarchy, basically every time I stop playing the game it automatically adds two (2) new “New Game Objects” to the Hierarchy which I cannot delete. If I restart Unity most of them disappear.
It would appear after my initial investigation that GameObject.hideFlags doesn’t not appear to work as advertised in the Unity docs. For some reason, it is causing the object to not be deletable. This bug appears to have been fixed in 2.5/2.6 as the problem only seems to occur on Unity iPhone. I’m working on a fix right now. Stay tuned.
UPDATE: I’ve written a workaround for the bug in Unity iPhone 1.5 related to .hideFlags. However, the next release is going to be delayed a day or two as I’m finishing off an incredible new feature that’s going to blow you away.
In the meantime, the hideFlags bug shouldn’t actually be hurting anything, it just results in a bunch of “dead” GameObjects that should not interfere with normal operation. But if you’re at a point in your project where you really can’t wait for the fix and need to do a production build, send me a message and I’ll send you an interim version with the fix right away. Otherwise, expect the new release as early as Saturday, or as late as Sunday night.
How do you control the order that overlapping sprites are drawn? I have a UI gadget sprite that is a fuel bar with the word FUEL in the middle, then I have a fill sprite that appears under the word Fill. I can’t seem to find a way of telling SM2 that I want the bar sprite drawn after the fill sprite.
I was previously using GUIManager but changed my code to use SM2 only.
In SM2, each sprite is a separate mesh which, if using Unity iPhone, gets dynamically batched. So draw order is handled by Unity, which is based on distance from the camera. So things you want drawn “ontop” should be a bit closer to the camera than the things you want “behind”. The difference doesn’t usually have to be very much.
