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.
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.
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.