Background Image in a 2D game: problems of size/quality importing. What's the right workflow?

Hi everyone.
I'm posting here by suggestion.

Recap is in bold.

Developing a 2D game we have a large (width) background image which is the result of different drawings merged together.
I've forced the size to be a power of 2 for dxt5 compression (i've just adjusted the canvas size) and the image format is .png: 32768 x 4096. (argh xD)

The resulting imported image in unity is of terrible quality and till now, attempting to change parameters (sprite(2d/ugui), advanced, max size to 4096, etc...) didn't that difference.

Obviously slicing to smaller chunk the original image results in better single ones, but also (predictable) in a total growing size...wich become unbearable for a single image up to 8 mb (about 10 images made the bigger one we're talking about...).


So my question is quite simple:
I don't have a clear idea of a workflow for producing 2D images and use them for a 2D game (especially extended backgrounds).
Do I have to keep the long image approach? or build the background out of several smaller images?

Whichever the case, which is the right approach to import with a satisfying quality/size(Mb)/dimension(width/height)?


thanks in advance

 

There's no catch-all for these scenarios, but I can say for certain that your starting image is far too large and you definitely need to chop it up.

Many older graphics cards can't hold a texture of size greater than 2048 by 2048, for example. Also, as you've already discovered, you get better results if you chop the image down.

Ideally, though, don't just chop it into rectangles. Break it down into background and foreground (well, not-so-background) elements. If they have repeating sections at varying distances, you'll find you can save memory by only storing the one section for each segment and then repeating it in the shader.

You get an additional benefit from this approach of being able to specify the import quality separately for each chunk. This means you might be able to save a load of memory by losing a little quality on the far-background elements, still keeping the foreground elements nice and sharp.

Lastly, if you find that with all of the tweaking you can apply that your background is still too large in memory (though, I wouldn't say 80mb is terrible, given today's standards and depending on what else you have going on), then you might need to rethink your background to introduce some repeating elements, or stream the resources into memory right before they're encountered instead of loading the whole background into memory at startup.

 

I already structured the background images in layers. I've thought that in the aim of given an effect of distance (the more distant the layer the more slower it flows).
This is an old trick and speaking by example, like child of light (a recent one anyway lol), I've noticed it uses an average of 3-5 layers moving at different speeds.
As you say different layers can be managed separately on one hand by setting a different quality for far objects, on the other by reusing component (best example is the sky which can be build from a relatively small bunch of sketches, thing you can't do that easily with the main layer, the one the pg walks on...).

One important thing i forgot to mention is that I have a friend drawing everything, so bg editor and images reuse is possible (and still a must) but the approach will be definitively different.
Anyway as I was replying in the other post (in unity answers and they suggested to post here too XD) is the solution cutting the original image (using photoshop for example) into chunks and then add all of them into different gameobjects that have to be load and unload at a certain time? (for now let's not consider the loading policy, that is how many and when these images should be loaded at startup and after. )
I'm just wondering if I can't tell unity to refer the original image at his native quality as it is on disk and then render just a part of it (by means of an offset).
This should imply to load the entire image into ram and could be another problem.

Probably I'm talking nonsense XD but I just find strange that there isn't a 'mechanized' solution to this (an editor for unity maybe) or a smart way of programming it instead of a cutcut work on an image editor

 

For large playfields like this you should seriously consider using maps and tiles. Check out SpriteTile (for example) in the Asset Store. Map editors and game tilemaps are exactly how this sort of thing is done to have huge worlds using a fraction of the memory used by a gigantic image.

 

I'm no really expert of tiles, but it seems like this approach (sprite tile for ex) is more fit to a different type of game that uses highly repeatable and 'mergeable' images. The most advantage should be a great degree of editing...(further the memory problem).

Relativelty to the thread, this approach just remind me to build the background out of small sprites. (a grid filled with tiles that's the principle?)
Giving that in my case, I have many handmade sketches, and that quality/dimension is a big matter, as reusability is harsher to obtain I'd surely prefer to build a 'full-custom' solution to this XD
I think I'll try to handle this matter in this way:
- I'll find the most professional way to cut a bigger image into several pieces, both on image editor (ps) and/or unity, defining consecutively the max number of sketch sheets (the real ones) I should work at a time.
- I'll manage via scripting all these sprites showing them and shutting them when far away.

Honestly by now I can't figure out more...XD
Any advice and suggestion on this approach would be valuable :O

 

Totally understand you now. Ok, so we're on the same page with:

• Break into chunks per layer that get overlaid at render time.

You state that your second problem is that there's still too much information in RAM at one time. I find this surprising, given how much goes into a 3D game (layers upon layers of textures, etc.) but maybe if this is on a phone or something, this is a reasonable issue. Anyway, you can write a system that defers loading of the sprite object's background at runtime and then:

• Manually carve up the large images, or;
• Create a unity editor plugin that does the carving, naming, saving and dropping of additional objects when you drop in a large object in the editor. (Saving you having to do it).

If I were you, and I was actually facing a memory concern right here and now, then I'd implement the visible-in-editor-but-streamed-at-runtime system first.


Then if I needed to chop the images up and it was more complicated than a photoshop script could do for me, I'd write an editor extension that does the necessaries.

As for the optimum size, this is best tested, though I'd start with half a screen wide and a full screen tall, to balance how often loading occurs and max memory footprint.

 

The information on RAM is more a matter of good programming for me than a real issue. I don't want to build up a system which overwastes resources 'cause "anwyay a medium pc will stand it" XD at least not in a unprofessional fashion XD

As soon as I'll try the scenario I've told you, and your suggestions too, I'll update the thread
Wish me good luck!! XD XD XD

 

Hi ! It's been a while but how did you manage your problem please ?

 

I'm also curious to hear that. We're 5 years late though..

We're making a game which consists of hand drawn backgrounds, where the resolution target is 1920x1080, and a bigger level could consist of a grid of maybe 6x3 images of that size. Is the recommendation to have each slice in 2048x2048 or smaller? I'm thinking that it should work on "normal" phones too.

Thanks