RAM Usage/Image Size.

As_Of_Latte

Hey guys,

I'm trying to relieve some of the RAM usage on my game...I've noticed that my images are greatly bogging down the RAM.

I've designed my game/images within a 1536x2048px portrait, to be sure that each image is sharp for retina display on iPad.

I save my images individually from this 1536x2048px portrait as .png files and use ImageOptim software to compress the .png files before importing them into GameSalad.

So the images are imported into GameSalad at 2x the size for sharpness on iPad retina and the actors corresponding to the image is sized at 1x.

**For Example: **
Image Imported = 800x800px (72dpi)
Corresponding Actor size = 400x400px

This way, the images are definitely sharp for iPad retina display! However, it really takes an impact on the RAM...

---

I've tried this same route again, this time designing inside a 768x1024px portrait and importing my images at 1x the size. This route definitely works great for the RAM, however now the images are blurry for iPad retina.

Any ideas on how to achieve the image sharpness for iPad retina but save on RAM usage?

Thanks in advance!

adent42

First, ImageOptim is not going to help you. The image size in RAM is going to be directly based on the actual image dimensions, no matter the size of the file you save (since we're having to write the whole bitmap into a memory buffer).

As for suggestions...

1) can you compose the image in game. Use a background you can tile and then compose other elements of the image as other actors.

2) Split the difference. 1024 is too blurry, 2048 is too big. Maybe make an image that's somewhere in between. Like 1024x1536 and see if it looks good enough?

As_Of_Latte

@adent42 Thanks for the advice. I'm not sure if suggestion number 1 will work for the game I've designed However, I'll try and give suggestion number 2 a go.

Socks

@adent42 said:
2) Split the difference. 1024 is too blurry, 2048 is too big. Maybe make an image that's somewhere in between. Like 1024x1536 and see if it looks good enough?

With the way images are held in RAM (at least with the current Pre-New-Rendering-Engine setup) there would no point sizing an image between those two dimensions (if the goal was to reduce the srtain on the RAM/Processor) as any dimension above 1024 pixels (even a single-pixel-larger image at 1025 pixels) will be held in a 2048 pixel 'chunk' of RAM - so if your compromise image size were, for example, 1200 x 1600 px you may as well use a 1536 x 2048 px image as the quality will be better with no additional RAM impact.

Which relates to another point worth making . . . @As_Of_Latte . . an image imported at 800 x 800 px will be held in RAM as a 1024 x 1024 px image, a 1536 x 2048 px will be held in RAM as a 2048 x 2048 px image (etc) . . . . basically you need to round up* your image dimensions to calculate their RAM usage (*round up to the smallest powers-of-2 dimension the image will fit within).

Personally I would always approach these sorts of things from the angle adent42 mentions, composing the image within the game.

colander

Tiling is a must for large images if you want your game to run reliably or at all for that matter. Here I am not talking about using the same small image repetitively to to form a large background. I am talking about cutting a large background image like 2048x6144 into smaller 512x512 pieces.

I cut my images using the following commands in the Terminal app. Locate folder containing image to be cut for example: cd Desktop/foldername

Then use the following command to cut it up: convert myimage.png -crop widthxheight +repage +adjoin myimage_%01d.png

For example if your background image name was Bg_S1 and you wanted to cut it into 512x512 pieces to suite 256x256 actors the command would be: convert Bg_S1.png -crop 512x512 +repage +adjoin S1_%01d.png

It will keep the original image and produce images cut to size and numbered consecutively in the same folder.

Hopscotch

There are lots of good tips in the dev log from Darker Dungeon regarding optimised backgrounds, tiling and reusing assets.

Socks

@colander said:
Tiling is a must for large images if you want your game to run reliably // I am talking about cutting a large background image like 2048x6144 into smaller 512x512 pieces.

I've never heard of this, in what way (technically speaking) would 4 x 512 x 512 px images be more advantageous than a single 1024 x 1024 px image ?

Lovejoy

@Socks said:
I've never heard of this, in what way (technically speaking) would 4 x 512 x 512 px images be more advantageous than a single 1024 x 1024 px image ?

From my understanding smaller images will render faster.

Here is an example:

One 1024x1024 image, lets say it takes 1 second for it to fully load from 0% to 100%.

One 512x512 image, lets say take 0.25 seconds to fully load from 0% to 100%.

So 4 total images of 512x512 will still each load in 0.25 seconds from 0% to 100% and save you the processing power of 0.75 extra second a 1024x1024 image would take.

----0----0.25----0.50----0.75----1

1024-----------------------------|100%

512-------|100%
512-------|100%
512-------|100%
512-------|100%

Again, this is just from my understanding.

Edit:

I got my numbers mixed up but you get the point I'm trying to make.

colander

@Socks it has been a year since I did this and thinking back it is a little vague now. If I remember correctly the largest actor that can be created in GS is 1024x1024 and tiling these in my large scene 1024x3072 would cause older devices to crash. When I used 256x256 actors the performance improved on an iPad 1 and iPhone 4, it would load quicker and run smoother and not crash. I didn't want to go even smaller than this to test it as it already took 48 actors instead of three 1024x1024.

I can't tell you the technically reasons why just the results. I don't know if it would still apply as a lot of improvements have been made to Creator. But when I last worked on it large actors and images definitely impacted performance.

Socks

@Lovejoy said:
One 1024x1024 image, lets say it takes 1 second for it to fully load from 0% to 100%.
One 512x512 image, lets say take 0.25 seconds to fully load from 0% to 100%.
So 4 total images of 512x512 will still each load in 0.25 seconds from 0% to 100% and > save you the processing power of 0.75 extra second a 1024x1024 image would take.

If this theory were true then you could iterate the logic down to - for example - 1024 32x32 px images that would - in theory - load in 0.00097th of a second (or, at it's extreme, 1,048,576 1x1 px images loading in 0.00000095th of a second) compared to 1 second for a single 1024 x 1024 px image.

Which would mean all images, whether 2048 x 2048 px or 1 x 1 px could, if sufficiently divided, load in 0.00000095th (assuming our hypothetical 1 second loading time for a 1024 x 1024 px image), which obviously doesn't make much sense ?

I can't see this being the case, I suspect that if a 1024 x 1024 px image takes - for example - 1 second to load, then 4 x 512 x 512 px images will also take 1 second to load, and 1024 x 32 x 32 px images will also take 1 second to load (assuming there is no additional overhead from splitting and loading images).

Socks

@colander said:
Socks it has been a year since I did this and thinking back it is a little vague now. If I remember correctly the largest actor that can be created in GS is 1024x1024 . . .

There is no theoretical limit on actor sizes in GameSalad, I am working on a project at the moment with a 10,240 x 13,209.6 px actor without any issue at all.

@colander said:
and tiling these in my large scene 1024x3072 would cause older devices to crash.

That would be just three 1024 x 1024 px images ? Just tested this on an iPad 1, it works just fine ? Maybe there was some other underlying issue ?

@colander said:
When I used 256x256 actors the performance improved on an iPad 1 and iPhone 4, it would load quicker and run smoother and not crash. I didn't want to go even smaller than this to test it as it already took 48 actors instead of three 1024x1024.

You could chop your images into as many pieces as you like - for example 768 x 64 x 64 px images - number them sequentially - and have GameSalad lay them out for you with a simple iterating change self.image rule.

@colander said:
I can't tell you the technically reasons why just the results.

Like I say I suspect there was probably some other underlying reason ?

tmann

The possibility of a certain level of concurrency could certainly account for the four quarters of a whole etc loading faster. So tiling large backgrounds could certainly make sense.

Once again without serious engine docs who knows.

colander

@Socks if you create a test project with three actors it probably won't make a difference. But add all the other actors, images and game mechanics of a large game and it does or it did when I last made a game.

Socks

@colander said:
Socks if you create a test project with three actors it probably won't make a difference. But add all the other actors, images and game mechanics of a large game and it does or it did when I last made a game.

Then what is making the difference ? The three actors which showed no issues, or all the actors, images and game mechanics of a large game that when added make a difference ?

Lovejoy

@socks a system (phone/gamesalad/engine/pc) can handle loading more than one image at a time, so loading the 4 images becomes faster than loading the 1 larger image.

Socks

@Lovejoy said:
socks a system (phone/gamesalad/engine/pc) can handle loading more than one image at a time . . .

I understand that, that's not the issue with this theory, the logic dictates that the system would see a 1024 x 1024 px image and decide to only load that (!?) while seeing 4 x 512 x 512 pixel images and deciding to load all 4 at once . . . ?

Why would any system do that, why would it not simply load the 1024 x 1024 px image alongside other images ? Why would it hit a 1024 x 1024 px image and decide to pause all other image loading ? Whereas it would hit a 512 x 512 px image and decide to concurrently load other 512 x 512 px images ?

@Lovejoy said:
so loading the 4 images becomes faster than loading the 1 larger image.

The logic of this idea says that would only be true if a project contained either 1 large image or 4 smaller images (of the same overall size).

Lovejoy

@Socks Everything would load along side each other, what i was trying to show was how 4 smaller images would load the overall picture faster than the 1 larger image.

you can have 1,4,10 or however many 1024x1024 images load alongside each other, but the system itself can only load each image so fast. This is why i tried drawing it out above, to show how smaller images pieced together would take advantage of the loading speed to complete the full picture faster.

colander

@Socks said:
Then what is making the difference ? The three actors which showed no issues, or all the actors, images and game mechanics of a large game that when added make a difference ?

The combination of every actor, image and mechanic adds to the strain on the device as it has to load, redraw, etc as the game runs. Anything that lessens the load helps.

Armelline

I'm going to be fascinated to see who ends up being right in this discussion. On the one hand, it seems so counterintuitive if loading multiple smaller images happens faster than loading one equally sized image.

On the other hand, GameSalad does things in weird ways sometimes!

colander

@Armelline said: On the other hand, GameSalad does things in weird ways sometimes!

Yeah who knows what is going on there. My experience with GS has taught me bigger is not better. I try to keep things smaller where possible.

I also consider this when choosing a platform for a game. My second game had a machine gun spawning bullets with lots of actors stationary and flying around with a ton of animation for splatter. I wrote the first version in iPhone 5 and later on I went back to do a rewrite and decided to do it in 720p HD but it would crash on older devices. I tried a smaller platform Nook still no good so I stuck with iPhone 5. Of course it is game dependent and I will use a larger platform where possible, they are much easier to work in.

With the memory leak fixes this may be a lot better. I have let my pro membership lapse due to work commitments so I wont be going back to retest it.

Lovejoy

@Armelline said:
I'm going to be fascinated to see who ends up being right in this discussion. On the one hand, it seems so counterintuitive if loading multiple smaller images happens faster than loading one equally sized image.

On the other hand, GameSalad does things in weird ways sometimes!

Agreed, this is a question that everyone would benefit from knowing the details.

Socks

@Lovejoy said:
you can have 1,4,10 or however many 1024x1024 images load alongside each other . . .

Only up to the 'parallel' / 'concurrency' (or whatever the right phrase would be) capabilities of the system, obviously we couldn't have a hundred thousand images loading concurrently, the bandwidth will be limited by various factors.

@Lovejoy said:
but the system itself can only load each image so fast. This is why i tried drawing it out above, to show how smaller images pieced together would take advantage of the loading speed to complete the full picture faster.

I can't see how this would work, of course I could be wrong (it wouldn't be the first time, not even today ) but even the suggested theory doesn't seem to make sense (to me at least), I expect image data is read into a system in the order it's called at the speed of the system, and changing the order in which things are read doesn't increase speed ?

And in what way would reading 4 x 512 x 512 px images (for example) be any different than reading 1 x 1024 x 1024 px image, if the suggestion is that a system can read 4 (or more) images in parallel then surely that same capability would be brought to bear on the single 1024 x 1024 px image (for example the system would simply read the single 1024 x 1024 px image in 512 x 512 px chunks to maximise efficiency). As a practical example of this Apple (and partners) invest countless sums of money into developing better and better hardware, but all the while their graphics pipeline could be enormously improved by simply parsing image data in smaller packets ?

This is something I would love to be wrong about, who wouldn't, it would be a free (and easy to implement) route to more efficient, faster loading games, but in the absence of hard evidence I suspect cutting images into smaller pieces is unlikely to speed things up (?)

Socks

@colander said:
Anything that lessens the load helps.

Agreed, but I suspect chopping up images into smaller piece doesn't help !

Socks

@Armelline said:
I'm going to be fascinated to see who ends up being right in this discussion.

I'd love Colander / Lovejoy to be right, if they are right we have a very simple route to improving the performance of GS projects (where applicable), but unfortunately I agree with this next sentence . . . .

@Armelline said:
On the one hand, it seems so counterintuitive if loading multiple smaller images happens faster than loading one equally sized image.

. . . I can see an argument for the parallel loading (to RAM) of multiple images, but as I've said elsewhere the idea that this exists and is not already automatically implemented seems vanishingly unlikely, if a system can parse 4 x 512 x 512 px images at once (for example) then it will almost certainly apply the same tools universally, the obvious corollary to this would be that our 1024 x 1024 px image also gets read in 512 x 512 chunks . . . at the same speed !

Socks

@Lovejoy said:
Agreed, this is a question that everyone would benefit from knowing the details.

Agreed, there are a whole bunch of GS things like this that would be useful to know, when Toyman was alive and functioning (pre-codewizard coup ) he went to great lengths explaining the new (upcoming) rendering system covering all these kinds of things in detail - and you could quickly see how this information could really help you make better, faster, smoother running games.

Lovejoy

@Socks I can't really go on about this subject because even I'm not completely sure about the inner workings of it.We need Toyman in this conversation for sure. I was just thinking that earlier today. Where do i vote on the feature request to bring Toyman here?

colander

@Socks said:

@colander said:
Anything that lessens the load helps.

Agreed, but I suspect chopping up images into smaller piece doesn't help !

I finally got around to testing this again in v1.23.1 and it no longer applies. I took the 48 256x256 actors out and replaced them with 3 1024x1024 actors and they loaded in the same amount of time on an iPhone 4.

So please ignore my advice I posted earlier in this thread.