Universal SD / HD Switching for iOS (iPad / iPhone) - Refresh problem

[iandunlop_oefun]

Your pixel size for your iPhone atlas should be 1536/640=2.4

Sure - fair enough. However, that isn't the problem. That won't address the problem with atlas pixelSize being used inconsistently in the SDK / source.

[ArenMook]

How is that? UIImageButton is not even a widget. It's just a script that uses sprites. And sprites use the pixel size property just fine.

[iandunlop_oefun]

How is that? UIImageButton is not even a widget. It's just a script that uses sprites. And sprites use the pixel size property just fine.

I explained that in an earlier post. MakePixelPerfect is called in the OnHover, but not on the Start() method of UIImageButton. That difference causes the button to appear larger when I hover over it.

[ArenMook]

Correct, and as I mentioned the size of the button shouldn't change. Ever. That's what the pixel size is supposed to address. You use the same size on screen, while doubling (or halving) your atlas size. In your case you were not setting the proper pixel size, so your button size was physically changing when you hovered over it -- something that should not happen.

[ArenMook]

Just to clarify, the point of pixel size is this: MakePixelPerfect before the atlas change should look exactly the same size as MakePixelPerfect after the atlas change.

[iandunlop_oefun]

Correct, and as I mentioned the size of the button shouldn't change. Ever. That's what the pixel size is supposed to address. You use the same size on screen, while doubling (or halving) your atlas size. In your case you were not setting the proper pixel size, so your button size was physically changing when you hovered over it -- something that should not happen.

If I set the atlas pixelSize to 2.4, the button becomes even larger when I hover over it. I think I understand that you are saying you can't use atlases that are the same size. i.e. I have to make my iPhone atlas smaller. My point is that if pixelSize was handled correctly throughout the code then it would solve my original problem. Which I understand may be beyond the scope of the feature originally.

[loopyllama]

@ian
if you have a source art that is 80 pixels tall on the ipad 3 with a height of 1536, it takes up this percent of the screen:
80 / 1536 = 0.052 percent of the screen

if you used this same art on the iphone 4 that has a screen height of 640, it takes up this percent of the screen:
80 / 640 = 0.125 percent of the screen

this means if you use your ipad 3 art on the iphone 4 and set NGUI UIRoot to automatic, the art will take up more than double the screen space on the iphone 4, than when compared to the ipad 3. Set it to automatic!

(you do not want to do what you are trying to do, but if you reaaaaaally want to see it try setting your reference atlas replacement to None in the inspector. Then your script sets your atlas to whatever you want on detection)

@ArenMook
Earlier in your postings you mention to someone not to do something like this in a switch atlas script:
public UIAtlas refAtlas;
public UIAtlas iphoneHDAtlas;
public UIAtlas ipadHDAtlas;
and you suggest to do a Resources.Load because the above way will load all the atlases into memory. I think those are variables are just references/pointers to the file and assigning one does nothing more than point to the resource/prefab. In either case wouldn't you always want to set your replacement property in your atlas to null before shipping your app? I think the whole "atlas switching" is really a misnomer-- it is more of a "atlas setting" because the whole switching part of it really only happens with the developer sitting on his computer switching between atlases...meaning technically ian would never really encounter the switching issue because he should really be switching from null to his detected atlas...

[iandunlop_oefun]

Just to clarify, the point of pixel size is this: MakePixelPerfect before the atlas change should look exactly the same size as MakePixelPerfect after the atlas change.

Ok, but it won't in the case I ran into. Which is related to using the same size of sprites for both atlases, and making the iPhone atlas use a pixel size of 2.0. Perhaps the SDK could warn in the log when trying to do that? It just wasn't clear to me that you couldn't use it like this.

[ArenMook]

@loopyllama: Well, yes -- you can call it "setting" instead. I'm pretty sure referencing the atlas as a public property will result in it being loaded into memory when you load the level, so if you have both specified, both will be in memory, which is obviously something you don't want. Resources.Load simply ensures that they are loaded only when you need them. And yes, you will want to set the reference to null before doing a build.

[loopyllama]

@ArenMook
Thanks for clearing up the null reference atlas part.
I am pretty sure that a public member variable set to a prefab is a hint for unity to include that prefab in the build. I believe this does not consume significant memory. I believe Resouces.Load is equal to calling Instantiate on the public member variable. I hope I am right!

Edit: I am not totally correct. Use the Resources.Load method where performance matters!

[Nicki]

Anything in the Resources folder is included in the build, but not loaded until you load it specifically.

If you want something to use an SD atlas for low res iphone, HD atlas for iphone retina and ipad, while keeping everything pixel perfect (smaller on iphone retina than ipad) then make a little script that sets the UIRoot manual height different on the ipad. If SD atlas has a pixel size of 1 and HD has a pixel size of 0.5f, you set your root manual height to half the height of the highres device - that is, the same as SD iphone for HD iphone, and actual resolution height /2 for ipad (either 384 or 512).

[Nicki]

Loopy: You are wrong. Stuff referenced in a public member is loaded into memory when a scene is loaded. The prefab will consume as much resources as its assets demand. You can reference it by name (as a string) and load it via Resources.Load, then it will only take up memory when you actually instantiate it.

Instantiating a public variable, will make a clone of that object, consuming 2x memory (original + clone), I believe.

[loopyllama]

Nicki: partially, it gets loaded into RAM but not VRAM as ArenMook says.
On a mobile device this would be bad, so member variables is not the way to go...

[ArenMook]

You're both right, actually. The texture is in memory -- RAM, not video memory.

[loopyllama]

ok, ok! You are right ArenMook. It gets loaded into RAM with the reference. It gets loaded into VRAM when the object is instantiated.