0
\$\begingroup\$

I am currently working on a 2D game for Android. All of the images that I render were created as SVG's and then exported to PNG's which I have placed in my assets directory. These images are also all sprites that I render using a sprite batcher.

My question is around using different versions of the sprites for devices with different densities. I know that when developing a traditional android app you could place separate directories for separate density levels inside of res and then place the correctly sized versions of the images in question in these sub-directories of res.

What is a good approach when dealing with sprite images in the asset directory? Should I just have one copy of the sprites at a really high density / resolution that I use for everything and I just render them on a coordinate system that is independent of screen size or should I resize the image based on screen density before I process it to create all my texture regions? Or is there another solution entirely?

Currently I have one high resolution set of sprites that I use for everything, it just seems wasteful and inefficient for the lower density devices.

\$\endgroup\$

2 Answers 2

Reset to default
2
\$\begingroup\$

After having used multiple asset resolutions on a couple of projects it has proven to be fairly painful in the long run to work with, even though it's usually just running a batch script. More complex support and build processes when updating slow down iteration.

The growing range of aspect ratios and resolutions makes the process questionable. Code that relies on detecting certain resolutions becomes more and more prone to needing rework. Most recently the 'retina' resolutions of iOS caused nearly a week's worth of restructuring to update an old game, since the old code had not considered such an eventuality.

I would recommend keeping your current line of using the highest resolution set only. If performance is a problem, perhaps generating scaled down versions of the assets could be handled on initialization.

\$\endgroup\$
3
  • 1
    \$\begingroup\$ Fun example of how even the big developers make ugly shortcuts when aspect ratio is concerned... toucharcade.com/2014/02/06/final-fantasy-iii-for-iphone-updated \$\endgroup\$ Commented Feb 6, 2014 at 22:57
  • \$\begingroup\$ thanks for the advice (+1 for this). I had used this approach until very recently when I started to get users reporting out of memory issues. So I decided to provide lower resolution images for older devices and I decide which "quality" of images I am going to be using on startup based on the available memory that the device has, not actually on the screen resolution. That seems to have sorted out all reported issues thus far. \$\endgroup\$ Commented May 1, 2014 at 16:49
  • \$\begingroup\$ oh and btw thanks for the link, it was very interesting \$\endgroup\$ Commented May 1, 2014 at 16:53
1
\$\begingroup\$

Even though it does require more work and a little bit of thought, I think it does add value to your game.

I personally use two resolution sets - one for all resolutions above some threshold and one for all below it. Then I use an initialization class which takes care of setting up the correct file names based on the current device's resolution. My rendering is then performed to a non-screen size dependent coordinate system which is also setup in the initialization class based on the aspect ratio of the device.

Doing it this way means that even if future devices require increased resolution, or I want to make changes to my current assets, I only have to change one class to affect all my graphics.

Going through the trouble of doing this depends largely on your game and intended audience. But since android has a very large group of low end devices I think it is worth the trouble, especially if you find in testing that your game performs poorly on low end devices using high resolution assets.

This will also future proof your game and allow you to fairly easily "upgrade" it for higher resolution devices as they become available. Most current devices target HD/1080p, but with UHD/2160p/4K becoming all the rage it is just a matter of time before devices support these resolutions. Graphics designed for 1080p will need to be scaled up to twice their original size to render to these devices, so adding native support for UHD could dramatically increase your visual quality.

\$\endgroup\$
3
  • \$\begingroup\$ thanks for your suggestion (+1 for this). I have tried to use the single set of images approach up until now but due to my users reporting out of memory issues on older devices, I have opted to do something very similar to what you suggested. My implementation is not exactly the same as yours but it is based on the same overall approach of having two sets of images, etc. I have actually used the device's available memory to determine which set of images to use instead of the screen resolution. This seems to be working well so far. \$\endgroup\$ Commented May 1, 2014 at 16:52
  • \$\begingroup\$ after getting to know how to handle texture issues a bit better I have found that this is actually not the approach that worked best for me. I used texture compression (ETC1) and quantization (pngquant) to sort out my memory-related issues and now I have only one set of high res images and everything is working like a charm. Your solution is still valid and helped me at one point so I have still +1'd it, but I have decided to accept @karmington's answer instead since it is more aligned to the solution that is working best for me currently. \$\endgroup\$ Commented Jun 14, 2014 at 0:32
  • 1
    \$\begingroup\$ While it is a lot easier that way, I personally prefer the quality improvement you get with manually creating different size assets instead of relying on automatic resizing and texture filters - especially on lower resolution devices, where important details can be lost. Performance is another factor on low end devices. But in the end I think it greatly depends on the type of graphics you use and there really is no "one size fits all" solution - use whatever works best for you :) \$\endgroup\$ Commented Jun 14, 2014 at 7:27

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.