koobas.hobune.stream
Background Image in a 2D game: problems of size/quality importing. What's the right workflow?
Hi everyone.
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
Unity Forums is a better place for design/discussion questions.
No expert in this area, but to solve a similar problem, I broke things into 2k x 2k chunks and loaded and unloaded them using Resources.Load() and Resources.Unload. In other words, I focused on the memory footprint and did not worry (much) about file footprint.
thanks for the advice :) I'll try to post later on the forums too!
Robertbu has mostly the right answer. You wont get a quality image that large into memory. You'll probably end up with something similar to what my application does with high quality renders of 3d animations. It stores all the frames on disk as .pngs and decompress/load them into memory one at a time. We had to slow our frame rate down to 12 fps on mobile but for our purposes that was acceptable.
In your case you'll probably want to break them up into slices 512 or 1024 in width. Then have some script using Resources.LoadAsync or a WWW request to create a texture out of it as your application requires.
As for your answer: You can go down the path of trying to get quality out of compressed-in-memory formats like dxt and pvr, or you can find efficient ways of getting high quality raw images in/out of memory.
mmm this is still blurry for me XD the slicing operation you're talking about is a 'preprocessing' of the image (I manually cut the background into several pieces for ex with photoshop, and load them at runtime as different objects) or ther's a way to do this in a smoother fashion? like load the entire image as a file with his native quality and then managing his parts one by one?
Technically you could do it all by script at runtime if you wanted to but it might be faster to slice it up manually.
I've transfered the topic on the forums as robertu suggested :)
yep that's what I'm gonna try to find out...XD the workflow I was speaking of :)
