GameSalad

Another performance question, image stretching

RossmanBrothersGamesRossmanBrothersGames Posts: 648Member, PRO
edited February 4 in Working with GS (Mac)

Hey guys, one more question as I am going through the process of some slight optimization adjustments. Really glad where gamesalad has come as our game is far more complex that projects in the past, but runs really well, just want to make some adjustments to make sure it is running at its best.

My questions: does stretching an image put any strain on the image, or are larger images a more significant strain.

Our game is pixel art, so our original images 1/4 the size of the final retna images to fit the look we want. So an image that starts at 16 by 16 would be exported as 64 x 64 and put on a 32 x 32 actor giving us a nice crisp image.

However some of our background images are rather large, I noticed if I put a 3x image in there instead of a 4x you really don't notice much of a difference as far as crispness goes. For example we may have a background image that is 800 x 800, (the original image being 200 x 200) and the actor being 400 x 400. Would replacing images like that with a 600 x 600 version of the image have less strain on the engine, or does the stretching put a strain? Again it doesn't really change the look, I've already tested that, just want to know if those of you with knowledge of how the engine handles images ( @adent42 @The_Gamesalad_Guru @Armelline ) think that a bunch of changes in that way would put less strain on the engine. And would this help with larger animated images, we have some large animations, would a stretched animation that is slightly smaller be better? Thanks again!

Comments

  • SocksSocks London, UK.Posts: 12,698Member, PRO
    edited February 4

    @RossmanBrothersGames said:
    My questions: does stretching an image put any strain on the image . . .

    Yes, if you stretch an image too much it does place strain on the image, in fact if you stretch it too much the image will eventually snap. :p

    @RossmanBrothersGames said:
    However some of our background images are rather large, I noticed if I put a 3x image in there instead of a 4x you really don't notice much of a difference as far as crispness goes.

    3x . . . 4x . . . !?

    You should only really ever need to produce 2x image assets, what project size are you working with ?

    @RossmanBrothersGames said:
    For example we may have a background image that is 800 x 800, (the original image being 200 x 200) and the actor being 400 x 400. Would replacing images like that with a 600 x 600 version of the image have less strain on the engine, or does the stretching put a strain?

    Stretching an image does not place any additional strain on the processor - compared to showing the image 1:1.

    Also a 600 x 600 pixel image and a 800 x 800 pixel image will both use the same amount of memory and place the same amount of strain on the processor as they will both be padded out to 1024 x 1024 pixels when loaded into RAM.

    So, there would be no advantage at all in reducing an 800² image to a 600² image, you will just compromise the image quality.

  • RossmanBrothersGamesRossmanBrothersGames Posts: 648Member, PRO
    edited February 4

    Thanks for poking fun at my writing mistakes :D

    @Socks said:

    You should only really ever need to produce 2x image assets, what project size are you working with ?

    Might not have explained this well enough...

    Since I am using pixel art the original image is much smaller. So my final images are 2x (like you suggest) the actor size, but 4x the original image

    so for an actor that is 32x32 in our game, we drew a 16x16 image and multiplied it by 4 to get a 64x64 image to put on the 32x32 actor.

    @Socks said:

    Also a 600 x 600 pixel image and a 800 x 800 pixel image will both use the same amount of memory and place the same amount of strain on the processor as they will both be padded out to 1024 x 1024 pixels when loaded into RAM.

    So, there would be no advantage at all in reducing an 800² image to a 600² image, you will just compromise the image quality.

    Are you sure about this? I thought that was only true of that new graphics engine that never ended up getting implemented.

    In fact we have a boss that had an image size 800 x 900 and it was animated. (It needed to be this large as it had some frames where it held its sword well above its head)

    It kept crashing the game so we changed those frames so that that boss could fit into a 660x700 image and the crashing went away.

  • SocksSocks London, UK.Posts: 12,698Member, PRO
    edited February 4

    @RossmanBrothersGames said:
    Since I am using pixel art the original image is much smaller. So my final images are 2x (like you suggest) the actor size, but 4x the original image.

    Ah! I see, for the sake of clarity I would describe your images technically rather than . . . hmmm . . what's the right word, 'aesthetically' ? Maybe 'visually' is better . . . 2x means something specific (technically) . . . GameSalad doesn't know these images have been scaled up (to ensure chunky pixels).

    @RossmanBrothersGames said:
    Are you sure about this? I thought that was only true of that new graphics engine that never ended up getting implemented.

    Yes, that's how the device works, that's how memory works (nothing to do with GameSalad). It was like this prior to the announcement of the new graphics engine, and seeing as the new graphics engine wasn't implemented it is still like this, in fact it was like this before GameSalad even existed ! And even if the new graphics engine was implemented it would still be the case that images in RAM are subject to the powers of 2 rule (the shelved new graphics engine chopped images into 64 x 64 pixel chunks - keeping within the powers of 2 rule).

    @RossmanBrothersGames said:
    In fact we have a boss that had an image size 800 x 900 and it was animated. (It needed to be this large as it had some frames where it held its sword well above its head)

    It kept crashing the game so we changed those frames so that that boss could fit into a 660x700 image and the crashing went away.

    Not enough details to comment, but a 800 x 900 pixel image and a 660 x 700 pixel image both occupy a 1024 x 1024 pixel chunk of memory.

  • RossmanBrothersGamesRossmanBrothersGames Posts: 648Member, PRO

    @Socks said:

    800 x 900 pixel image and a 660 x 700 pixel image both occupy a 1024 x 1024 pixel chunk of memory.

    Interesting. Must be some other reason it fixed the issue. So is the next step down images smaller than 512 by 512?

  • SocksSocks London, UK.Posts: 12,698Member, PRO
    edited February 4

    @RossmanBrothersGames said:
    Interesting. Must be some other reason it fixed the issue. So is the next step down images smaller than 512 by 512?

    Yes, a 512 x 512 pixel image is 4x smaller than a 660 x 700 pixel image (512² vs 1024²), that's 75% less pixels for the processor/GPU to be throwing around the screen !

  • RossmanBrothersGamesRossmanBrothersGames Posts: 648Member, PRO

    Thanks @Socks basically any images I have that are just over 512 may be worth changing up, good to know.

  • ToqueToque Posts: 869Member, PRO

    This memory allocation is a device attribute for loading in to ram?

    Because storage it does change correct?

    On my mac in preview. If I change image size.

    512x512 82 kb
    800x800 160
    900x800 191

    So a 600x600 image would still be better than a 1000x1000 for game size?

  • SocksSocks London, UK.Posts: 12,698Member, PRO

    @Toque said:
    This memory allocation is a device attribute for loading in to ram?

    Because storage it does change correct?

    Yes.

    Images in RAM are held in full 24/32 bit RGB/A colour space (uncompressed), whereas when stored on a device images can take advantage of compression.

    @Toque said:
    On my mac in preview. If I change image size.

    512x512 82 kb
    800x800 160
    900x800 191

    Too many questions . . . Format ? Compression ? Is this the file size or the size on disk ?

    @Toque said:
    So a 600x600 image would still be better than a 1000x1000 for game size?

    What is 'game size' ? Do you mean the size of the file on disk ?

    I wouldn't be so sure there would even be a storage advantage, GameSalad uses its own compression system, so its hard to say, also any gains or loses would also be effected by the image content . . for example you can easily generate a 800 x 800 pixel uncompressed PNG that weighs in at ~2MB, then simply change something about the image (for example add noise) and the same 800 x 800 pixel is now ~400kb.

    Another example - a graphic image (hard edges, blocks of colour, pixel art . . . etc) at 800 x 800 pixels might be as small as 40kb . . . and the same image reduced to 200 x 200 pixels (using nearest neighbour) might still end up at 40kb because of the way a PNG is stored.

    And here's the kicker . . . . . that same 800 x 800 pixel graphic image (40kb) reduced to 200 x 200 pixels using a standard bicubic interpolation could end up being something like 200kb (bigger file size !), simply because the process of interpolation is adding more colours to the file (on the edges between contrasting colours).

    So it's not always as straightforward as smaller absolute pixel counts = smaller file sizes.

    (And the OP is mainly dealing with graphic images, this is very relevent here)

  • ToqueToque Posts: 869Member, PRO

    @Socks said:

    @Toque said:
    This memory allocation is a device attribute for loading in to ram?

    Because storage it does change correct?

    Yes.

    Images in RAM are held in full 24/32 bit RGB/A colour space (uncompressed), whereas when stored on a device images can take advantage of compression.

    @Toque said:
    On my mac in preview. If I change image size.

    512x512 82 kb
    800x800 160
    900x800 191

    Too many questions . . . Format ? Compression ? Is this the file size or the size on disk ?

    @Toque said:
    So a 600x600 image would still be better than a 1000x1000 for game size?

    What is 'game size' ? Do you mean the size of the file on disk ?

    I wouldn't be so sure there would even be a storage advantage, GameSalad uses its own compression system, so its hard to say, also any gains or loses would also be effected by the image content . . for example you can easily generate a 800 x 800 pixel uncompressed PNG that weighs in at ~2MB, then simply change something about the image (for example add noise) and the same 800 x 800 pixel is now ~400kb.

    Another example - a graphic image (hard edges, blocks of colour, pixel art . . . etc) at 800 x 800 pixels might be as small as 40kb . . . and the same image reduced to 200 x 200 pixels (using nearest neighbour) might still end up at 40kb because of the way a PNG is stored.

    And here's the kicker . . . . . that same 800 x 800 pixel graphic image (40kb) reduced to 200 x 200 pixels using a standard bicubic interpolation could end up being something like 200kb (bigger file size !), simply because the process of interpolation is adding more colours to the file (on the edges between contrasting colours).

    So it's not always as straightforward as smaller absolute pixel counts = smaller file sizes.

    (And the OP is mainly dealing with graphic images, this is very relevent here)

    Ok. I get what your saying. Thanks

  • pHghostpHghost London, UKPosts: 1,905Member

    @Socks said:
    Not enough details to comment, but a 800 x 900 pixel image and a 660 x 700 pixel image both occupy a 1024 x 1024 pixel chunk of memory.

    @RossmanBrothersGames said:
    Thanks @Socks basically any images I have that are just over 512 may be worth changing up, good to know.

    Is that still the case? I thought that GS revamped their way of handling graphics and are using 2048x2048 mega-textures which combine multiple mapped images together, so that you reduce the overhead of wasted memory?

    In such a case reducing to 660x700px could have an effect, because it might fit into an already in-use mega-texture with no extra memory strain, whereas the 800x900px wouldn't fit and thus another mega-texture had to be created, overloading the memory and causing a crash.

  • adent42adent42 Posts: 735Key Master, Head Chef, Executive Chef, Member, PRO GameSalad Employee

    It's still the case.

    @pHghost, we were never able to fully debug the the mega-texture system. It was very promising for some games, but we always ran into issues with some images being excluded from loading. Any image heavy game ran into problems.

    A combination of having to divert resources to kill the macOS tool memory leak and subsequently the switch to new tool development means we've left that effort behind for now.

  • SocksSocks London, UK.Posts: 12,698Member, PRO
    edited February 9

    @adent42 said:
    It's still the case.

    @pHghost, we were never able to fully debug the the mega-texture system. It was very promising for some games, but we always ran into issues with some images being excluded from loading. Any image heavy game ran into problems.

    A combination of having to divert resources to kill the macOS tool memory leak and subsequently the switch to new tool development means we've left that effort behind for now.

    If we were allowed to alter the horizontal and vertical anchor for an actor's image at runtime we could easily fashion our own sprite sheets (as well as allowing numerous other tricks like easy to impliment parallaxing and various masking tricks).

  • pHghostpHghost London, UKPosts: 1,905Member

    @adent42 said:
    It's still the case.

    @pHghost, we were never able to fully debug the the mega-texture system. It was very promising for some games, but we always ran into issues with some images being excluded from loading. Any image heavy game ran into problems.

    A combination of having to divert resources to kill the macOS tool memory leak and subsequently the switch to new tool development means we've left that effort behind for now.

    Thanks for the info on that -- somehow I had the feeling it had been implemented and have become a bit reckless with high-resolution image use!

  • pHghostpHghost London, UKPosts: 1,905Member

    @Socks said:

    3x . . . 4x . . . !?

    You should only really ever need to produce 2x image assets, what project size are you working with ?

    In my latest project, I am actually trying something that might sound a bit crazy, but it actually is working great so far. I'm using image assets that are 3.2x the size of the actor.

    If you stick to actor sizes that are divisible by 5, your image sizes will always be 16x16, 32x32, 480x480 -- multiples of 16.

    This number is also gives you optimal image sizes when designing Universal apps in the GS iPhone 5 Project (or camera size, as you can have a different preset and just adjust the camera proportions instead). The reason I prefer this is because I often build single-scene games and with an iPad-sized canvas, it gets horribly unwieldy and annoying to scroll around (I wish the zoom in/out that was in one of the beta versions makes it to public release version at some point). Also, mathematically, 320 points across is much better to work with compared to the 768 of the iPad Project.

    In the iPhone 5 Project (320x568 starting canvas), to cater for iPad, the equivalent scene size adjusted for ratio is 426x568.

    320x568 times 3.2 is a 1024x1818 (1817.6) pixel-size canvas, which is less than 6% under full screen resolution of iPhone Plus models, so it will give you nice crisp graphics. At the same time, restricting the width to 1024px is also good for memory use, since a 1080px image would take up the same memory as 2048px, which is a huge difference (of course, this only applies if you need to use full-size backgrounds). For the iPad, that takes you to 1363px (1363.2) across and leaves you with less than 12% under full screen resolution, which is still great for image clarity.

    You can ignore all this if your target platform is only iPad, of course. There the typical 2x assets are still standard. Though I would generally make my canvas smaller (512x384) and go for 4x assets (note here: your assets actually stay the same size as they would be before, but you just shrink your actors to half size, which makes the assets 4x in relation). Yes, that's how much I dislike scrolling around huge scenes.

  • SocksSocks London, UK.Posts: 12,698Member, PRO
    edited March 16

    @pHghost said:
    In my latest project, I am actually trying something that might sound a bit crazy, but it actually is working great so far. I'm using image assets that are 3.2x the size of the actor.

    If you stick to actor sizes that are divisible by 5, your image sizes will always be 16x16, 32x32, 480x480 -- multiples of 16.

    Interesting idea !

    The only issues I can see (if I understand it correctly) is that you will be comprising image quality a little on most devices, as the pixels in your image/actor won't be aligning 1:1 with the screen pixels, and of course you will be placing more of a strain on the target device with larger images - for example whereas normally a 500 x 500 pixel actor would require a 1000 x 1000 pixel image, using 3.2x would require a 1600 x 1600 pixel image (which would occupy a 2048 x 2048 pixel chunk of RAM).

    But depending on your project these issues might not be a problem, for example image quality compromised by image pixels not aligning with screen pixels is irrelevant if the actor is moving.

    It's certainly an interesting approach, could be useful for a few things, I like the fact that everything automatically divides into RAM friendly image sizes - and is always divisible by 4.

    @pHghost said:
    Yes, that's how much I dislike scrolling around huge scenes.

    :) :# tell me about it !!

    It's frustrating that GameSalad did all that work on the zoom function and having windows retain their last position (this would have made moving around large scenes so much easier) . . . just to abandon it (like pretty much everything else they seem to work on!).

  • AlchimiaStudiosAlchimiaStudios Posts: 806Member, PRO

    @Socks said:

    It's frustrating that GameSalad did all that work on the zoom function and having windows retain their last position (this would have made moving around large scenes so much easier) . . . just to abandon it (like pretty much everything else they seem to work on!).

    I really wish this was in a stable build. Those two are huge for me, and i'm sure many others.

    Follow us: Twitter - Website

  • pHghostpHghost London, UKPosts: 1,905Member

    @Socks said:
    The only issues I can see (if I understand it correctly) is that you will be comprising image quality a little on most devices, as the pixels in your image/actor won't be aligning 1:1 with the screen pixels

    Yes, this compromise is definitely something to be considered, and might not be worth it depending on the project. BUT: from my testing, the visual quality holds up very well (basically not noticeable by eye even with sharp geometry) at these small percentages of image blow-up. Ultimately, you will never get a perfect 1:1 in any project, because of the mess of resolutions (even if you stick to Apple only). Three sizes of iPhone screen (though the 5SE family might go away soon), plus iPad (which might be messed up even more with the rumoured 10.5 inch one). I've been testing mostly with pixel art assets, and must say I'm impressed with the crisp look.

    Things will probably start looking muddy on the 12.9 iPad Pro, but that's the one compromise I'll happily make.

    @Socks said:
    and of course you will be placing more of a strain on the target device with larger images - for example whereas normally a 500 x 500 pixel actor would require a 1000 x 1000 pixel image, using 3.2x would require a 1600 x 1600 pixel image (which would occupy a 2048 x 2048 pixel chunk of RAM).

    It should actually be equal strain or less strain. The reason is that GS 'points' are a pretty much entirely abstract and fluid in themselves. They only attain a concrete value relationally to the size of the GS camera. So, for example, if you have a full-screen image on an iPad project, the actor will be 1024 GSpoints tall and the texture will be 2048px, so it's a 2x texture, as usually recommended. But, if you reduce the camera size to 1/2 and the actor to 1/2, you have an actor that is 512 GSpoints tall and the texture will still be 2048px, so it is actually a 4x texture, because you want the same visual quality. It will display exactly the same on device, take up the same amount of memory, but will take up 4x less visual space in GS Creator. The only downside to this is that GameSalad renders its DisplayText fonts in relation to the GS camera size, not the device resolution, so you might end up with blurrier text, unless you use images instead of DisplayText.

    So, in the case of the app I'm working on, reducing the displayed resolution of the screen width to 1024px, you will get a 2048x1024 chunk of memory taken. If you went with the 1:1 resolution of 1080px for the iPhone Plus, you would use 2048x2048 of memory. You will still take that much if you extend the image resolution for iPad aspect ratios, but I usually use filler images on the iPad fringes. The image is only reduced in quality (stretched out) on iPhone Plus and iPad devices (by about 6% and 12% respectively), but on smaller iPhones there is more resolution than required.

  • SocksSocks London, UK.Posts: 12,698Member, PRO

    @pHghost said:
    Yes, this compromise is definitely something to be considered, and might not be worth it depending on the project. BUT: from my testing, the visual quality holds up very well (basically not noticeable by eye even with sharp geometry) at these small percentages of image blow-up. Ultimately, you will never get a perfect 1:1 in any project, because of the mess of resolutions (even if you stick to Apple only). Three sizes of iPhone screen (though the 5SE family might go away soon), plus iPad (which might be messed up even more with the rumoured 10.5 inch one). I've been testing mostly with pixel art assets, and must say I'm impressed with the crisp look.

    Yes, agreed, depending on the particular artwork you can often get away with non-1:1 resolution and still have the images look great (like I say moving objects are one example where you can all but ignore the issue).

    @pHghost said:
    Things will probably start looking muddy on the 12.9 iPad Pro, but that's the one compromise I'll happily make.

    Those people don't care, they've got loads of money so are probably always drunk/high.

    @pHghost said:
    It should actually be equal strain or less strain. The reason is that GS 'points' are a pretty much entirely abstract and fluid in themselves. They only attain a concrete value relationally to the size of the GS camera. So, for example, if you have a full-screen image on an iPad project, the actor will be 1024 GSpoints tall and the texture will be 2048px, so it's a 2x texture, as usually recommended. But, if you reduce the camera size to 1/2 and the actor to 1/2, you have an actor that is 512 GSpoints tall and the texture will still be 2048px, so it is actually a 4x texture, because you want the same visual quality. It will display exactly the same on device, take up the same amount of memory, but will take up 4x less visual space in GS Creator. The only downside to this is that GameSalad renders its DisplayText fonts in relation to the GS camera size, not the device resolution, so you might end up with blurrier text, unless you use images instead of DisplayText.

    Ah, I see (at least I think I do !!), you are zooming in - but increasing the resolution of the assets accordingly so when zoomed in the resolution is what it would have been if you were not zoomed in.

    Sounds like a pretty good approach for quite a few situations ! I might play around with the idea myself (then steal it an claim it as my own :) )

Sign In or Register to comment.