[Performance Question] Rendering on mobile

According to page in Mobile overdraw section:

https://www.scirra.com/blog/112/remembe ... our-memory

This text says a solution:

[quote:2ltb5mq1]The solution here is again to prefer using small images instead of large ones. A large image will eat up lots of the mobile's drawing budget in one go, whereas it's easier for it to render several spread out smaller objects. For example, a window-sized sprite to add borders round the edge of the screen is very inefficient, since the transparent pixels in the middle still use up the draw budget; using four separate sprites for each edge of the screen would be a lot faster.

I would like to review this solution, let me show you the examples.

This is a sprite to set as background:

It has 800 px of width and 336 px of height, basically it's not good idea to draw on mobile, the solution says 4 separated spirtes for each edge of the screen would be a lot faster, it makes me to think we should split this sprite into 4 pieces.

Each sprite has 400 px of width and 168 px of height, does it help?

Otherwise if you're going to say use power of two, let's see, it's using 256.

8 pieces using power of 2.

I'm not sure it would consume more memory usage than four pieces due to transperency.

What's is the best method?

Thanks.

I think you misunderstood that bit..

In the text snippet above, they were referring to using smaller images, if the target was to create a frame that would not cover the whole screen in the first place, but only the edges. So you would waste draw time, if you put a window sized sprite -on top-, with everything transparent but the frame. That indeed does not make any sense.

However in your example, splitting the BG up probably does not change anything, because it has to be drawn all over the screen anyway.

Indeed you misunderstood it, the article says that you can reuse images easily, so you should try to use smaller images to compose a big environnement, rather than having a big picture.And also that transparancy that physically exist in a picture is still stored in the memory (since it is information of the picture)

Slicing a big picture still takes the memory (pretty sure in some cases it could be worse at the end), mostly slicing object to keep memory low is comparable to fill a bucket with small glasses of water, at the end the same quantity is in the bucke, it might have advantages but not worth the effort, you should try another solution that ll be better and take less time at the end.

PS: you are not the only one to have read it like that, and everytime I say this is not the way to do it people says "but ashley said it", which can be really annoying since it is the interpretation of what he said that is wrong.I think a clearer response from him would help.

Eisenhans Oh really? I thought it would be another solution from this article, however you say it doesn't make sense and change anything, well I guess splitting sprites is useless now. My project contains 1.5 mb of download and 50 mb of memory usage, I'm looking alternatives to reduce memory images, my background images are splited by half width to avoid more than 1024. I'm wondering we have no expression to get value memory usage per layout, no at all. Anyway Thanks for clearing.

Aphrodite Talking about composing, maybe it helps but sometimes I did it in the past, could not use compose again because it would require a lot of non-animated objects on screen would degrade performance because C2 engine doesn't have culling object, however it's only for decorations because It doesn't explain about a big background like curved road and landscape without decorations, if we do slice sprites over this big background, well it doesn't make a difference as you say it's not worth the effort, I don't have idea what's another solution that it will be better. So what's another solution?

Mention to PS, I never thought like that, since when I did like that?

As long as you avoid large images where its not required, you are doing nearly all that you can.

ie. Avoiding making something larger than power of 2 rule, since it will waste double the required ram in texture.

A 512 x 10 object may be 10kB as a filesize, but in texture, its 512 x 512 x 4 = 1MB memory

— one big sprite with some color palettes will have 10 mb of memory, then a pack of 30 sliced sprites from big sprite will have same memory 10 mb.

I have another project uses 2 or 4 colors, C2 says it uses 1.5 mb memory usage, then it's on preview using chrome, it uses less than 5 mb of memory.

I was wondering if I make an another project without sprites, I use text and set as ImageMemoryusage expresssion, then started to run and it says 9.68 mb of memory by a plain white background, that's odd.

If you look at the rayman origins example on this post, I think the point is clear:

https://www.scirra.com/blog/112/remembe ... our-memory

Captain Well, look at these big trees, mountain, grassland and landscape in background. These are points that I'm using different backgrounds each level that don't use a lot of decorations.

— one big sprite with some color palettes will have 10 mb of memory, then a pack of 30 sliced sprites from big sprite will have same memory 10 mb.

I have another project uses 2 or 4 colors, C2 says it uses 1.5 mb memory usage, then it's on preview using chrome, it uses less than 5 mb of memory.

I was wondering if I make an another project without sprites, I use text and set as ImageMemoryusage expresssion, then started to run and it says 9.68 mb of memory by a plain white background, that's odd.

I think C2 adds by default twice the rendering area to this expression, I am not entirely sure though, but that ciuld explain it.

And for the PS, I was extrapolating, I know you aren't like that, was just constating that some points could be clearer, since a lot of people misinterprets them sometimes, not towards you.

Splitting up large pieces of artwork will not help at all - in fact it could end up using more memory and causing problems with seams.

The blog post is advising to use the same technique as Rayman Origins. Despite being a beautiful game, it does not use any large pre-rendered images like you have: it's entirely built out of smaller images. That is a far better way to design games. With the single large piece of artwork in your post, there is nothing you can do, it is simply going to use lots of memory, and you can't reuse it anywhere, so the temptation will be to continue using more and more large images until you completely run out of memory. A game like Rayman Origins on the other hand can keep going with huge levels reusing the same images without using more memory.

Ashley Is difficult to implement culling objects as when the objects are offscreen, then get destroyed, otherwise when a player is on specificed position according to scroll, recreate objects with current instance variables?

Joannesalfa - no, the only problem is image memory, and all images for the layout are loaded at the start of the layout. We can't really load images half-way through a layout, because it will pause the game (e.g. for 500ms while the image is decompressed and sent to the GPU) making the game very jumpy.

So if we want to use big images, don't care about slight pauses, but care about memory usage (say, if we're making a hidden object game, point and click or RPG), we either use a separate layout or "load image from URL"?

I would strongly recommend you simply do not use big images. As the blog post mentioned, professionally-designed games don't do that.

I would strongly recommend you simply do not use big images. As the blog post mentioned, professionally-designed games don't do that.

Is it possible to replace sprite image using ajax on mobile with the technology that we are using?

Edit@ Also, it's a bit off topic, but what's the average load of the images in the background on desktops? Cheers