2D Toolkit Forum
2D Toolkit => Support => Topic started by: ramones on April 25, 2012, 12:50:53 pm
-
Hi,
I have finished a prototype of my game for iphone 3gs (480x320). I want know to make it work on other iphone devices and android.
Could anyone suggest best practices to accomplish this? I'm really lost here. Don't know if I need to have a different atlas for every resolution. How do you accomplish relative positioning to let things appear at right positions depending on the current resolution?. Has 2dtoolkit any support to make this easier?
Any help will be really apreciated.
Thanks in advance.
-
There are two separate issues with this, both of which need to be addressed separately.
Coping with varying pixel density and coping with different aspect ratios.
I don't know what your game is about, so I'm going to assume that you can safely zoom out of the viewport to keep the game pixel perfect and that there is valid data outside the current 480x320 viewport.
So for varying aspect ratios, what you need to do is correct the orthoSize on your main 2d orthographic camera appropriately on startup.
NewResolutionHeight / OldResolutionHeight * currentOrthoSize.
That will rescale your camera so the sprites are pixel perfect in your new resolution - you can easily make a HD iPhone game work on an iPad.
The next thing is UI elements when you change aspect ratio, obviously you'd want to keep the widgets hugging respective parts of the screen. If you can switch the UI stuff to use tk2dCamera, then you'll be able to take advantage of the anchor system in there and everything should just work.
With DPI, the easiest way to do it currently, is to simply create a highdpi atlas with mipmaps, and use QualitySettings to make it drop one mipmap for LowDPI situations. We will be looking into on a seamless solution for this (the ideal case is to be able to replace atlases at runtime) after 1.70 final is released.
unikron
-
Hi!,
Thanks a lot for the insights.
My game is a puzzle game, so right now there's no valid data outside the 320x480 window. THe only option here would be to use a bigger texture? Or better, should I use a texture for a set of pixel ratios ( pixel ratios that more or less are the same) to avoid too much blurring?.
One more question. From my current tests trying to make up my mind, I have noticed it is a must to have an image for each different ratio or at least have an image big enough to fit in a set of resolutions. As an example 320x480 and 800x480 the first one is 1.5 and the second one 1.666... I could have a 800x480 one to use in both or have one for the 1.5 ratios and other for the 800x480 ratios. Am I right?.
What texture sizes do you prefer to minimize number of textures and cover as much pixel ratios as possible keeping a good quality?.
SOrry for this nob questions but this seems a pretty difficult topic.
Thanks in advance.
-
Hi,
Would it be possible to send a screenshot of what you're aiming for to support at unikronsoftware dot com? You can blur out / delete any confidential information, I just need to know what kind of data we're dealing with here.
It would be hard to make recommendations otherwise.
-
At this moment I can't send anything because NDA sorry.
Anyway would you be so kind to explain the following behavior. I have been playing with different texture sizes, etc... and playing a bit with the ortho size.
I have a texture background that is 320x480 and my resolution in unity is set to 480x800. When I push the 1:1 button for the script (make pixel perfect) the sprite covers all the height of the camera. WHy is this? If my texture height is 320 shouldn't it leave a top and bottom gap when displayed in the 480x800 resolution?.
Thanks in advance.
-
Sure -
The way 2D Toolkit is designed is that you say what resolution you're gonna display the sprites at and what the ortho size is. The real resolution you display at doesn't matter, and it scales automatically to fill the viewport, maintaining aspect ratio (so if you expand resolution horizontally, you get bars rather than the image being stretched). This means that you can trivially 2x or 0.5x your screen, and everything just works.
The 1:1 button basically scales based on the sprite collection settings vs camera size, so if you 1:1 on a 960x640 vs 480x320, you should get the sprites being the same relative scale - again for the reason mentioned above.
For this approach to work with arbitrary resolutions, you can use the orthoSize method mentioned earlier, and that makes everything pixel perfect without touching or modifying each and every sprite. And with rich and potentially very complex sprites in 2D toolkit (sprites aren't limited to just rectangles), this can be a massive saving.
We also have the tk2dCamera class, which does things rather differently. Here, what you get is a self adjusting camera which will automatically adjust itself so sprites are ALWAYS pixel perfect. You also get the added bonus that 1 world unit = 1 pixel in whatever resolution you're using, and the coordinate system starts from the bottom left. the tk2dCamera also has support for anchors. Check out demo 11 - camera and alignment for more info. Seeing that your game is a puzzle game (and I'm guessing no scrolling), this might be a better solution for you.
There are 2 "bugs" with tk2dCamera currently. Firstly, the box drawn in the scene view representing the camera is incorrect (tk2dCamera uses a custom projection matrix, and the Unity scene view thing uses parameters rather than reverse projection). Secondly, the "Camera Preview" button doesn't display the correct data either - again for the same reason above. So if you intend on using the tk2dCamera, always look at the Game window.
Hope that helps.
-
Hi!,
Ok I understand now unicorn. Lota thanks.
But then the 1:1 button is not a "Pixel perfect" button am I right? I mean, it will be just pixel perfect when you display the sprite in the resolution you originally had. For other resolutions it will stretch it keeping aspect ratio with may produce blury images if too much streching is done. Am I correct?
THanks in advance.
-
Yup, thats one way to think of it.
-
Hi again,
This question is a bit off topic from the thread main subject but I want to keep the forum clean so, don't wanna create another thread for this one.
I have been reading a lot this 2 days about how iPhone handles internally points/pixels to seamlessly allow us to dot not have to change positions, etc... when running a game made for low res to retina.
The only thing that is not yet clear to me is how change my atlas depending on the platform. I assume that changing the texture to a higher resolution, iPhone will use it and show correctly without touching anything inside unity (ortho size, etc...), Am I right?.
I'm sorry to come again with this kind of questions but I'm almost making everything clear.
By the way, what does sprite dicing really means? :/.
Thanks in a dvance.
-
OK, the only way to change atlas depending on platform for now, is to use Resources.Load to load the correct sprite collection data in. Its not the most ideal way to do it, so the following may be more suited to you, well its easier anyway.
By default all textures have mipmaps, and if you generate your atlases at iPhone4 res, then you can drop one mipmap to half the texture size on iPhone3GS. You can do this using QualitySettings. Set it up in the interface to half texture quality in one of the settings, and when your game starts up use the QualitySettings API to switch collection when you detect that particular hardware.
Sprite dicing = a way to seamlessly chop up sprites, and reconstruct them to save texture space & fillrate.
-
Thanks a lot unicorn for your support.
Just one more question. How is it that you can save filtrate with dicing? I understand the texture save, but the filtrate won't be the same that the original sprite. On the other hand I suppose the bad thing is that the sprite should be renderers using more triangles to render all the "chops".
Thanks in advance.
-
With dicing each dice is trimmed - so you will gain significant fillrate improvements if there is empty space in your atlas. Obviously no gain to be had if your sprite is solid. The additional triangles dont end up costing anything any noticeable amount - it doesn't add that many triangles to make a difference.
-
We also have the tk2dCamera class, which does things rather differently. Here, what you get is a self adjusting camera which will automatically adjust itself so sprites are ALWAYS pixel perfect. You also get the added bonus that 1 world unit = 1 pixel in whatever resolution you're using, and the coordinate system starts from the bottom left. the tk2dCamera also has support for anchors. Check out demo 11 - camera and alignment for more info. Seeing that your game is a puzzle game (and I'm guessing no scrolling), this might be a better solution for you.
I think what I might be missing here is the sprite scaling with the tk2dCamera class. What I see when going from 960x640 to 480x320 is a correctly positioned sprite but it has not scaled to the appropriate value. eg. if I have a sprite on a retina screen and my sprite scale is (1, 1, x) with a pos of (100, 100, x) then I expect when going to a low res screen (3GS) a sprite scale of (0.5, 0.5) w/ pos (50, 50, x/2). This is not what I'm seeing though.
Also, the solution of setting the camera ortho size of the camera (essentially scaling everything on the screen) based on the device mentioned earlier in the thread isn't always the best solution for us when handling multiple resolutions. A better solution would be a case by case sprite 'Autoresize' (as found in xcode's nib builder) that would allow sprites to be anchored and scaled based off of their parent container and to adjust how they're scaled an anchored on an individual basis.
Anyhow, maybe this is already done by some other manner and I'm just missing it as I'm a new user.
-
Thats what the resolution overrides are for. Add an override for 480x320 and have a scale of 0.5 and it should just do what you expect.
-
Thats what the resolution overrides are for. Add an override for 480x320 and have a scale of 0.5 and it should just do what you expect.
Of course but it does it for the entire scene (eg. I may want to scale sprites individually depending on screen resolution and some sprites I may only want to scale on the Y or X axis. Some sprites I may not want scaled at all).
Furthermore it's impossible to tell what sort of screen resolutions there will be tomorrow, especially in the realm of Android. I assume I'd have to create several over rides or set them through code during run time.
-
Thats an interesting thought. Is there any particular reason you'd only want to scale non-uniformly? I was thinking of a "snapshot" based system for positioning screen overlays / UI elements / etc, where you position them and then set them up for different aspect ratios, etc. Obviously won't catch every permutation, but should give a decent starting point.
All of this is really dependent on what you want to do though, and also what should be part of the toolkit and what should be specific to a game. I need to think a lot more about this.
-
Hard to say whether it would be just for a specific game. Our studio frequently uses the Autosize options in Xcode's xib editor when porting from iPhone->iPad with great results. I've already begun setting this up in the provided source package (tk2dBaseSprite & tk2dSpriteEditor) and it seems like a no brainer at the moment. It should definitely allow devs/designers to fine tune their 2D layouts without simply mass scaling.
-
I have always found the autosize option to be a bit limiting and end up creating two layouts when dealing with iPhone - iPad, but at least I understand what your comment about scaling is about. I'll look into this. If you're adding this, I suggest doing it outside the sprite behaviour altogether, by using the .scale parameter - it will keep it much more portable and reliable, and will avoid a lot of branches in the code.
-
Hi,
this thread is already a bit older, and by now there are probably already new features included, and I am still thinking about how to generally address the problem of "arbitray" landscape screens (Android et al). Maybe the solution is already built in?
So I have tons of graphic assets initially made for iPad Retina. I have also 2048x1536 kind of abstract background images that can well be scaled and distorted to fit all the (current) common landscape formats (and I don't want to cut off anything, it should all be shown). Of course the other assets should never be distorted at all, only proportionally scaled.
So could I setup one camera that just handles the background and fills that background picture onto the whole screen, not leaving any borders? And then have a second camera that handles all the other sprites that I need on-screen? Or how would I start here?
Regards, habitoti
-
If you want to do different things to different sprites, you'll obviously have to deal with them separately. I'd start of sorting out all the proportionaltely scaled ones with the tk2dCamera overrides. If you want the rest of the sprite/s to fill the screen, either do that with a second camera, or manually scale it to fit tk2dCamera.ScreenExtents.
Example here:
http://unikronsoftware.com/2dtoolkit/forum/index.php/topic,2590.msg12929.html#msg12929