Correct workflow setup for multiple resolutions...

[harry hayes]

What is the correct process is to setup a workflow for multi resolutions for ipad and iphone, - I'm sure this applies to android also.

This is the process as I understand it:

* Create the artwork at the highest resolution - so set a screen size of 2048 by 1536, and scale all other in-game assets to this.
* Export artwork 32bit transparent png.
* Import into game textures in Unity and set the target height in the sprite editor to 1536, ortho camera size to 1, and compression to reduced 16bit.

Then, setting the target height to 768, 960, 640 and 320 respectively and hitting 'Commit' in the editor will rebuild the atlases for all other hand held devices. I noticed though that if you tick the 2d camera checkbox these grey out - what is the significance of the 2d camera?.. wouldn't you still need to reset the atlas sizes?

Now...

From this point, do you have to make separate builds for each device, or do multiple resolutions build with as many as you want to group together? It must be the latter, because on the app store, you only see iphone, ipad or ipad HD.

If so, is this what you mean by 1x, 2x, and 4x in the Platforms tab because I couldn't grasp what this was about from the documentation alone.

Sorry to ask what might be an obvious question to some, but when you're starting out it can all be very confusing.

Thanks,
Harry

[unikronsoftware]

That is incorrect.

This document covers the basics of setting up platform specific sprite collections - i.e. 1x, 2x and 4x sprites.
http://unikronsoftware.com/2dtoolkit/doc/advanced/platform_specific_sprite_collections.html

In a nutshell
- you create multiple versions of your artwork at different resolutions, 1x, 2x and 4x, named as described in the documents.
- you follow the steps in the doc which will create the platform specific sprite collections.
- 1x, 2x and 4x are the sizes of the textures, the naming convention made popular by the iOS SDK. What this means is if you design your scene with the base resolution source textures at 2048x1536, these textures could be classed as 4x. The 2x set of textures would be half the size of these textures, and 1x would be a quarter the size.

You're free to use whatever convention you like. For example, the docs recommend you start with 1x, and scale up, rather than start at the highest resolution and scale down. This is probably slightly better workflow, as it will ensure everything is crisp at the lowest resolution, and automatically, everything will scale up correctly.

1x, 2x and 4x are just sizes for these textures. If you start with something, and then have the option to scale up AND down, then your default one would be 2x, and 4x would be twice the dimensions and 1x would be half the dimensions.

Once you understand that concept, everything else should make sense.

As usual, if you have any further questions, feel free to ask.

[harry hayes]

Thank you, I understand the 1x, 2x concept now. So seemingly, there's nothing to stop me from starting now at the lowest resolution and adding the other resolutions later?

So the purpose of adding    tk2dSystem.CurrentPlatform = "2x";   before loading is to view it and deploy it as a 2x build, while keeping the other versions handy in the editor for subsequent resolutions?

But you'd have to release four versions to cover all the iPhone generations - I must have missed the point big time here. Or does all four builds go out in one with an auto detection script for the optimal resolution.

Also, still not clear why the 2d camera shuts out the target height and ortho.

Sorry to bother you with this - I realise you're a busy guy.

[unikronsoftware]

The most ideal workflow at them moment is to start with lowest res and add higher res later.

The purpose of tk2dSystem.CurrentPlatform is to set it at runtime. All the versions are bundled with the app, but not loaded. Setting tk2dSystem.CurrentPlatform will then tell tk2d to load whatever particular sprite you want. There isn't an auto-detection script, but thats where tk2dSystem.CurrentPlatform comes in - you detect what you want, and after you've decided which version of sprites you want, you call tk2dSystem.CurrentPlatform to tell it to load what you want.

Using tk2dCamera sets fixed target height and ortho size parameters. You won't be able to change them as they need to be a special combination to work with the tk2dCamera.

[harry hayes]

Thank you for clarifying the use of the software.

I have to say, your support is second to none. Unity gave artists like myself a unique opportunity to become an indie developer that just wasn't possible before. This must be frustrating for yourself though when you're answering questions that must seem obvious to you. I'm going to go through all of your videos and documentation again to make sure I thoroughly understand everything to keep your disruption down to an absolute minimum.

I answered a poll on the software recently, and like myself the vast majority of your customers seem to be new to Unity and the the 2D Toolkit. If I might make a suggestion here - If you ever have the time (probably doubtful) A basic grounding on the problems that occur from outputting to multiple devices might be added as a prequel to your documentation, and how the 2D Toolkit gets round it. This would be really helpful to new developers, giving them (and myself) a better understanding of why those functions are there.

The 2D Toolkit is like a huge missing chunk from Unity that should have been in there. Hats off to you sir!..

Thanks,
Harry

[c-Row]

This is probably a noobish question, but do moving sprites need a multiplier in the source code to make sure distances also scale up in 4x resolution?

[unikronsoftware]

No, in most cases you won't have to care about any of that. The 1x, 2x, 4x sprites will all be physically exactly the same size, so distances will still be the same. What changes, however, is the amount of detail in them.