[Performance Question] Rendering on mobile

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.

Ashley Pause the game for 500 ms is not big deal until if it breaks the game. In that case the AAA game is called Skyrim rarely pauses the game like max. 15 seconds.

I would consider to use composition to design levels, I hope it would decrease memory usage, I'm curious so what happens when memory usage is on limit?

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"?

You can use big images, it just eats up your quota for memory much faster. Using individual smaller object sprites to form a scene is more useful in that you can re-use them in different forms and combinations to make varied scenery but at a smaller memory footprint.

As for the image sizes and breaking them up, you wont save much on memory breaking one large image into quadrants etc. But certain images if you do it smarter, you can save a lot of memory.

Let's say you want to drawl a line, it's 1200 pixels long and 20 pixels tall. You think because the sprite is small, it wont use much memory but its false. Into texture, such a sprite will occupy 2048 x 2048 texture memory or 16MB of ram. Why? Because its too wide (1200px) for the next texture down, 1024 x 1024 so it has to go into the next texture size up, by power of 2. These are optimizations you have to do when you work with mobiles. Never have an image like that, since its wasting so much ram.

But surely there are scenarios where a big image has to be used, and you cannot compose, right?

Visual novels, for instance, are full of huge backgrounds, and even the characters can be huge. I mean look at this thing:

It's immediately obvious that the background cannot be "composed".

Surely as long as we only have one big background per scene, we're fine?

Keep in mind performance isn't all that critical in that sort of game, the developer would be much more concerned with battery drain, music smoothness and text drawing.

So my guess is that since construct 2 doesn't redraw when nothing on the screen has changed, the framerate would be kept high. The only problem is that people like to implement that "typewriter effect" on the text, so it might count as constant redrawing - Ashley would c2 be smart enough to only redraw the bottom half of the screen?

Fimbul

There is no problem witha game like that. honestly you can probably get away with 5FPS and the user probably won't notice.

Canvas and WebGL rendering doesn't work like that. You can't just draw on the bottom part of the screen and then hope to leave the top half. Techniques like that exists 20 years ago, but today rendering is just done whole screen. it's easier.

The problem is, if I'm getting 5fps in a mobile, that means the device is doing a ton of work.

True, the user probably doesn't care, but his battery will notice for sure. Especially since this is a visual novel, so it's supposed to be experienced in long stretches.

Also, just throwing this out there, if the most frequent bottleneck on mobiles is fill rate, why not limit the redrawing to only the parts that change? Yes it's impossible in some types of games, and yes you get a bigger hit on the CPU, but on the other hand the GPU will have less work to do.

The problem is, if I'm getting 5fps in a mobile, that means the device is doing a ton of work.

True, the user probably doesn't care, but his battery will notice for sure. Especially since this is a visual novel, so it's supposed to be experienced in long stretches.

Also, just throwing this out there, if the most frequent bottleneck on mobiles is fill rate, why not limit the redrawing to only the parts that change? Yes it's impossible in some types of games, and yes you get a bigger hit on the CPU, but on the other hand the GPU will have less work to do.

EDIT: I wonder if drawing this picture into a separate canvas (through the canvas plugin) would mean that the canvas itself would not be redraw on screen, and so help for that.

The text changes.

The text changes.

I edited my post just after posting it, but it was too late:

I meant drawing this picture into a separate canvas.

Fimbul, what device are you testing on? If you're remaking that screenshot, there's a lot of overdraw going on, as remember even fully transparent pixels in a texture are still drawn by the gpu, and semi-transparent ones take a lot more work to draw, so you might try making the text background fully opaque. Also, are you using normal text or sprite text? I seem to recall some people talking about normal text having worse performance. Otherwise, the only ideas I have are to check your CPU use, or as mentioned, pasting everything except the text to an instance of the canvas or paster object.

The screen uses more battery than the CPU or GPU in modern phones, so even if the game is inefficient it will be less important than simply how long the user has their screen on and its brightness level.

Only redrawing small sections of the screen is surprisingly complicated to implement properly, and will actually involve a fair amount of CPU work to correctly calculate the changed region. GPUs are often so fast that it could actually be slower in some cases than just redrawing the whole screen anyway. Simple approaches are often fast ones.

But surely there are scenarios where a big image has to be used, and you cannot compose, right?

Under such a scenario, even a weak mobile will run your game at 40fps+, try it, make a quick background and one character sprite and updating SpriteFont, compile and test on your device. Should be silk smooth with the text update.

The only problem is multiple pictures like that compiled with CocoonJS will destroy even modern devices in terms of memory usage. CocoonJS loads ALL your graphics into memory on startup, even if you do not require it on your current layout. It's the bane for larger games.

But if you do it, use Intel XDK, it will only load the assets required for that one layout. So such a scene, with a 720p background, a large sprite etc, wouldn't take more than 50mb of ram. It then frees the ram when you change layout into a another scene.

I drew about 30 different 720p backgrounds for my Ninja Legacy (first) game, since I was clueless about good game design and about CJS's inability to handle layout loading... I ended up using about 11 BGs only and cut back on character animation frames. Still, the game used 450MB of ram with CJS. Same game with Crosswalk/XDK, only 240MB peak in a busy scene with lots of enemies.

— Did you try Crosswalk? does it load partial memory for one layout?

EDIT: I'm curiosity about the sprites, if a sprite has more than 20 animations does it affect memory usage?

This sprite has 20 animations each 5 animations are used for color, eg. 5 are blue, 5 are red, etc.

Is recommended to create new object as sprites with 5 animations instead of 20 animations?

Is recommended to create new object as sprites with 5 animations instead of 20 animations?

No. It's more efficient to fill a single spritesheet instead of splitting your animations between more objects.

This blog post may clear your doubts.

https://www.scirra.com/blog/87/under-the-hood-spritesheets-in-construct-2

Joannesalfa Definitely Crosswalk/XDK does layout-per-layout loading of art into memory. The difference in startup times and memory usage is massive. My big game with CJS took 40 seconds to load even on beefy devices, uses 450mb of ram. On Crosswalk, takes about 10 seconds to load, uses 240mb ram.