How do you usually solve the problem of using the right assets for multiple resolutions?


Just wondering how people go about solving issues like using different assets when supporting multiple resolutions, such as in an iOS Universal application?

I’ve been using a class that resolves image paths, scales positions and movement, but I’m not crazy about this solution and was wondering if someone is doing this in a nicer way?

Marco Lopes

1 Like

I’m using vector graphics. I scale them to fit the screen and then draw them on to bitmaps. Application size is smaller this way but loading times are longer.

You shouldn’t scale position/movement on an individual basis. In-game distance should be equal on all devices, regardless of screen size; if the world is 500 units wide on your computer, it should be 500 units wide on a high-resolution tablet, and on the smallest smartphone around.

To accomplish this, scale the Sprite that contains the game world, rather than scaling the individual pieces of the world.

The only reason to scale the individual pieces is to account for resolution. If you select a high-resolution bitmap, scale it down until it takes up the correct amount of game-world space. Likewise, if you select a low-resolution bitmap, scale it up.

Isn’t scaling bitmaps going to cause performance, and loss of quality issues? The only reason I’m scaling positions and movement is to avoid quality loss, and eventually performance degradation, when resizing raster images, which basically all the graphics in my game are.

Well, yeah, if you want high-performance rendering, scaled bitmaps aren’t what you’re looking for. hcwdikk’s solution would work better, but what you really want to use is Tilesheet. This will allow you to do the equivalent of scaling your bitmaps without the performance penalty.

There’s also the Tilelayer library, which makes Tilesheet easier to use. It allegedly improves on Tilesheet’s performance in some cases, but it hasn’t been updated in years, so who knows if that’s still true.

Interesting, I’ll definitely try to do some more Tilesheet trickery in my next game, this one is too close to ready, already to play around with it .I’m using Tilesheet already in some places anyway, but I’m probably not getting all the benefits out of it, since I’m also loading differently sized spritesheet assets, to avoid quality loss.

Yeah, one of the most important things to do in terms of performance is to put everything in the same Tilesheet object.

This is because Tilesheet uses OpenGL, and in OpenGL it’s important to reduce draw() calls as much as possible, which means combining as many things as possible into the same texture.

This one also looks like an interesting way to manage spritesheets, and is simple enough that it won’t get outdated unless the JSON format used by TexturePacker changes:

Would that still apply for large or large(ish) images such as level backgrounds that are bigger than the screen size, or even just the screen size? In such a case spritesheets can easily get huge, if they contain backgrounds for multiple levels.

Is this still true in OpenFl 3.x? I was looking at the code and it uses beginBitmapFill, which I’m not sure how it works.

You could probably draw the level background separately if texture size becomes a problem.

I assume the Graphics class uses OpenGL, at least on native targets. It doesn’t in Flash, but that isn’t under OpenFL’s control. (It’s also why Tilelayer uses regular bitmaps on that platform.)

For a game I’m making I’ve got a (semi) working solution that takes an SWF with all my vector assets, then on game load it scales them depending on the device DPI and packs them into a texture atlas that I then use with Tilesheet. The reason I say semi is because its full of bugs, but it does work (and seems to be pretty quick, no noticeable lag on startup on Windows or Android). Eventually I’ll get round to making it save the generated atlas locally so it won’t have to be generated each time the app starts.

Although it’s not what I used, there’s a runtime implementation for starling that might be worth looking at if you end up going down this route;

I considered something like that, having a spritesheet with all the game assets in the highest resolution, and then generating the smaller sizes in run time, and caching them in disk, not sure if it’s a good idea yet, still giving it a thought.