I’m doing a platform game and I want it for mobile. So, optimization is a important point and I was thinking about to reduce my images (they are already small). I started my tests and… my god… it’s to much work to do with origin points when my objects flip! Then came me the question: all that work is really necessary? It would make some real difference? Or is more easy to stay with only one size large enough to all imagens of all animations?
I compared the size of my images before and later the change. The diference is near to 150 bytes…
You’re going to have to give context here, you should never be modifying origin points in 99.9% of cases, and you ESPECIALLY shouldn’t be modifying origin points when you flip objects, since the engine already does that.
Thousands of images that are only 465 bytes bytes are not going to make any difference from thousands of images at 606 bytes.
Your game will not run on a phone with a potato (i.e. super slow) processor, for numerous reasons:
The Google Play store does not accept APK packages anymore, only AAB. AAB packages are only supported on the last generation of Android 8 devices and newer, and barely. No potato processors really existed with support for Android 8 or newer anyway, and you really shouldn’t be building your game with Android 8 devices in mind as they make up only about 10% of all Android devices on the market, almost all of the rest are Android 9 or newer. Android OS version market share over time
iOS devices have much worse issues to worry about than memory limitations (what you’d run into from image issues). For web apps Safari has a terribly optimized rendering engine, for electron apps WebGL rendering is comparatively pretty poor on iOS as well. You might run into performance issues on iOS, but there is very little you can do about it as it’s going to likely be logic related (i.e. you’d have to refactor how you’re doing events, and even that may not solve it)
As mentioned above, art assets are very likely only going to impact 2 things: RAM and download size. Your assets being less than 1kb each already means that making them even LESS than 1kb is not likely to be impactful. Processing the assets is very unlikely to impact any CPU/GPU performance.
Little precision: file size as in storage space won’t impact CPU/GPU performance, but the image size as in resolution will as it makes more pixels to process and render.
Let-me make a example with what I think happens. An object with two animations with different X sizes. The origin point stay in the original place and both animations like this:
When I change the animation with object no flipped all works fine. If I change the animation with object flipped it “jumps”. I think when we flip an object something like in this edited image in paint happens:
My guess is the origin point stay in the same place and that’s why object “jumps” changing animations. If the original point had been flipped it should look like in this another edited image? And if yes, why it’s “jumps”?
You should never, under any circumstances that I know of, have animations of different sizes on the same object.
On a single object, every frame of every animation should be the same size. This may mean you have to have larger empty space around smaller animation frames.
This isn’t just due to points, but also to collision masks and physics attributes, which depend on the animation size.
Not having them all the same asset dimensions means you will have to update the points AND collision boxes for each animation, and that still won’t work if individual frames of an animation are different sizes.
