Shall I scale actor size or image size?
PandaParents
Member Posts: 64
Hi, I am trying to understand how to scale the size of images for ipad or iphone game. Based on the cookbook, "iOS will automatically scale your videos to the nearest of a set of pixel ratios, As a result, if you have an image that is 130x20 pixels, you may wish to scale the one side down by 2 pixels, or it could take as much as 256x256." My question is which is more important, the actor size or the image size? I read somewhere in the forum, it seems to me that all I need to do is to scale the actor size. Does that mean I don't have to worry about the size of the images when I upload them into the game salad? some of my images are really big and can I upload them into GS and then change the actor size?
Thank you
Thank you
Comments
Well, actually, yes you can, but it wouldn't be a wise move.
(Not forgetting that if the target device is Retina then you want to double these sizes) That's just how it works, it's the same deal for an system where you import images from one piece of software to be laid out in another (certainly all systems where the final piece will end up on a screen). Typically I'd produce the image at the largest size used in GameSalad, then all the resized versions will be smaller so won't suffer from a lack of resolution.
Although if you have one massive 1024 x 1024 pixel flying rock actor and 100 smaller 32 x 32 pixel flying rock actors you are best making up two different sizes - otherwise each of those 32 x 32 pixel flying rock actors will contain a 1024 x 1024 pixel image . . . which will be a more strain on the target device compared to a bunch of 32 x 32 pixel flying rock actors which use a 32 x 32 pixel image. I haven't got a clue, literally. Compressing a PNG (usually through bit depth reduction) only effects the size of the image file when it is stored (on a hard drive or equivalent), once you load your compressed PNG into RAM on (for example) an iPhone the image will expand back out to its original size (or near enough), but any quality lost through the compression process will not be returned.
So, PNG file size reduction won't make your game load any faster or run any smoother, it will just make the app size, when on disk, smaller.
By the way . . . . the quote you posted from the cookbook . . . .
"iOS will automatically scale your videos to the nearest of a set of pixel ratios, As a result, if you have an image that is 130x20 pixels, you may wish to scale the one side down by 2 pixels, or it could take as much as 256x256."
. . . . is pretty much all nonsense, obviously GameSalad doesn't allow you to import 'videos', it should read 'images', and when you do import images GameSalad doesn't scale them to anything, they are left exactly how you made them, so if you made an image at 130 x 20 pixels and imported it into GameSalad it wouldn't be 'scaled' down or up or anything, it would stay exactly as it is, 130 x 20 pixels. Also the term 'nearest set of pixel ratios' is pretty much meaningless.
What they are trying to say is that images take up the smallest ^2 sized chunk of memory they can fit into, ^2 values look like this . . .
4
8
16
32
64
128
256
512
. . . etc.
So an image that is 128 pixels wide will fit into a 128 pixel chunk of memory, but an actor that is 129 pixels wide won't, so it will need a 256 pixel chunk of memory - so it's worth trimming off that one pixel (or scaling down the image) to save a whole load of memory.
Also the advice to scale down 'one side' is bad advice as you will introduce a little aspect ratio distortion . . . etc etc, basically that whole section is misleading and badly written.
Yes, it's a good idea to make your pixel count (both X and Y) an even number.
GameSalad measures an actor . . . (the presumption here is that the actor is the same size as the image) . . . from its centre, so placing a 100 pixel wide actor on x=50 will mean there are 50 pixels either side . . . . but if your actor is 99 pixels wide, the centre of the actor will still sit on x=50, but there will be 49.5 pixels either side, with each of those pixels sitting not on whole number pixel values but in between (so 31.5 - 32.5 - 33.5 . . . etc, instead of 31 - 32 - 33 . . . ) and the only way to get a pixel to sit on a half way point between actual on screen pixels (physical monitor / device pixels) is to place half the colour value on each adjacent pixel - a process know as aliasing . . . .
And this aliasing makes your images not quite as sharp as they could be.
Does this matter ? Well if you have a picture of some clouds then you are unlikely to be able to see this very very slight aliasing (or blurring), and now that everything is Retina based it's going to be even more imperceivable with something like a picture of clouds, and probably pretty much any photographic image, but if you are dealing with very graphic content (fonts, hard lines, contrast) then you might notice it more, even here the issue is not very noticeable on Retina screens (but you certainly could see it quite clearly on older non-Retine devices).
So, if you want to best quality, try and make your image sizes even (and if it's for a Retina device then make them divisible by 4), generally speaking this is a good rule - but like I say it's not going to effect how the game works, only how it looks, making the files odd sized won't break anything . . . . so there's nothing to stop you - for example - deciding that an image looks a little too sharp, so you deliberately trim off a single pixel from one dimension (or both) to force the device to subtly anti-alias it. That's up to you, you can do whatever best suits your needs. In this kind of situation I would simply enlarge the 'canvas' of the image, so the canvas size is now 128 pixels and the image is unaffected. But you could also crop off a pixel (which again would leave the image unaffected), or stretch the whole image (not just one side), or a million other ways . . . whatever works for you. I've not mentioned "zip" anywhere in my posts. That's up to you ! Use it if you want, it makes your file sizes smaller with not much in the way of quality loss, so it might be useful if you are trying to keep your application / game size below a certain size (for instance to make it downloadable over a phone network). Not really, but that's not to say it might not be useful if size is a concern. "zipping" an image file would make it unreadable !
. . . . . . . . . . . .
For example, if you make up an image at 256 x 256 pixels (@ 72ppi) and import into GameSalad, then drag the image into the Actors window, GameSalad will automatically make you a 128 x 128 pixel actor with your image in it. Here is a basic guide:
Aliens: 5,000 x 5,000 pixels.
Buttons: 12 x 12 pixels.
Picture of Cheese: 640 x 640 pixels.
Small picture of Cheese: 1 x 1 pixel.
Massive shoe: 220 x 220 pixels.
iPhone 5: 1136 x 640.
iPad: 2048 x 1536.