Platform support only for multiples of 2?

[habitoti]

Hi,

is there any technical (tk2d internal) reason top only have platform support in multiples of 2 (as the platform support creation process suggests), or can I switch to arbitrary source resolutions?
Reasoning: coming from iOS, I have all artwork as hires sources made for 2048x1536 iPad Retina resolution. For Android, lots of devices out there still have 1280 x <something>, and just a few phones have <= 1024 x <something>. So for the latter, it would be less worthwhile to create the 2x of 1024 (vs 4x/2048) platform, but creating a "native" 1280-based set of atlasses would be very much of a useful additional effort.

Thanks for clarification,
    habitoti

[unikronsoftware]

No technical reason, but only multiples of 2 are officially supported. Everything else should work fine though. Its not officially supported because its easy to shoot yourself in the foot, e.g. with an anchor point which isn't perfectly divisible, etc.

[habitoti]

Can you shed some light on what parameters are affected exactly when switching platforms?

• Does Unit/meters change? (e.g. from 100 to 50 when having a 50% 2x res.?) -- and BTW: where can I read that param?
• Is the native res in tk2d camera adopted?
• Any other magic applied?

I am asking because I am using some stretching on background assets to fit all aspect ratios that is based on the above, which works great on my initial platform, and not so great with another platform now with smaller assets, so I assume there is more being changed in the background which I need to consider in my calculations...

The mentioned support for a 1280px width platform would mean a scale of 0.625 when coming from iPad Retina resolution (2048). My assets are now shown a bit too big on 2x, but if I scale them explicitly down by 0.8, they end up correctly. 0.625 x 0.8 = 0.5 -- so I assume you are making a fixed 50% assumption somewhere in your platform magic which would prevent to use it properly in the described way (though I believe this is THE most common and wanted usecase when transferring form iOS to Android, and looking through other threads a lot of people would like to do that...)

Thanks, habitoti

[unikronsoftware]

Units/meters does not change. The sprites are scaled to be the same vertical size as the base platform. So... if your 1x platform is the base platform, the 2x and 4x ones will be exactly the same size. tk2d does this by scaling the sprite by baseScale / targetScale.

[habitoti]

Yeah, I understand that this works overall for e.g. 2x = 50% 4x. My point is: my 2x is 62.5% of 4x. But somewhere in the process you still come up with a 50% scale now (with 4x being the initial platform). So only if I apply an additional explicit scale of .8 for each sprite, they will come up correctly. This is of course not a feasible option.

Can you tell me where the applied base scale is computed? It seems it needs to be adjusted for non multiples of 2.

Regards, habitoti

[unikronsoftware]

No, your 2x should NOT be 62.5% of 4x, it should be exactly half the size.  If you want non 2x multiples, add your own assetPlatforms in tk2dSystem - this is officially unsupported, but it works.

[habitoti]

Ok...your first answer above sounded like it would work out of the box  (and there doesn't seem to be much missing, actually -- just the correct computation of the scale...).

Is there any doc or sample for adding other assetPlatforms?

[unikronsoftware]

Nope, you'll have to add it in the file. No docs, samples, etc. Thats why its unsupported

[habitoti]

Just changed the scale factor for 2x in the assetPlatform setup from 2.0 to 2.5 (which is the actual relation from 1280 (2x) to 2048 (4x)) and regenerated platform data -- et voilą...everything works great now out of the box, including all stretch and rel. positioning calculations etc., w/o having to change anything else.

Really wondering why you are not leveraging such a great feature more, e.g. by introducing a freestyle platform setup in addition to the present 1,2,4x...

Just struggling still with not being able to set 2x programmatically (see other thread). Just won't work though everything looks right :-( 

[unikronsoftware]

Its too easy to break if you don't think about it. Ive thought about this a lot, and it boils down to the fact that I can't deal with any more support than I am at the moment. I really have to think of the support impact of each feature before adding it, especially as new unity releases seem to be breaking a lot more than they fix - I've pretty much got my hands full.

[habitoti]

Understood.

I think I am stuck now anyway at a point I haven't considered at first...when you create the platform data, all is just scaled (vs. creating completely new collections). That way I end up with non power of two textures for platform support...

I am now trying to start with upscaled 2560x1920 related assets for 4x and that way get a proper 50% version that is fully supported....

[unikronsoftware]

NPOT textures is really fine if you don't have mipmaps.

[habitoti]

I think on most Android devices textures need to be POT, respectively are made POT before transferred to VRAM, resulting in additional performance penalty, so I'd rather control upfront what kind of textures I do have. E.g. such a 1280x1280 would be converted to 2048x2048 then, though it would well fit to 1024x2048.

Having said the above, I am not even sure any longer that other platforms are just created through scaling (as I thought I saw in your code). I just have the issue of a 2048x2048 4x texture, that results in a 2048x1024 2x 50% texture, and I have no clue why it's not 1024x1024. All assets are strictly 50% of the originals, and there is a huge wastage on the 2x now, and the layout of assets inside the atlas is completely different. What could be the reason? Is dicing also scaled accordingly?

Just to mention: I am now on the supported path of just using multiple of 2 graphic assets, I dropped my intentions of going for "uneven" platforms to not run into more unsupported issues.

Thanks, habitoti

[unikronsoftware]

I think non compressed can be NPOT - AFAIK at least PVR & Tegra support it natively, so it shouldn't be too bad. I've seen restrictions with compressed textures. The max texture size is scaled, but if the textures fit in smaller it tries to find a better fit.

The padding is also scaled, you can force that to 1 on the highest res to make sure it isn't increased. tk2d plays it safe in the event you're downscaling & have mips, etc. The layout is naturally different because of padding. Dicing is also scaled. You can override anything you like in tk2dSpriteCollectionPlatformBuilder - it should be pretty straightforward.