Optimizing Images
So I honestly just found out that making your images divisible by 2 will help a large deal when optimizing. But the problem is that...it's a bit late for me, and the game I'm working on has a large amount of images already, does anyone know of something I can do to change all of the images into an even size in a quicker way? Thank you!
Having trouble with your game? Sounds like a personal problem.
Comments
Is your game having problems with crashing/being slow?
Not crashing, but when testing on my phone, it does lag a bit
Having trouble with your game? Sounds like a personal problem.
Well, primarily make sure that the images aren't too large. If any texture is more than double the size of its actor, you are wasting memory while gaining nothing in terms of visuals.
About the divisibility by 2, it shouldn't really bog down your game.
Are you sure? I was watching one of @Tshirtbooth's videos, and he says it's quite important.
Having trouble with your game? Sounds like a personal problem.
@ADSentertainment -- Was he really saying divisible by 2? Or that it should be a power of 2?
As in 2, 4, 8, 16, 32, 64, 128, 256, 512...
Those are two very different things.
Power of two can have an impact, with bigger textures especially. It has to do with how GS works with images at runtime.
Having an image size 130x130 is wasting memory because since it's over 128, it actually takes up the same memory as a 256x256 image.
That being said, once GS introduces (supposedly soon!) their new way of working with images -- internally creating a sprite sheet for all your images, essentially merging them, this problem should disappear.
Can you give examples of some of your image sizes?
He was talking about even numbers. They have to be divisible by four actually, but he does talk about powers of two later on, here's the video:
Having trouble with your game? Sounds like a personal problem.
@ADSentertainment --
Well, as he says: if you have art not divisible by two, it might make it look a little blurry (especially if it has sharp edges). If that is a problem you are having, then yes, the only solution is to have art divisible by two. But this is not going to affect the performance of your app.
Power of two might affect it (depending on the actual sizes), but as I said, it will soon become pretty much a non-issue with sprite sheets.
First and foremost make sure that the images you are using are not unnecessarily large, that's usually where people waste the most memory.
Making an image divisible by 2 will have no impact on optimisation (by optimisation I presume you mean memory usage / processor load / file size and so on).
+1
@Socks @pHghost Oh alright, I thought he meant it would increase memory usage along with that. And I'm now fixing the problem with the unnecessarily large images now
Having trouble with your game? Sounds like a personal problem.
Yep, agreed, I think this point has been a little overplayed on the forums, to the point were you see the occasional post that suggests if your images are not divisible by 2/4 then the economies of the world will collapse, ebola will spread to all corners of the earth and the zombie apocalypse will be upon us.
The advice to make image dimensions even (or divisible by 4 for Retina images) is sound advice, but often makes little difference with things like photographs or texts or even illustrations, even the slight bluring effect it has on more obvioulsy graphic images (which is where the advice makes most sense) has been mitigated a fair bit with the move to Retina.
That's not to say you shouldn't follow the advice, just that it really isn't a big a deal as it can often be made out the be.
omg did I hear the zombie apocalypse is upon us - better go and get my shotgun.. no wait, I'm not in the states... I'm so f-ed!
Here's the deal with image pixel count divisibility . . . . .
An image's coordinates in GS are measured from the very centre of the image (or actor).
An 8 x 8 pixel image's centre is the upper righthand side corner of the fourth pixel across and up.
If this image were to be 7 x 7 then the centre point would be the centre of the fourth pixel across and up. This would mean that the pixels in the image would be offset by half a pixel from the actual screen pixels - pixels don't exist in between actual pixels and the best any system can do is to take the values of the image pixels around an actual pixel and average them to get a value for the actual pixel. The result is smearing / blurring / anti-aliasing (or whatever you want to call it).
Hope that makes sense !
Great! Let us know if that helps!
So true.
I think it all comes down to being sensible (and possibly manually doing the calculation how much memory you are wasting, if in doubt). If you have a couple actors that have badly optimized textures, and the textures aren't on the huge side of things, you are OK. Look at games like Super Heavy Sword -- I can decently play it on my iPhone 4! And that game has a lot going on visually, lots of memory allocated.
That's not to say don't optimize at all. But if you have, say, eight actors of a normal size, with textures that correspond to 2x actor size, and your app is slow, most likely you need to optimize your logic rather than make sure that your images are a power of 2.
Yeah, I've noticed how it works that way, not necasarilly coordinate-wise, but how actors move, I notice that my actor can sometimes be either rather blurry, or sharp, and I'm assuming it's around the same deal
Having trouble with your game? Sounds like a personal problem.
Not 100% sure I know what you mean, but yes sub-pixel moves (like sub-pixel static positions will blur an image).
In the above example I mentioned how an 8 x 8 pixel image (placed at 4, 4) sits neatly on a whole pixel, and how a 7 x 7 pixel image (placed at 4, 4) doesn't sit on a whole pixel, and gets smeared . . . but you could also take an 8 x 8 pixel image and place it on x=3.5, y=3.5 and it will also be smeared, even though it is an even number of pixels for the reasons mentioned above.
Now imagine an image that moves from x=500 to x=501, a one pixel move, over 10 seconds, the image will spend most of it's time in sub-pixels positions, and therefore blur, this is true of any movement that where an image is moving slowly enough, although most of the time you won't notice it, and when you do it's normally seen as advantageous as it smoothes out the motion, similar to motion blur (but on a sub-pixel level).
So . . . the following will cause an image to be soft/blurred - and will do so for the very same reason:
Moving an actor (unless it is moving by whole pixel counts)
Placing an even pixel count image on a sub-pixel position (or non-whole number position)
Uing an odd pixel count image (like 133 x 133)
And likewise, if you placed the 7x7 pixel image at x3.5 y3.5 it would be sharp.
Yep, absolutely, which brings us back to our point about the idea that images must be divisible by 2 or 4 being sometimes overplayed, there are situations (as unlikely as they may be) where using an odd pixel count image will give you a sharper image (like the x=3.5, y=3.5 scenario).
Also GameSalad's entirely purposeless convention of placing actors on arbitrary sub-pixel values when dragged into a scene doesn't help newcombers navigate these issues, it just adds confusion ("hey guys, I made my actor 200 x 200, so it's even, but when I put it into the scene it's still blurry ! help !!" . . . etc) . . . whilst causing more experience users to have to manually type in the coordinates of every actor placed into the scene, forever, for as long as they continue to use GameSalad, or until they die (whichever comes first
) something I guess would be thousands of times or even tens of thousands of times for long term users, a pointless extra layer of scene admin !
Damn, I better stop, I can feel a rant coming on . . . .