Hi guys,
Is there any solution for swapping between sd/sd texture atlases (for sprites)?
I have two kinds of assets:
iPad Retina - 2048x1536,
iPhone 4 and 5 - 960x640
Now game is based on iPhone assets, how can i dynamically swap them with iPad?
Hi guys,
Is there any solution for swapping between sd/sd texture atlases (for sprites)?
I have two kinds of assets:
iPad Retina - 2048x1536,
iPhone 4 and 5 - 960x640
Now game is based on iPhone assets, how can i dynamically swap them with iPad?
The sprite renderer component has a sprite property exposed that you can dynamically assign sprites to in code.
// assign your SD and HD sprites in the inspector
public Sprite sdSprite;
public Sprite hdSprite;
void Start() {
if (iPhone) {
renderer.sprite = sdSprite;
} else {
renderer.sprite = hdSprite;
}
}
I hope this helps.
edit The code will not work as is but should give you insight on how to accomplish it.
Or you could use 2Dtoolkit which provides this functionality automatically
I really wish people would stop saying âso and so plugin will do this for youâ. Thatâs not the point. If somebody wanted to know which plugin was best for something they wanted to do they would ask it specifically. This is a community support forum, not a âplug your favorite assetâ forum. Use the asset store category for that and allow people to learn how things work.
Ok Iâll stop doing that.
So if someone is banging their head against their desk with the limitations of release 1.0 implementation of the 2d native tools, suggesting an alternative to a concussion doesnât seem appropriate? (trick question asâŚit is.) The 2D tools will get better for sure, but for now, helping each other with what works is more relevant than anyoneâs âwishâ.
This topic has appeared on quite few forums and going through different ways of handling it I believe that for mobile development (especially) it is the best to make 3 atlases, each for different device screen definition, ex: SD, HD, UD.
That way you can cover most of mobile phones and tablets. Starting from preparing assets for the largest one you could go down to the smaller one and as it has been mentioned above (1) replace reference to the atlas depending on the device size and (2) adjusting pixel size to keep everything in place.
Here is what worked for me:
definition | resolutions | pixel size
-----------+-----------------+------------
SD | 960 x 640 px | 1.25
HD | 1024 x 768 px | 1.0 <- default atlas
UD | 2048 x 1536 px | 0.5
And here is the link to the article on how to handle resolutions and aspect ratios if you need more info. I have just added that to the Game Manager I am creating so hopefully will be able to post some
Most of the people in these forums are indie developers with little to no budget for buying things. I just saved him $65 by explaining how he could do ittheoritically using native unity ways. You have a valid point in your statement but my point was that telling someone that an editor extension will solve his problem is kind of counter productive if you are coming here to learn like most here in fact are. Iâm sorry if I offended anyone.
Unity will load sdSprite and hdSprite at the same time. I dont want this.
I seen Sprite Collection, it is based on Meshes not Unity 4.3 Sprites.
Not sure what you mean here, it wonât load them both into memory.
Are you trying to saying you that you do not to include both images in your build? If that is the case you will need to make two separate builds, one HD and SD, and offer them as two packages in the App store. That is a common practice.
If you only want to release a single build, there are a couple of ways. First you can just include both sets of images and use the proper ones at runtime. Either with something like unitylover described, or some overall system to handle it. This will, of course, increase your app size. The second way is to only include the minimal amount of images needed to get to a certain point (splash screen, menu, etcâŚ), then download an asset bundle containing the images for the specific resolution remotely. This will give you a very small initial download. Downside is that users will have to wait when launching while assets are downloaded. This also means that you will have to have a storage solution. And maintain multiple packages.
Thanks for your answer.
Somebody in other thread tell me that Unity will load all assets that are referenced in scene.
I want single build with SD and HD. I have many sprites (~800) that are referenced in many places (in SpriteRednerers, AnimationClips, custom MonoBehaviors etc.). So i dont want to change all those sprites but only change them textures.
Thats what i want to do. I need a solution how change textures.
Well, you could write a script that extends/attaches to those classes and preforms a check/swap. The best bet would be to have a handler at all those points, build a tool that makes the determination and loads the appropriate image. But it will take time to edit, but I donât know that there is way to handle it global. Not that there isnât, I just donât know of one. You could also write some a script(s), to go through your code and automate making the changes (at least to a degree).
Possibly, if you are using atlases, you can swap them at that point, but I have never tried it that way.
If he hired a coder to resolve this, I imagine it would cost a wee bit more than $65. If he doing it himself, and as every developer should, apply a dollar amount to time invested on a project, it would again, likely exceed $65 worth of his time, I would imagine. But thatâs a producerâs view versus a coderâs view. Moving the ball down field being more important that doing every task oneâs self. Items such as NGUI, 2DTK or AI Behaviors are a godsend and often the only way an indie can advance a project.
That said he could accomplish this functionality by writing it and testing. Or as Kurious and I suggested, he could also take a peek at this.
http://www.unikronsoftware.com/2dtoolkit/features.html#sprites
It might be worth the $65- to have a proven, turnkey solution along with the killer customer support that Unikron has always provided. Moving the ball down field in production, especially for an indie is often more important that doing it all yourself, though granted, not always. I guess itâs a divergent point of view. But as long as anyone can come in here and get honest enthusiastic help from folks like yourself or ZombieGorilla or even a non-coder artist type like me, as Martha would sayâŚâitâs a good thing.â
Amen!
Well said. If you are a individual or small team and your project looks like it is going to have a lot of, well⌠anything (for example around 800 sprites), it can be well worth it to look into proven solutions like those mentioned early on. Granted, it is easy for things to happen that you donât plan for or a project to grow, but as much planning upfront that can be done, the better.