So in my previous game I decided to have assets for multiple resolutions, but ended up with a huge application file. It was also a problem as OpenFL didn’t use to allow choosing a resolution for full screen in desktop targets (think that has been fixed now, but my game was stuck with an older version because of the disappearance of the Tilesheet which I was heavily relying on), so it basically meant I couldn’t release for desktop unless I used windowed mode only.
I tried using scaling but the image quality dropped dramatically, and that’s why I went with assets for each resolution I supported.
How is everyone else solving this problem? I see there are games with supporting multiple resolutions without so many assets, and even games that are on steam (desktop fullscreen), so someone must have solved this problem before.
What am I missing?
Thanks. I don’t use 3D or vector images, I’ve tried scaling down, it wasn’t amazing, but as I said, I’ve been using an old version of OpenFL. I’ll definitely do scaling for my next game.
How many resolutions were you using, anyway? Personally, I use three, pick whichever is closest to fitting the window size, and then scale it up or down a bit. Obviously it doesn’t look perfect, but it’s good enough.
On the project I’ve just finished, I supported 8 resolutions, created all the assets in high resolution, and then used Texturepacker to create a Spritesheet for each resolution. I’ve seen that 3 resolutions (something like @1x, @2x and @3x) and then scaling approach, before, but I was wondering how it works, because in my experience doing scaleX = scaleY = 0.8 (or any other number), didn’t really look that great, but maybe I’m just being too picky.
This is my approach and for me it’s OK.
So here’s one example of what I’m talking about. On the right the game is running at 960x640, assets resized at run time from 2048x1536. On the left, running at the same resolution, the assets are pre-generated from the 2048x1536 by Texturepacker. I suspect the main problem here is that I should probably have some intermediate size.
What are the 3 sizes people traditionally use?
I’ll experiment that as well and will post the results for comparison.
EDIT I’m doing the scale on the main class, the one that is declared in the project.xml file, which extends Sprite, and doing it by changing scaleX and scaleY. Being very specific in case I’m doing it the wrong way.
Don’t scale rasterized text. If you must scale rasterized text, then you’ll want to set TEXTURE_MIN_FILTER to either LINEAR_MIPMAP_NEAREST or LINEAR_MIPMAP_LINEAR. Note that this will probably impact performance, at least on low-end devices.
But you have better options:
- Embed that font and then use text fields.
- Use vector assets. Inkscape (a free program) will be able to convert your text, or you could use Adobe Animate if you have it. It’s up to you whether you convert anything other than text.
I also always use dynamic text. Scaling from 2048x1536 to 960x640 is too much. Maybe you should have half of 2048x1536 or HD graphic.
Thanks for the tips. I do render the text dynamically, except for those labels. But it’s also noticeable in the circle near the bottom of the image.
@gonzos I do have several resolutions in between (including 1920x1080 aka Full HD), I’m just using 2048x1536 for testing purposes. Before going with the final version, I’ll pick up two more resolutions and will scale down from those. For anything higher than 2048x1536, I guess I’ll have to scale up.
I’m wondering if it’s always preferable to scale down, or if a resolution being closer to a lower one, it would be better to scale up?
well, I always scale it down so I’m not sure for scaling up. But if range is not too big I think it’s OK.
bitmapData.draw helps with software resizing, which looks smooth (like flash). OpenGL linear filtering (
bitmapData.smoothing = true) doesnt perform well for big scale changes, so recreating a smaller bitmapData at runtime can help