Optimizing your artwork
DillonV
South FloridaMember Posts: 26
Hey everybody, I just watched another great tutorial by Tshirt Booth about optimizing artwork. However, i'm confused on one thing. In the tutorial, he explains a little bit about RAM and how sizing impacts that. Lets say you have an image that's bigger than 1024 x 1024. How will that affect your RAM? I'm still relatively new to all of this. This is the video I saw in case you didn't know which one I was talking about.
Thanks guys!
Thanks guys!
Comments
Regarding image sizes specifically, the larger (width and height) the image, the more RAM it will take up. A 1024x1024 image will consume more memory than 800x800.
Now, if your project's screen size is going to be 1024x1024 then you may need to have your image that size, regardless of memory use, because you want it to look perfect. You *could* cut corners to save memory, make the image 800x800 and then stretch it to fill your screen size, but that would be blurry and look terrible.
* EDITED, CORRECTED BELOW BY SOCKS *
I am unable to watch the exact video from where I am currently at, so I am posting this as general information on the subject. Hopefully I addressed your question.
Sorry to sound like an old pedant (which I am
My favourite 'force load' method at the moment is to drag all the images needed in a scene into an animate behaviour, then place the actor with the animate behaviour actor off screen somewhere - and destroy it after a second or so (depending on how many images it needs to load). I'm not sure that's true, there may well be a threshold beyond which additional memory usage impacts on performance - but I very much doubt that an app occupying, for example, 150MB of RAM is going to run slower than one occupying 100MB of RAM, but you are spot on about hitting the RAM buffers, using up too much available RAM will bring your app to its knees and, like you say, even crash it. A 1024 x 1024 image won't take up more RAM than an 800 x 800 image, they will both occupy the same (1024 x 1024) sized chunk of RAM.
Images use the smallest 2n size they can fit into, so as 800 x 800 is bigger than 512 x 512 it will occupy the next largest sized chunk of RAM, which is 1024 x 1024, so an 800 x 800 pixel image and a 1024 x 1024 image will both occupy a 1024 x 1024 pixel chunk of memory.
In fact there is an argument that says the 1024 x 1024 image will be more efficient - as the 800 x 800 image needs to pad itself out to 1024 x 1024 in real time on the device, something the 1024 x 1024 doesn't have to do. This is not the case.
A 1024 x 1024 pixel image at 72ppi is identical to a 1024 x 1024 pixel image at 200ppi, or 500ppi, or 15,000ppi, or 13,500,000ppi, or 15.95 billion ppi - they all use the same amount of RAM and have the same amount of pixels, they are identical, the only difference is that they have different metadata.
If you take a 1024 x 1024 pixel image at 72ppi and a 1024 x 1024 pixel image at 72,000,000ppi - import both to GameSalad, and place each one in its own 1024 x 1024 actor, they will be identical, the same size in pixels, the same size in memory usage on the storage device and the same size in RAM - they are identical.
Try it, save a 1024 x 1024 pixel image at 72ppi, then check how big the file size is, then change the ppi to 8,000ppi - and save again - check how big the file size is, it will be identical to the 72ppi version.
PPI is a descriptor, it's metadata, it only gives information about other data, it doesn't modify it.
This is why I'd always advise people to jettison the increasingly arcane ppi notion altogether and work in absolute pixel values, we generally know the resolution of the target device in absolute terms (i.e. device XXX is 1024 x 768) so there's no real need for any of us to get wrapped up in this 'how many pixels would fit into an inch' business, it doesn't even make sense anymore, my iMac is not 72ppi, GameSalad doesn't display images at 72ppi on my iMac, my iPhone, Android phone, iPad or Kindle aren't 72ppi either - in fact nothing is ! (unless you have a 10-15 year old CRT monitor).
Anyhow, sorry to sound like I'm taking you to task on this, and I know all you are doing is helping out a fellow GS user, but it's an interesting subject (to me at least!) so I can't help but stick my oar in.
me > :-@
So, I see what you are saying about the file size and metadata description... I am quite used to creating images by standard measurements (inches/feet etc) and DPI directly affects the overall "Pixel" size (eg 1024 x 1024)... But in reality, the end product in that fashion really is much larger in pixel size, not the same.
I had to re-read your post a few times and yes, if you force the image size to 1024 x 1024, regardless of the DPI, the outcome IS exactly the same.
I am still unsure about the physical size of the image affecting RAM usage though... In my 20+ years as a PC tech, RAM usage has had nothing to do with the physical size of an image. If it is a 1mb file, then you use 1mb of RAM... If it is a 22mb file, then it uses 22mb of RAM.
Please explain?
This holds true as long as a your app does not use up more than a certain amount of RAM and where that limit lies differs between devices based on e.g. how much RAM the device in question has..
Here are the (rough) max memory limits to expect before an out-of-memory crash will occur:
iPad1: 127MB/256MB (crash amount/total amount)
iPad2: 275MB/512MB
Newer Ipads: 645MB/1024MB
2) No, an image with dimensions 800x800 takes up the exact same amount of RAM as an image with dimensions 1024x1024 if they have the same bit depth.
The image dimensions most certainly matter, so does bit depth.
If the image would be full color with transparency (alpha channel) it would be represented as a 32-bit image in RAM.
Red (8-bit) + Green (8-bit) + Blue (8-bit) + Alpha (8-bit) = a 32-bit image.
That means that your 800x800 image would take up 4MB of RAM.
Actually, if memory serves me the image is represented twice in the form of 4MB in RAM and 4MB in VRAM and since both system RAM and Video RAM are shared on IPAD/Iphone that would mean 8 MB for a 800x800 or 1024x1024 image.
If the same image would not have an alpha channel (no transparency) it would be represented as an 24-bit image in RAM which would equal 1024x1024x3 = 3MB RAM (or 6 if the RAM+VRAM assumption is correct).
Now lets say that you would use a 32-bit image with dimensions 1025x1025 instead...
Since you passed the 1024x1024 dimensions the image would actually be represented as a 2048x2048 image in RAM, for a 32-bit image that would be 2048x2048x4= 16 MB RAM (32MB if represented in RAM+VRAM).
2048x2048 is the max dimensions for use on IOS retina devices.
'dpi' is a print term, when I used to do print work we'd make sure our ppi was double the dpi, so if you wanted something printed at 150 dpi (pretty standard magazine quality), you'd work at 300ppi in Photoshop (if you really want to get into it look up Nyquist frequency).
But like I say people use ppi and dpi to mean the same thing these days, so use whatever you are comfortable with as most people take them to mean the same thing.
No, I'm not saying that !
If you have a 22MB file and a 1MB file they will not occupy the same amount of RAM, the 22MB file will occupy 21MB more than the 1MB file. Agreed ! I will repeat what I said:
"A 1024 x 1024 pixel image at 72ppi is identical to a 1024 x 1024 pixel image at 200ppi, or 500ppi, or 15,000ppi, or 13,500,000ppi, or 15.95 billion ppi - they all use the same amount of RAM and have the same amount of pixels, they are identical, the only difference is that they have different metadata."
. . . . but obviously have differing physical sizes due to their shared absolute pixel values and differing ppi values.
So, sticking to 'physical' size - and using my first two examples above . . .
A 1024 x 1024 pixel image at 72ppi (14.2 inches x 14.2 inches)
. . . is identical in pixel count, memory and RAM usage to . . .
A 1024 x 1024 pixel image at 200ppi (5.12 inches x 5.12 inches)
Both have the same RAM usage (1024 x 1024 pixels), but different 'physical' sizes - so like you say RAM usage has had nothing to do with the physical size of an image.
I would imagine that Video Memory would handle image dimensions as you two have stated, but System Memory as well? Do you know offhand if PC's would handle it in the same fashion? I have had so many years working with PC's and have never heard of system memory functioning that way.
I have been creating my images in Inkscape 25% larger in size so they will export at the the size I want in 72dpi. For example to get a 64x64 72dpi png image I have to create it at 80x80. Is this a waste of time? If I export at 90 dpi the size is the same and would save all the mucking around calculating sizes.
Universal Binary Template - Universal Binary Template Instructions Rev 4 (Short) - Custom Score Display Template
I have one question which I can't get my head around, I've played Gesundheit (if you don't own it as a developer you should stop reading this and download it now) and it's ~500MB as far as I know . . . . so how does it run so smoothly on an iPad1 ?
EDIT: Sorry, of course, I was being stupid, it doesn't load the whole 500MB into RAM at once, just the scenes (and artwork and music and code) it needs as you progress through the levels. Sorry ! Lol, this is turing into a browbeating competition
Bit depth has no impact on RAM usage, as 8 bit and 24 bit images are both held in 24 colour space on the device (when in play)
So on disk: (made up figures to illustrate the point)
8 bit 1024 x 1024 pixel image = 2MB
24 bit 1024 x 1024 pixel image = 8MB
When in RAM:
8 bit 1024 x 1024 pixel image = 8MB
24 bit 1024 x 1024 pixel image = 8MB
Yep, that's the crucial take-home lesson to all this, keep stuff inside 2n values !
But if you know what size your images are (you should!) then the ppi is irrelevant, for example if you know you want your picture of an alien mothership to be 1024 x 1024 and you work on a 1024 x 1024 canvas in Photoshop (or wherever) - and when you bring it into GameSalad you place it on a 1024 x 1024 actor then the ppi will be irrelevant, it might have been 72ppi or 6,000ppi or 1ppi or 16,000,000ppi, but none of the this will have any bearing on anything, they will all be identical when put onto the 1024 x 1024 pixel actor.
But, just to clarify, the reason GS recommended 72ppi was because images imported at 72ppi will be read at the right size (in case someone is unaware of what size the image should be), basically a convenience for people who might not be aware of the correct image size. I'm a little confused by your question, Inkscape is vector based so resolution is not important ? You just need to export your images at the absolute pixel value they will be used at, so if you need a 512 x 512 image you need to export your artwork at 512 x 512, the ppi is largely irrelevant, but 72ppi might save you a little confusion.
2) Ohh, has won lots of awards I see - must check it out, thanks for the tip
3) That may very well be true but I didn't compare 8-bit vs 24-bit... I was comparing 24-bit vs 32-bit, I might still be wrong though so you have another chance here to beat me in the "bro match"
Since an RGB image with alpha channel is a 32-bit image in my book it would consume another 8bits in the equation so for example:
a) 1024x1024 png-image, 24-bit (RGB)
1024x1024x3 = 3 MB RAM
b) 1024x1024 png-image, 32-bit (RBG+A)
1024x1024x4 = 4 MB RAM
@Socks, Am I missing something?
Well worth taking a look at. Lol !
Damn, didn't spot the 32bit caveat, I've been out-bro'd.
1. Downloading Gesundheit now.. 03:35 AM here in Sweden, should be sleeping but wtf
2. Don't you know that I'm always right
Yes, I agree in regards to the file size. Tip: PNGOutWin by ardfry.com is bar none when it comes to png-compression.
Except for your time.
:-B
Lol, maybe an argument worth trying on my boss if I get one our late for work someday
Agree in regards to compression and IOS devices, though it's still very much worth it in my opinion. Also, as new and faster devices are being released this becomes less of a problem since decompession time / loading time becomes less for every iteration (I love my Ipad Air
I like to think that we are always ahead of you
Compression has got some worth when it comes to the apps size on disk, but - as you probably already know - it has no impact on performance or RAM usage, a 6MB file compressed down to 1.2MB will expand straight back out to 6MB once it's loaded into RAM.
I'm going to look at my iPad3 now and cry a little bit more . . . .
No, seriously - Ipad3 is lovely especially because of it's Retina screen. It's actually a better screen than on the Ipad Mini (2) Retina where the colors look really washed out - you see it easily when comparing a mini2 next to an Ipad3/4/Air.
There is however a quite noticeable performance difference when running GS apps on an Ipad3 vs Ipad Air
And of course; file compression has nothing to do with RAM usage - two completely different things but both are important to "master"
a Dr Who fan? :P
Yeah, I've heard even an iPad4 is a sizeable leap in processor power over the iPad3 - and the iPad Air is a sizeable leap above the iPad 4, so I imagine it must be pretty damn fast.
I hate my iPad3, I'm not going to talk to it all day tomorrow, I'll make it feel ashamed by dressing it up in an old ill-fitting cheap plastic iPad1 case and leaving it on a table in Starbucks, that'll show it who's boss.