Scaling to different devices
Monkey Forums/Monkey Programming/Scaling to different devices
| ||
| What's the best solution you guys have got to scaling your games to different device screen sizes. My game runs perfectly to the standard HTML5/Flash screen size and also to big Android devices (HTC One/S4/etc) but any smaller screen sizes I struggle with, what solution do most of you use to fix this? |
| ||
| Have a search for the all mighty Autofit ;) |
| ||
| I guess you've discovered autofit? |
| ||
| autofit will scale fine when the devices have the same aspect ratio, but you will have to supply other images or use large images and draw them offset to fit other ratios without black bars. |
| ||
| Just give autofit a try and i'm confused because all the images show bunched up in the corner of the screen but the transparent touch boxes i've created show up in the correct place. I really can't understand how this has happened. |
| ||
| @richb: Autofit it is perfect if you make a game for a specific resolution. It will automatically scale all the images to fit the current screen. Of course if you design the app to run on a 4:3 screen, on a wide one will have some black bars. regarding your issue, maybe you should show us a code to see what is happening. |
| ||
| I'm using the AutoFit implementation thats built into Diddy which I think is the main autofit, and it's got a bool that you can turn on or off that toggles those black bars, so im sure the main solo autofit module will have the same thing. |
| ||
| What does it put instead of the black bars, does it stretch the image or something? |
| ||
| Well personally I use some flow layout. I know both extremes which is the aspect ratio of the iPad (3:2) and phones (which can be up to 16:9). So I have a fixed area and a floating one. That way it always fits perfectly. |
| ||
| rIKmAN is stretches out to fit the screen. I like the idea of that flow technique, to be honest up until a few days ago when I got my first Android phone I had never needed to worry about resolutions, I simply designed for the one I wanted, and hard coded everything for it. But Android has really opened my eye's to making things fit, as a result from now on I will be building my games with an Aspect Ratio in mind, and not an actual fixed resolution, so when I start my next full project I will design it for either 4:3 or 16:9 either of these should then scale and stretch nicely into the others that exist. that being said, my little test android project Bit-Invaders was done in 4:3(640*480) and it fits well on an android tablet and my phone so either way i'm happy. |
| ||
| Woo Finally sorted it!!! just have to go through and hard code all of the Height and Width variables haha. |
| ||
| @Taiphoz That doesn't sound right to me, if I use a 960x640 background (iPhone Retina) and run it on an iPad (1024x768) then autofit will scale with black bars to keep the aspect ratio (and vice versa) If it stretches the image to remove the black bars won't that just stretch and distort the image to an aspect ratio it wasn't made for, and look really ugly I'm probably being stupid, but I can't get my head round what you mean. |
| ||
| it does stretch but as long as the distortion between one aspect and the other is not to high then its all good. Currently when I test Bit-Invaders on my mobile or tablet it looks nice, without knowing before hand that it's actually designed in 640*480 you would'nt really notice. I am sure that the type of graphics being used might help this or hinder it, something that's easily recognizable might be easier to spot when in an aspect ratio its not designed for, but at least for me for the moment thats not an issue. The worst case scenario is that I simply toggle the stretch flag back to true and the aspect ratio flips on and I get a few borders, its really not that big a deal. I suppose there is also nothing really stopping you from designing your game with two aspect ratios in mind, and then rendering things based on the current ratio being used. |
| ||
 Here is one of my projects with the Aspect on and off. its clear when they are both right next to each other, but when the user does not see the other version with borders they have no clue, the game does not look any worse as a result. I apologize for the crappy quality on the pic, had to take the photo with the iPad and its low light in this room at the moment . |
| ||
| Yeah I'm developing for 2 aspect ratios at the moment, with different graphics depending if its an iPhone / iPad. It's only the full screen backgrounds though as the other graphics look fine (just a bit smaller on iPad apsect ratios which is fine). What is the flag to enable/disable the bars? I'm not at home at the mo so can't check the source, but I'll give it a try and see how it looks. |
| ||
| Well I use Diddy, which has AutoFit built in, so I simply call SetScreenSize(640, 480, true) or False depending on what I want. Not sure what normal auto fit has in terms of exposed methods you would have to go look at the module source. |
| ||
| If you fiddle with the impossible-to-explain zoomborders/keepborders parameters of UpdateVirtualDisplay you can retain the aspect ratio and zoom in a bit to lose the borders. Eg. Download AutoFit from here and modify autofitdemo.monkey so the UpdateVirtualDisplay call reads: UpdateVirtualDisplay True, False If you zoom to x1.2 (or, better, call SetVirtualZoom 1.2 in OnCreate) in the demo, then it fits correctly and maintains the aspect ratio. (The 1.2 appears to relate to VirtualDisplay.Display.dratio divided by VirtualDisplay.Display.vratio, which are private fields, but there's nothing to stop you exposing them if this is what you're after -- just comment out the Private!) Of course, there are downsides, such as blurry pixels (depending on target/image filtering settings) and the loss of the outer edges or top/bottom edges, depending on the conflicting aspect ratios, but many games wouldn't be affected by this. ... but there's no one-size-fits-all answer to all this! I do keep meaning to update it to allow the drawing of an image/set of images into the borders, but it got really tricky last time I tried... (BTW If anyone's using the version that comes with Monkey, PLEASE ditch it for the above!) |
| ||
| I think keepborders = False meant that the borders effectively got zoomed outwards as you zoomed in (True meant they stayed the same size no matter what), and that parameter only had an effect when zoomborders was True. Like I said, hard to explain! |
| ||
| Great info thanks James (and Taiphoz), and I agree there is no "one size fits all" quick fix. I shall have a play when I'm back at my computer tomorrow. |
| ||
| One of the most interesting things I've done in the past few months has been a Testcard. It's quite a simplistic one, and there's not a lot to it, but it scales and reforms itself to any given resolution. You can see it in action in most of my recent games, but it's most noticable appearance is in Hoppy Bobby. Simply tap the AGameAWeek logo on the menu, to pop it up. Lots of maths involved. Split the screen into a grid, work out the most grid elements you can fit into the space, line up scaled graphics, work out gradients... There's quite a lot of stuff in there, considering it's not even half a testcard. But it scales, and resizes, and fits snuggly into any given resolution, and does so quite nicely. As far as end-results go, it's quite nice, and a neat little credits-screen. But for a programming challenge, it was quite a good learning experience. Dealing with unknown resolutions, and aspect ratios and combining images with polygons and bitmap fonts.. A good learning challenge. Highly recommended. Go make your own testcard! |
| ||
| Just checked that out, pretty cool. I've also just realised you are Jayenkai from the old BB days :) |
   |