Large sprites, tiled backgrounds, and performance

I have been working on a game and found that it was randomly crashing on iOS with cocoonJS. After a bit of work and emailed to an from Ludei they told me what the problem was. My game was using all the memory.

My sprites were way too big. We have a lot of detail done on large backgrounds so the tiled background option wasn't really feasible. Also, when I started working on the game, directCanvas from appMobi was just launched and that didn't support tiled background at all. Which in turn caused me to use sprites for everything.

At one stage I tried to cut up some of the larger images to see if it would improve performance, but it didn't. Little did I know that it actually had.

So now I am at a situation where I am going to chop up my images and manually tile them. But I have some questions that hopefully someone with some more technical knowledge can tell me.

Does tiled background perform the same as a sprite if there is only one "tile"? Or is it stll faster?

Is there a plugin to easily tile images?

How small should should my tiles be? 256 x 256, 512 x 512, or could I get away with bigger? My background is approx 3072 x 1024.

I don't mean to be lazy and not search the forum - I have actually done some searching and reading, but I was hoping to get feedback from people who have come to the same situation.

Thanks

Tiled background is exactly the same as drawing a sprite if it only shows a single tile. However it is vastly more efficient at drawing large areas of tiles.

Mobile devices have much more limited resources than desktops. It does not matter which engine or exporter you use if you have lots of large images - you will simply run out of device memory. You just have to design your game differently. The maximum tile size supported is 2048x2048 but bear in mind each tile that big will use about 16mb of memory.

Thanks for the feedback Ash, if I cut a 2048 x 2048 image into 16 of 512 x 512 slices, would it then be better?

Is there another way to create a large type of layout? Or would it be best to try and flatten whatever I can into single images instead of layering?

3072 x 1024 is a large background. If large portions of your background aren't shown on the screen at all times, then you could save memory by having tiles sized small enough so off-screen portions of the background won't be drawn.

If your game background is large to be scaled down to fit on-screen, then you should consider lowering your resolution. Third generation iPads are only 2048 x 1536.

Cutting up large images does nothing performance wise, if the same pixels end up on the screen, except maybe make it a little slower.

You should not design layouts as large single images. Make each part of the background a separate object (and a tiled background wherever possible) and build your background out of those objects. This will consume vastly less memory and allow for significantly larger levels.

Thanks guys.

Ok, so what ever is drawn on the screen is what is in memory. If I have an image that is larger than the screen resolution the entire image is put into memory even though only a portion of it is drawn. Is this correct?

Just a side note. My window size is 960x720, but the layout is the big one.

The whole game is in the memory.

— is right, it's not just on-screen objects that are in memory. The entire project is in memory, even off-screen images, and even images on different layouts.

superkew

Optimization is a problem no matter which platform you choose, and gamedevs and artists are constantly trying to replicate, stretch and re-export the assets to make sure their project stays in the performance limits.

Take for example the gorgeous Rayman: Origins, or Braid. They look absolutely gorgeous, yet it's possible to achieve those results without a single 2048x2048 texture! Play (or watch videos) of these games, and study how they did it! :D

Some nice reference videos for you:

Braid level editor

Ashley I thought the assets were unloaded when entering a new layout. Time to simplify my main menu I guess :P

superkew

Try to design your levels using modular parts that can be re-used and combined to construct the scene. By using instances instead of new objects the memory usage can be significantly reduced.

You can also upscale low detail images in the editor (like background gradients) to fill a big area without compromising memory usage or quality. The key is to find the balance between re-usability and variation.

Don't forget in hardware accelerated platforms (most desktop browsers, and CocoonJS/directCanvas on mobile), scale and rotation of objects can be rendered virtually the same speed as unrotated unscaled objects. This means you can use loads of scaling and rotation to keep the same few sprites looking interesting. It's one of the technique Braid and Aquaria also use to make a visually interesting level out of a handful of sprites.

Thanks for all the helpful feedback guys. I re-use a lot of assets with scale and rotation, but there are some things that I can't seem to really reduce.

I'll chat to the designer and see if she has some ideas.

Would it be possible, do you think, in future releases to have a tile compiler of some sort.

I've only just started using C2 so forgive me if this is already in there. But I do have a lot of experience of tile based systems from working on GBA games.

Currently C2 is good at large areas made out of repeating tiles. What it doesn't seem to be able to do is to cope with a level made out of a small tileset like the one in tiles.png in the Jungle Platformer example - which I think is 64*64 tiles. I could make a huge and very varied image out of that which could then be stored in memory as the tileset and a map referencing it. Do we have that? Could we have that? It is the best way to make 2D games of this sort.

Hm, I've been considering to make a plugin that would allow one to freely render a given texture. It'd work kinda like this:

• single texture / image
• you have full control over how you want to render it; fully, partially, whatever
• every tick, the plugin would collect instructions and then execute them in one go

So it could be used as a tileset, texture atlas, etc. Control animations, tiling and such yourself. However, those would be textures only, not objects like individual sprites. They won't have any UID, variables, properties, behaviors etc. They're just textures and it is up to you how you draw them.

I'm not sure if there'd be much performance boost, as Construct 2 already optimizes rendering routine. It would just be an alternative to sprites and tiled backgrounds, if all you need is a texture that you can abuse.

Would there be an interest?