GameSalad

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Optimizing your artwork

DillonVDillonV South FloridaPosts: 26Member
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!
«1

Comments

  • bryanearlbryanearl Wasilla, AlaskaPosts: 49Member, PRO
    edited January 2014
    When your program starts, it is loaded into temporary memory (RAM). That means that all the code, images, sounds etc all get loaded into RAM. The less "free" (unused) RAM that your device has available, the slower it will run. If you fill it up all the way, the performance will be poor and may even error out or crash...

    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.
  • SocksSocks London, UK.Posts: 12,822Member
    edited January 2014
    @bryanearl

    Sorry to sound like an old pedant (which I am ;) ) but there are a couple of misunderstandings here . . . .
    bryanearl said:

    When your program starts, it is loaded into temporary memory (RAM).That means that all the code, images, sounds etc all get loaded into RAM.

    This is not entirely true, if it were true then we'd have no use for functions like 'Preload Art' . . . . nor would we see those little glitches (where applicable) when images are called for the first time. Generally speaking assets are loaded into RAM when they are called, unless we force them into RAM (to avoid loading glitches).

    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).
    bryanearl said:

    The less "free" (unused) RAM that your device has available, the slower it will run. If you fill it up all the way, the performance will be poor and may even error out or crash...

    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.
    bryanearl said:

    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.

    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.
    bryanearl said:

    Lets say you have an image (1024 x 1024 at 72 DPI). That image may be 500kb in file size. If it were the same 1024 x 1024, but the DPI was set to 200, the image will be twice the file size (1,000+ kb)

    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 > :[email protected]
  • bryanearlbryanearl Wasilla, AlaskaPosts: 49Member, PRO
    edited January 2014
    EDITED

    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?
  • JSprojectJSproject Posts: 730Member
    edited January 2014
    bryanearl said:



    1)...The less "free" (unused) RAM that your device has available, the slower it will run. If you fill it up all the way, the performance will be poor and may even error out or crash...

    2)...A 1024x1024 image will consume more memory than 800x800.

    1) IOS devices will not run slower with lesser RAM available. Apps that are running in the background will be automatically unloaded from memory by the operating system (IOS) to free up RAM on the device if an app needs more RAM than what is currently free.

    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.

  • JSprojectJSproject Posts: 730Member
    edited January 2014
    ohh, and a great answer (as expected) from @Socks also I see (but man I thought you were at sleep by now ;))
  • SocksSocks London, UK.Posts: 12,822Member
    edited January 2014
    @bryanearl
    bryanearl said:

    So, regarding the "ppi" and RAM usage (I am used to "DPI", not "PPI", I assume you are using MAC)...

    The correct term is ppi (pixels per inch) - rather than dpi (dots per inch), but to be honest they've become largely interchangeable these days and people use them to mean the same thing.

    '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.
    bryanearl said:

    If I have a 1200 DPI image that is 22mb in file size and another exact same size image that is 72 DPI and only 1mb in file size, you are saying that they will consume the exact same amount of RAM?

    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.
    bryanearl said:

    Same goes for the physical image size... In my 20+ years as a PC tech, RAM usage has had nothing to do with the physical size of an image.

    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.

  • bryanearlbryanearl Wasilla, AlaskaPosts: 49Member, PRO
    JSproject said:

    ohh, and a great answer from @Socks also I see :)

    Yes, you both listed excellent information, and I am happy any day to be corrected and learn something new. I am hoping for some more clarification on the image dimensions vs RAM usage...

    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.

  • SocksSocks London, UK.Posts: 12,822Member
    bryanearl said:

    . . . if you force the image size to 1024 x 1024, regardless of the DPI, the outcome IS exactly the same.

    Agreed ! :)>-
    bryanearl said:

    I am still unsure about the physical size of the image affecting RAM usage though...

    'Physical size' has no bearing on RAM usage.
  • bryanearlbryanearl Wasilla, AlaskaPosts: 49Member, PRO
    @Socks Apparently we were typing our comments at the same time and you didn't see my second post after I edited it... I totally understand what you mean. Good info!
  • colandercolander Posts: 1,610Member
    In September I asked support "What dpi do my images need to be?" and they replied "For optimal use, 72 dpi" with no further explanation.

    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.
  • SocksSocks London, UK.Posts: 12,822Member
    edited January 2014
    @JSproject
    JSproject said:

    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

    Handy to know ! :)>- Cheers, I wasn't aware of these values.

    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.
    JSproject said:

    The image dimensions most certainly matter, so does bit depth.

    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
    JSproject said:

    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).

    Yep, that's the crucial take-home lesson to all this, keep stuff inside 2n values !
  • SocksSocks London, UK.Posts: 12,822Member
    @JSproject
    JSproject said:

    ohh, and a great answer (as expected) from @Socks also I see (but man I thought you were at sleep by now ;))

    No way, I've still got 6 bottles of 'London Pride', a half eaten Pineapple and Anchovy Pizza and a can of Chicken Noodle soup to get through, I could be here all night.
  • SocksSocks London, UK.Posts: 12,822Member
    @bryanearl
    bryanearl said:

    @Socks Apparently we were typing our comments at the same time and you didn't see my second post after I edited it... I totally understand what you mean. Good info!

    Yep! We were tripping over each other there, posting at the same time (I think forums need a name for that kind of thing).
  • SocksSocks London, UK.Posts: 12,822Member
    @colander
    colander said:

    In September I asked support "What dpi do my images need to be?" and they replied "For optimal use, 72 dpi" with no further explanation.

    Yes, 72ppi is good - in fact any ppi is just fine, 72ppi means that when you import your images then GameSalad will know what size they are.

    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.
    colander said:

    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.

    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.
  • JSprojectJSproject Posts: 730Member
    edited January 2014
    Socks said:



    1)... Handy to know ! :)>- Cheers, I wasn't aware of these values.
    2)...Gesundheit
    3)...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)

    1) You're welcome :)

    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? :p



  • SocksSocks London, UK.Posts: 12,822Member
    edited January 2014
    @JSproject
    JSproject said:

    2)...Gesundheit

    Yeah, big award winning app, very 'cute' / kiddie, but really really well done, the puzzles (how to kill the monsters and stay alive) really do get difficult, and you really do get tense when you are struggling to escape some great big furry **** running after you and trying to eat you ! :))

    Well worth taking a look at.
    JSproject said:

    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" ;)

    Lol !

    Damn, didn't spot the 32bit caveat, I've been out-bro'd. ;)
    JSproject said:

    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)
    1024x1024x = 4 MB RAM

    @Socks, Am I missing something? :p

    No, you are absolutely right, although RGBA [vs RGB] wouldn't necessarily add an additional 33.33% to the file size (that counts as my out-bro-ing attempt), that would depend on the content of the alpha channel (e.g. an entirely black alpha channel [unlikely I know] would only add a tiny fraction onto the file size)
  • JSprojectJSproject Posts: 730Member
    @Socks
    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.



  • SocksSocks London, UK.Posts: 12,822Member
    edited January 2014
    JSproject said:

    @Socks
    1. Downloading Gesundheit now.. 03:35 AM here in Sweden, should be sleeping but wtf ;)

    Why has Sweden got the wrong time ? Don't you know it's 02:35 AM ? We invented time here in the UK, everyone else has got it wrong.
    JSproject said:

    2. Don't you know that I'm always right ;)

    Except for your time. :)
    JSproject said:

    Yes, I agree in regards to the file size. Tip: PNGOutWin by ardfry.com is bar none when it comes to png-compression.

    Yes, PNGOutWin is really good, but compression in GS (and more importantly with iOS devices) is a moot point !

    :-B
  • JSprojectJSproject Posts: 730Member
    edited January 2014
    @Socks
    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 :).
  • DuesDues Posts: 1,159Member
    @Socks

    I like to think that we are always ahead of you ;)
  • JSprojectJSproject Posts: 730Member
    @Dues - lol, true but be gentle to him, he can't help that he's living in the past ;)
  • SocksSocks London, UK.Posts: 12,822Member
    @JSproject
    JSproject said:

    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'd love an iPad Air, but I'm stuck on an iPad3, I feel so ashamed, I only use it when no one is looking, and even then I cry when I use it.

    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 . . . .
  • SocksSocks London, UK.Posts: 12,822Member
    edited January 2014
    Dues said:

    @Socks

    I like to think that we are always ahead of you ;)

    I like to think I am always behind you, in the bushes, with a camera and a zoom lens.
  • SocksSocks London, UK.Posts: 12,822Member
    JSproject said:

    @Dues - lol, true but be gentle to him, he can't help that he's living in the past ;)

    It's ok here in 1857, our mobile phones are slow and made from wood and compressing a file actually makes it bigger, but the fonts are more interesting.
  • JSprojectJSproject Posts: 730Member
    Socks said:

    @JSproject

    JSproject said:

    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'd love an iPad Air, but I'm stuck on an iPad3, I feel so ashamed, I only use it when no one is looking, and even then I cry when I use it.

    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 . . . .
    Yes, you should be ashamed of that... very ashamed, go stand in a corner! :P

    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" :)
  • JSprojectJSproject Posts: 730Member
    Socks said:

    Dues said:

    @Socks

    I like to think that we are always ahead of you ;)

    I like to think I am always behind you, in the bushes, with a camera and a zoom lens.
    Sounds creepy.. ;)
  • JSprojectJSproject Posts: 730Member
    Socks said:

    JSproject said:

    @Dues - lol, true but be gentle to him, he can't help that he's living in the past ;)

    It's ok here in 1857, our mobile phones are slow and made from wood and compressing a file actually makes it bigger, but the fonts are more interesting.
    Hello Mr time traveller!
    a Dr Who fan? :P
  • SocksSocks London, UK.Posts: 12,822Member
    JSproject said:

    There is however a quite noticeable performance difference when running GS apps on an Ipad3 vs Ipad Air :)


    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.
  • SocksSocks London, UK.Posts: 12,822Member
    JSproject said:

    Socks said:

    Dues said:

    @Socks

    I like to think that we are always ahead of you ;)

    I like to think I am always behind you, in the bushes, with a camera and a zoom lens.
    Sounds creepy.. ;)
    It's worse than it sounds, I'm often naked.
  • SocksSocks London, UK.Posts: 12,822Member
    JSproject said:

    Socks said:

    JSproject said:

    @Dues - lol, true but be gentle to him, he can't help that he's living in the past ;)

    It's ok here in 1857, our mobile phones are slow and made from wood and compressing a file actually makes it bigger, but the fonts are more interesting.
    Hello Mr time traveller!
    a Dr Who fan? :P
    We haven't got Dr Who yet.
Sign In or Register to comment.