Any chance to get this to work on Unity 3.5.7? I am still on that version because of the pro plugins I have. Thanks!

Click to expand...

I dropped Unity 3.5.7 support on the last version because it was too much work managing all the different combinations (Unity / NGUI). Having said that, it should just work - I just don't offer support for it.

1. It seems to rely on UIRoot, which I do not use. Anybody has the patch for UIOrthoCamera to work with the plugin?

2. HD assets use 0.5 pixelsize in the atlas. However it's unclear for me how to manage the size of the BoxCollider then? It stays the size of SD asset.

3. All atlases have to have same sprites. If a sprite is needed for just one device, it still has to be present in all atlases, even as a 1x1 placeholder?

4. Looks like I completely miss the logic of the plugin, any help is appreciated. As i understand, it switches atlases in runtime to match the current device. So all devices' atlases are packed into the app. While making sense for testing, such approach sounds useless for production apps. I expected that this plugin offers a switch, so i choose "ipad @2x", refresh atlases and push Build to make retina iPad production build, with only iPad@2x assets packed into the app. Then choose "ipad" and make second build specific for regular ipad, etc. I have absolutely no need to switch devices at runtime, as there are virtually no physical devices with screen switching.

5. The whole SlicedSprite discussion is relevant only for runtime resolution/atlas switching, right? So if I'm building for specific device and SlicedSprite size won't change, the only thing to take care of is that borders are fixed across all atlases, so SD sprite should allow for HD borders pixel size.

4. Looks like I completely miss the logic of the plugin, any help is appreciated. As i understand, it switches atlases in runtime to match the current device. So all devices' atlases are packed into the app. While making sense for testing, such approach sounds useless for production apps. I expected that this plugin offers a switch, so i choose "ipad @2x", refresh atlases and push Build to make retina iPad production build, with only iPad@2x assets packed into the app. Then choose "ipad" and make second build specific for regular ipad, etc. I have absolutely no need to switch devices at runtime, as there are virtually no physical devices with screen switching.

Click to expand...

The advantage is that you can ship a single universal binary. I'm not sure I understand why you think it's a bad feature for runtime. Could you further explain your use cases? It sounds like you want to push out different builds for iPad and iPad Retina - but I'm not sure that is practical or even supported on the AppStore.

5. The whole SlicedSprite discussion is relevant only for runtime resolution/atlas switching, right? So if I'm building for specific device and SlicedSprite size won't change, the only thing to take care of is that borders are fixed across all atlases, so SD sprite should allow for HD borders pixel size.

Click to expand...

The sliced sprite uses the transform scale in NGUI 2.7 for it's actual size - that conflicts with using the scale for keeping a piece of art pixel-perfect. If you only ever have a single resolution then you are correct it doesn't matter (especially if you're not using UIRoot).

The advantage is that you can ship a single universal binary. I'm not sure I understand why you think it's a bad feature for runtime. Could you further explain your use cases? It sounds like you want to push out different builds for iPad and iPad Retina - but I'm not sure that is practical or even supported on the AppStore.

Click to expand...

It's simple - to stay under 50 megs. Google Play supports custom builds, but you're right and the only option in AppStore is separating iPhone and iPad apps. Would have to think about downloadable art packs then.

It's simple - to stay under 50 megs. Google Play supports custom builds, but you're right and the only option in AppStore is separating iPhone and iPad apps. Would have to think about downloadable art packs then.

Click to expand...

I haven't looked at UIOrthoCamera. Thanks for the info.

Regarding the App Store / download limit - they raised that to 100MB. I know it doesn't directly address your use case but it does help

We've been using RetinaPro on a e-book project for awhile now, and I have a few suggestions. I've implemented a few of them myself, but trying to keep them intact when updating RetinaPro is a pain so I thought I'd mention them here.

1. Keeping atlases sorted by name in the atlas window. We have quite a few in our project, so not having them sorted became annoying after awhile. I added a button to the atlas window to trigger the sort, but an auto-sort might be better.

2. 'Refresh all' button for atlases. I added this to the atlas window as well because refreshing each atlas manually after updating textures was taking awhile. With a refresh all I can update all the art, hit refresh all, and go do something else (for a few hours...)

3. Expose all atlas options in the atlas window. If you look at NGUI's Atlas Maker tab, when updating an atlas there you also have options for using a pre-multiplied alpha shader, trimming alpha, using Unity's texture packer, and (if not using Unity's texture packer) forcing square atlases.

4. Store atlases (and textures) by name + device suffix only. I haven't implemented this one yet, but I think it would make the project structure a little cleaner. When I'm working on a single atlas, I have to do a lot of scrolling/folder closing just to look at the atlas or textures on each different device. I think it would be better if I could just look at the suffix in a single folder to tell what device it's for. So maybe it could look more like this:

Anyway, just some suggestions. I think the project we're using this on is probably not even close to the normal usage (way more atlases and textures), but I'm sure these things would help our workflow quite a bit at least.

One last thing, I think we may have also found a bug in building atlases on iOS, but I don't think it's specific to RetinaPro. Basically, if the atlases are set to compress then PVR compression runs on the atlas each time a sprite is added to it. And occasionally this will hang for some random amount of time before moving on to the next image. I see the same problem if I just update the atlas through NGUI's Atlas Maker too though, so it may be some kind of focus issue with Unity. Just thought I would mention it in case you had seen it before.

We've been using RetinaPro on a e-book project for awhile now, and I have a few suggestions. I've implemented a few of them myself, but trying to keep them intact when updating RetinaPro is a pain so I thought I'd mention them here.

Click to expand...

Hi Josh, thanks for the feedback and suggestions. I like some of these ideas and will do my best to incorporate them into a future release.

If you're using RetinaPro or following this thread then you probably know that the current Unity Asset Store version of RetinaPro v1.4 requires NGUI 2.x. Many of you have been requesting the NGUI patch I have which adds support for NGUI 3.x. Now that NGUI 3.x is more stable I've decided to formalize my plans for the next version.

Going forwards RetinaPro v1.5 will require NGUI 3.0.6 or later. The reason I'm doing this is that it makes sense for me to consolidate my effort into one version of the package due to cost / time.

Additionally there are some benefits...

Previously RetinaPro would, for a given device, add each texture one-by-one to the atlas - this could be slow with large textures. A recent change in NGUI 3.0.6 means that I can now refresh an atlas with all of its textures in one pass. This substantially improves the refresh time when handling multiple devices.

After reading the whole thread I'm planning to by the plug-in but I have some questions for you:

1. Version 1.5 will include support for the UITextures? I have backgrounds for different devices/resolutions and I don't want to waste space putting then in
atlases in order to use them with ReitnaPro

2. When I could buy the new version (1.5)?

Thanks!!

Click to expand...

Hi,

1. UITextures are not supported. I doubt they ever will be because they don't offer the functionality needed for swapping at runtime like UIAtlasRef does. The recommended workflow is simply to create separate atlases for large background textures.

2. Version 1.5 is in testing right now. It may be a few days before I submit it. The main reason for the delay is that I'm waiting for NGUI to stabilize a little.

Hi,
1. UITextures are not supported. I doubt they ever will be because they don't offer the functionality needed for swapping at runtime like UIAtlasRef does. The recommended workflow is simply to create separate atlases for large background textures.

Click to expand...

Hi Ian,

I like your point but How can I add a NPOT texture to a UIAtlas? I mean backgrounds are usually like the screen dimensions of the device in this case
mobile ( 960x640, 1024x768 ) so right now when I add a NPOT texture to the atlas maker the generated atlas is a Power of 2 texture and that drives to
a waste of space in the resulting atlas. Do you have any advice about it?

I like your point but How can I add a NPOT texture to a UIAtlas? I mean backgrounds are usually like the screen dimensions of the device in this case
mobile ( 960x640, 1024x768 ) so right now when I add a NPOT texture to the atlas maker the generated atlas is a Power of 2 texture and that drives to
a waste of space in the resulting atlas. Do you have any advice about it?

Thanks,

Óscar

Click to expand...

Something to keep in mind that only the currently used atlas reference is in memory. If you only have a few of these loaded at runtime then I wouldn't be concerned about this space - especially on more modern devices. Everything else is in the bundle that is compressed - so any white space in an image is compressed really well.

I want to setup a Unity project with support for iOS and Android devices. So in the GUI part we are going to have 4 different resolutions:
by the way the game is landscape.

- 960x640
- 1136x640
- 1024x768
- 2048x1536

So we are going to create 3 atlases ( 960 and 1136 use the same atlas ). So I think Retina Pro is a good tool in order to create the devices
and atlases. The only thing that is not solved yet is the background images. With this configuration we have 4 images with the dimensions of
the 4 different resolutions. So if for example I put the 960x640 in an atlas that atlas will have a dimensions of 1024x1024 and I don't want that.
What I want is to create an atlas with a NPOT texture in order to avoid load that texture into memory!

To be honest I have got to create a NPOT Atlas using TexturePacker but I don't know if you know a better way of do it.

I want to setup a Unity project with support for iOS and Android devices. So in the GUI part we are going to have 4 different resolutions:
by the way the game is landscape.

- 960x640
- 1136x640
- 1024x768
- 2048x1536

So we are going to create 3 atlases ( 960 and 1136 use the same atlas ). So I think Retina Pro is a good tool in order to create the devices
and atlases. The only thing that is not solved yet is the background images. With this configuration we have 4 images with the dimensions of
the 4 different resolutions. So if for example I put the 960x640 in an atlas that atlas will have a dimensions of 1024x1024 and I don't want that.
What I want is to create an atlas with a NPOT texture in order to avoid load that texture into memory!

To be honest I have got to create a NPOT Atlas using TexturePacker but I don't know if you know a better way of do it.

Thanks!

Click to expand...

Given that you only have one background I would just use an atlas. Yes it wastes space, but it's not that much compared to available runtime RAM.

Hi,
I want to buy Retina Pro, but i am using an old version of NGUI 2.6.2, i cant change now, i a about to finish my project so updating it to 3+ will be a pain and will increase my release time.... may i buy it and have access to an old release of retina pro wich will work with my ngui?
Thanks!
David

Hi,
I want to buy Retina Pro, but i am using an old version of NGUI 2.6.2, i cant change now, i a about to finish my project so updating it to 3+ will be a pain and will increase my release time.... may i buy it and have access to an old release of retina pro wich will work with my ngui?
Thanks!
David

Click to expand...

If you purchase the current version I can send you an older version of RetinaPro. Please contact me via the support email address. You can find that in the readme.txt file that is included in the package. Send me a copy of your invoice as proof of purchase. Thanks.

Hi,
a few questions before i buy....
Sorry if they where asked/answered before....

The size of the project will be much bigger if i have an atlas for each resolution?
May i have the magic script which make the images in all the sizes? the one shown in he first video.
does it support not adding atlases but only change the offset in the anchor?

The size of the project will be much bigger if i have an atlas for each resolution?

Click to expand...

You'll typically have an atlas per resolution. However, you can share a single atlas for many screen resolutions that are similar in size. You can do this in the device settings. This is useful on Android platforms where you may have many devices that are very close in screen size. It's also useful for iPhone Retina / iPhone Tall screen sizes.

May i have the magic script which make the images in all the sizes? the one shown in he first video.

Click to expand...

Yes, I can supply you with those scripts via the email support address. The scripts simply processes "high rez PSD's" and for each PSD exports multiple different sizes (as you need per atlas size). However, it will need to be modified to suit your needs.

"does it support not adding atlases but only change the offset in the anchor? "
I think you answered whit this
"You'll typically have an atlas per resolution. However, you can share a single atlas for many screen resolutions that are similar in size. You can do this in the device settings. This is useful on Android platforms where you may have many devices that are very close in screen size. It's also useful for iPhone Retina / iPhone Tall screen sizes."

I asked if i can avoid adding more atlases but enjoy the offset correction for the anchor scripts of NGUI.
Thanks!!!

I have some problems when working with an scroll view that is anchored with "set to Current Position" and RetinaPro, so I wanted to see if anyone else have had similar problems and knows a good solution for it.
The scroll view is anchored with set to Current Position.
The problem is that when I change the resolution and a new atlas is loaded every widget is resized because of anchored. But the containing Grid has a hardcoded cell width and height so they will not change its value so all items in the grid will not look as they should.

I can think of some solutions but I wonder if there is not an easier way of doing it
Solutions that my work
1) Do some recalculation of children dimension when parent panel/widget is resized.
2) Add the "RetinaPro ignore UIRootScrip" and change the Pixel Size for each atlas.

Off topic, I did not want to post another message.
I think I found a minor bug in the code.
The atlasFolder string inside retinaProConfig is not used in stead the atlasFolder inside of retinaProDataRuntime is used and i guess this is just something you missed when refactoring the code.
This is not a problem for most people that don't need to change the path of the atlases. But to limit the amount of files that I need to merge when updating to a new version it would be nice if it get fixed or if the values is loaded from the data file.

I have some problems when working with an scroll view that is anchored with "set to Current Position" and RetinaPro, so I wanted to see if anyone else have had similar problems and knows a good solution for it.
The scroll view is anchored with set to Current Position.
The problem is that when I change the resolution and a new atlas is loaded every widget is resized because of anchored. But the containing Grid has a hardcoded cell width and height so they will not change its value so all items in the grid will not look as they should.

I can think of some solutions but I wonder if there is not an easier way of doing it
Solutions that my work
1) Do some recalculation of children dimension when parent panel/widget is resized.
2) Add the "RetinaPro ignore UIRootScrip" and change the Pixel Size for each atlas.

Off topic, I did not want to post another message.
I think I found a minor bug in the code.
The atlasFolder string inside retinaProConfig is not used in stead the atlasFolder inside of retinaProDataRuntime is used and i guess this is just something you missed when refactoring the code.
This is not a problem for most people that don't need to change the path of the atlases. But to limit the amount of files that I need to merge when updating to a new version it would be nice if it get fixed or if the values is loaded from the data file.

Thanks in advance.

Click to expand...

Can you send me an example project with scroll view? I'm not sure I understand the problem and that would help.

Regarding the atlas folder constant - yeah, it's because one is used for the editor and the other is used at runtime. I can refactor that and create a shared constant file that both can use. I'll try and get that done on the next version for you.

I just have one more questions and a feature request
With the current version of NGUI and RetinaPro its possible to use sliced images right? Because when i test it it looks okay but i read that older version of this plugin was not able to handle sliced images so i don't know if i am missing something.

It would a nice to have feature to be able so have subfolder in the atlas folder to be able to keep track of images better. I will probably do this change my self locally so it's not that bug of a problem.
And the last request is that it would be good is a warning is shown when an atlas is generating bigger then 4k.

I just have one more questions and a feature request
With the current version of NGUI and RetinaPro its possible to use sliced images right? Because when i test it it looks okay but i read that older version of this plugin was not able to handle sliced images so i don't know if i am missing something.

It would a nice to have feature to be able so have subfolder in the atlas folder to be able to keep track of images better. I will probably do this change my self locally so it's not that bug of a problem.
And the last request is that it would be good is a warning is shown when an atlas is generating bigger then 4k.

Click to expand...

The original problem with sliced sprites and RetinaPro was that refreshing the atlas would remove the slice sprite margins from the sprite. This was fixed.

Thanks for the feedback on the 4K atlases. I'll add your request to my list and see what I can do for the next version.

The subfolders problem is if you have a subfolder called Buttons with images in the atlas folder the images will not be exported to the atlas only images directly under the atlas folder will be exported.
The reason for this is that GetFiles in getValidArtFiles don't use the "SearchOption.AllDirectories" and if you add this then the load and CompareTo functions needs to be updated also.
But I found out that adding subfolder support will also have some limitation, like an image cant have the same name as another even if its in another folder and that is because of how NGUI handles sprite selection.

The subfolders problem is if you have a subfolder called Buttons with images in the atlas folder the images will not be exported to the atlas only images directly under the atlas folder will be exported.
The reason for this is that GetFiles in getValidArtFiles don't use the "SearchOption.AllDirectories" and if you add this then the load and CompareTo functions needs to be updated also.
But I found out that adding subfolder support will also have some limitation, like an image cant have the same name as another even if its in another folder and that is because of how NGUI handles sprite selection.

So far it is very good, except for a few minor (and one major) issue.
1 - It does not work at all with dynamic fonts (a newish but not that new, feature in NGUI). Now when I say it doesn't work, I don't mean that it does not have support (which it doesn't), I mean that simply HAVING a dynamic font in your hierarchy causes runtime errors that prevent the addon from working.

Note: This can be fixed by going to the line that causes the error, and adding a 'label.bitmapFont != null' check before accessing label.bitmapFont.gameObject property.

2 - It breaks the convention in unity, that whatever takes place during Play mode is reset once Play mode is disabled. If you have your screen dimensions in the editor 'game' panel set to iPad, hitting Play does what it has to do (resizing stuff, changing what each reference atlas points to, for example ipad / iphone / iphone@2x ). However, once you're done - the settings stay the same, and this can be an issue when tryign to layout your UI

Finally, and this is a minor gripe - When using the tool it logs out (Using Device X, pixelSize = Y), I wish this information were accessible externally as static variables.

With all that being said, make no mistake - you should still purchase this addon. It is extremely useful, and the author is very responsive

So far it is very good, except for a few minor (and one major) issue.
1 - It does not work at all with dynamic fonts (a newish but not that new, feature in NGUI). Now when I say it doesn't work, I don't mean that it does not have support (which it doesn't), I mean that simply HAVING a dynamic font in your hierarchy causes runtime errors that prevent the addon from working.

Note: This can be fixed by going to the line that causes the error, and adding a 'label.bitmapFont != null' check before accessing label.bitmapFont.gameObject property.

2 - It breaks the convention in unity, that whatever takes place during Play mode is reset once Play mode is disabled. If you have your screen dimensions in the editor 'game' panel set to iPad, hitting Play does what it has to do (resizing stuff, changing what each reference atlas points to, for example ipad / iphone / iphone@2x ). However, once you're done - the settings stay the same, and this can be an issue when tryign to layout your UI

Finally, and this is a minor gripe - When using the tool it logs out (Using Device X, pixelSize = Y), I wish this information were accessible externally as static variables.

With all that being said, make no mistake - you should still purchase this addon. It is extremely useful, and the author is very responsive

Click to expand...

Thanks for the feedback.

Version 1.6 will be coming soon and addresses some of your concerns.

1. Basic dynamic font support. What I mean is that you can now use dynamic fonts and have them change size based on device type. However, the data setup requires some manual setup of prefabs etc. The example scene will show how to do this. In a future version I'll actually have a GUI that allows for easy setup / creation.

2. RetinaPro does modify the atlas references at runtime. However, there are many times Unity's convention is broken (e.g. Materials). Unity isn't consistent with respect to this. In other words, I don't have any control what Unity decides to preserve vs. overwrite.

3. With v1.6 you can now access the RetinaPro runtime data. Example script shows how to do this.

4. I've tested RetinaPro with NGUI 3.5.3. I also fixed the UIFont.pixelSize problem. However, the workaround does require the use of a new script that you need to drop on your game objects with UILabel's.

First off great asset! Using it in my projects now and its making the UI much better, and saving me a lot of time.

I do have a question/feature suggestion though.
I would like to use Retina Pro for just two screen sizes, iPad and iPad Retina. This is sufficient for most of my sprite needs, and they look fine on all devices. Now, for backgrounds, I need one for various devices I support. For example, I would need a background for iPhone, iPhone 5, iPad and iPad Retina. Currently, if I have all of these devices in the "Device" list, then it will expect to find an atlas for all of the devices, and not show anything if it does not find one! Would it be possible to have solution in place for textures. You would assign a scripts, and give it the texture name, and it would then pick the texture from the "Textures" folder based on the current screen size. Is this possible? If so, it would pretty much be my ultimate solution.

First off great asset! Using it in my projects now and its making the UI much better, and saving me a lot of time.

I do have a question/feature suggestion though.
I would like to use Retina Pro for just two screen sizes, iPad and iPad Retina. This is sufficient for most of my sprite needs, and they look fine on all devices. Now, for backgrounds, I need one for various devices I support. For example, I would need a background for iPhone, iPhone 5, iPad and iPad Retina. Currently, if I have all of these devices in the "Device" list, then it will expect to find an atlas for all of the devices, and not show anything if it does not find one! Would it be possible to have solution in place for textures. You would assign a scripts, and give it the texture name, and it would then pick the texture from the "Textures" folder based on the current screen size. Is this possible? If so, it would pretty much be my ultimate solution.

Adam

Click to expand...

Thank you!

For your specific case I recommend that you add your own script for handling single textures as currently I don't have a UITexture solution. I will however, keep this in mind as you are not the first person to ask for it.

Alternatively (and what I recommend) is that you handle the background in it's own atlas and add all the device types you need. I recommend keeping the iPhone / iPhone retina devices present. It may seem wasteful, but keep in mind that it's only the bundle size that grows - it doesn't waste any runtime space.

If you've updated to the latest NGUI 3.5.2 or later you'll probably have noticed the following error:

Code (csharp):

Type `UIFont' does not contain a definition for `pixelSize' and no extension method `pixelSize' of type `UIFont' could be found (are you missing a using directive or an assembly reference?)

This is fixed in an internal version I have here that is not yet released to the Unity Asset Store. Please contact me via the email support address with proof of purchase and I'll gladly send you the current build.

For your specific case I recommend that you add your own script for handling single textures as currently I don't have a UITexture solution. I will however, keep this in mind as you are not the first person to ask for it.

Alternatively (and what I recommend) is that you handle the background in it's own atlas and add all the device types you need. I recommend keeping the iPhone / iPhone retina devices present. It may seem wasteful, but keep in mind that it's only the bundle size that grows - it doesn't waste any runtime space.

Click to expand...

Thanks for the reply.

I am currently using the solution you recommended, however because I only need two devices for the app UI elements, but I need 4 devices for the backgrounds, it means when i run RetinaPro cannot find 2 of the 4 atlases (as they are not created) for the app UI elements and displays nothing! The only way I have got around this is to create atlases for all of the devices for the app UI and add in textures from the device it would be using. Hope this makes sense, basically I will have 4 atlases for my app UI, 3 of which will contain the same size textures to get around the issue.

I am currently using the solution you recommended, however because I only need two devices for the app UI elements, but I need 4 devices for the backgrounds, it means when i run RetinaPro cannot find 2 of the 4 atlases (as they are not created) for the app UI elements and displays nothing! The only way I have got around this is to create atlases for all of the devices for the app UI and add in textures from the device it would be using. Hope this makes sense, basically I will have 4 atlases for my app UI, 3 of which will contain the same size textures to get around the issue.

Oops...

"Unity", Unity logos, and other Unity trademarks are trademarks or registered trademarks of Unity Technologies or its affiliates in the U.S. and elsewhere (more info here). Other names or brands are trademarks of their respective owners.