SM2 - 2D made easy and efficient!

[steddyman]

Stupid question time.

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.

Thanks

[Brady]

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.

If that doesn't fix it, let me know.

[steddyman]

Great, thanks for the rapid response.

I had tried that, but forgot I have my camera facing backwards so needed to put the ones in front at a lower Z value.

Now working fine. Much easier to use than the previous methods.

Steddy

[greensquidsolutions]

Hi,

I am very curious about SM2, however there's no demo to try out. Do you have one hiding which I didn't see or could I play with an eariler version?

Thanks

[Gaspedal]

how fast is SM2 ?

how much frames on iPhone would I get, when I render 20-30 animated Sprites at same time ?

I need a very fast Sprite Engine

[Brady]

greensquidsolutions:
Unfortunately, I don't have a demo version that can be tested since it is source-code only. I do plan on releasing a free performance demo for iPhone however so you can see its performance on the device. In addition, you can check out the videos on my site that show how it is used.

Gaspedal:
It is pretty fast. Combined with dynamic batching in Unity iPhone, you can get really good performance. I can get 100 fully-animated sprites with all the features turned on running on an iPod 1st gen (the slowest) at about 40fps. And that's running at a high animation framerate. At slower animation framerates, you can get even better performance. And with only some of the sprites animating at one time, I could easily see 60fps (the iPhone cap).

As I wrote above, I'm going to try and get a free performance demo out on the AppStore for people to try out.

Thanks for all your interest!

[Mattimus]

My current project is a very GUI-heavy game. I have spent about 15 hours in GUIManager on it to try and boost performance of the interface. Hours and hours of work of manually building an atlas, recording atlas coordinates, and rebuilding the interface inside Unity. When it was all said and done, the interface was messy, hard to operate, buggy, and ran less than 0.1 fps faster than the same scene built with native Unity GUI elements. Needless to say, I'm frustrated.

And then I read this:

[dreamora]

You will have to write such classes, there aren't any GUI commands actually.
But if you are able to get basic rect checking and the few lines of code to switch the animation, thats not much of a problem

[steddyman]

I was using GUIManager for my game but the interface wasn't as complex as yours sounds.

I converted mine to use SM2 in about an hour. More importantly if I had access to SM2 at the time I did the work originally I would have saved a day or more in creating the texture atlas.

GUI's are easy to do with SM2, but you need to create your own graphics. Just do the following:

1. Create your individual drawing elements in something like Photoshop.
2. Create GameObjects and attach the PackedSprite script to them
3. Drop the texture for each element onto the PackedSprite script and set any properties you want to change
4. Place the GameObjects for the GUI's into the GUILayer
5. Create a new Orthographic Camera object and tell it to only show the GUILayer

All very easy and quick to setup. SM2 is a great product and well worth the asking price in my opinion.

[tau]

@Brady: good job on SM2! just in time of my next project.

I've got few questions:

1) is dynamic batching available in iPhone 1.5 Basic with SM2?
2) what will be a correct way to perform sprite collision check with SM2? is it possible to do that based on pixels? or should I still use a collision mesh?
3) might be a stupid one: is it possible to zoom in/out a pixel perfect sprite? Sometimes I like to change zooming on some actors during camera shakes.



Thanks!

[cheezorg]

[Brady]

You're exactly right cheezorg.

2) I'd recommend primitive or compound colliders, in that order, and if neither of those will work due to sprite complexity, then I'd recommend a convex mesh collider. But if it's an animated sprite, you're much better off doing a primitive collider (sphere, box, capsule), since this can be easily resized/positioned during the animation to fit the sprite, whereas a complex arrangement of compound colliders, or a convex mesh collider, cannot be easily changed. Then again, I suppose you could use different arrangements/meshes that you selectively turn on/off based on the animation frame, but that sounds like it would be a lot of work, but certainly possible.

3) What cheezorg said. The way pixel-perfect works is by resizing the sprite to fit the ortho camera. So by definition it can't be zoomed, lest it not be pixel-perfect anymore. So in such a case, you'd want to use Auto Size instead if you still need the automatic resizing.

Also, note that if you're using pixel-perfect sprites on ortho cameras that will be resized for things like GUI (in which case I'd just recommend using a separate GUI-only camera for that instead), you'll need to inform the pixel-perfect sprites that the camera has been resized so they can adjust immediately. How to do this is explained in the docs.

Thanks for the questions!

[Gaspedal]

What do you think is better?
is it better and faster to makes a own 2D collider-lib without using Unity colliders ? A simple 2D collider that checks the x,y position between 2 objects within a radius.

by the way: just bought your lib

[Brady]

Thanks, Gaspedal!

Hmmm... I'm not sure. If you're doing an actual radius check, I think that might be expensive since it usually involves a sqrt(). But I suppose it would depend on how many collision checks you're doing. But if it's not an actual radius, but more like a squared distance or Manhattan distance, it could probably be pretty fast, again depending on how many checks you're doing per-frame. Just remember, however, that the physics (including collider) code is all in native code, whereas anything you write will be in script, which will be significantly slower. That said, you might do up a little test case and see how the speed is.

[Brady]

RC4 is now available, and includes a great new animation timeline editor! See the first post for a screenshot and look for a demo video of this new feature on my site within the next few days.

Have fun, everyone!