koobas.hobune.stream
Epic slow android build time, lots of Read/Write enabled sprites!
I am experiencing super duper slow build time (like ten minutes or so, which in comparison to my past experiences is super slow) when I am trying to test builds on my android. See the thing is I need 8 separate 2048 x 2048 sprites, which 4 of those sprites are read/write enabled (doubling size) allowing my game to do the things it needs to do.
When I am at the stages "Compiling all assets into archive..." and "Building target package..." is where the slowness comes in.
These textures are RGBA32 with read/write on half of them remember... so yes there is quite a bit of stuff to get loaded into the package... but really? ten minutes? There must be something I can do to speed it up! I can't sacrifice texture quality (lower res/smaller textures) and I can't sacrifice read/write (need to edit textures at runtime) so what are my options? Deal with it? I hope that isn't my only option... I have read some Answers on here (and unanswered problems) where users suggest things like changing the one file in unitys install folder to use different compression... would this apply to me? or is having those read/write textures gonna kill it regardless? Any pro's out there with insight on this?
Perhaps there's a way to compile/build these parts and retain them, assu$$anonymous$$g they aren't to change. $$anonymous$$aybe exporting to Google Project and working some magic in Eclipse.
If you built the packages in a separate project you could reference/load them with the main game project and only need to re-build that portion. The trick on Android to data sharing between projects its to build them with the same $$anonymous$$ey, apparently.
Hmmm I'd have no idea where to start! Haven't messed with Eclipse yet... Interesting suggestion though
Couple other notes: The images are PSD format, so my guess is they are converted through to ETC or something for android... would that be correct? Is it possible unity fires up a Photoshop process, auto exports to PNG or something, then converts back to ETC or something???
EDIT: oh you can do that? (in response to the second part of your comment) Hmm so that would allow me to build out the textures like they would be each time through (assu$$anonymous$$g they aren't changed) and then rather than load them again, reference to them in another project folder with the same key? I might look into this but I imagine that is not as easy as you make it sound haha!
I think that depends on the compression settings. But yes, you do need to face it to some degree that larger textures use a lot more RA$$anonymous$$ to process.
Sorry to keep picking... 'saved them as PNG'. Im trying to gather whether you actually exported or simply saved under a new extension :P Apologies; got to check these things.
Best thing I could do to improve it (only about 15-30 percent or so, but hey!) was to change my background textures all to be ETC 8, though I can't figure out a way around using rgba32 for the ones I edit at runtime since they require alpha, and they need read/write enabled so those both are heavy on compiling assets stage. Still the average build time to android will be at least 3 and a half minutes or so - which is better than the 6-10 minutes it might have taken on different texture format for the background textures.
It's worth mentioning that changing from PSD files to PNG files made no difference whatsoever it appeared from my testing!
