Best approach for different screen sizes?
Monkey Forums/Monkey Programming/Best approach for different screen sizes?
| ||
| I'm sure this has been asked before, but I'm looking to start messing around with different devices and I'm wondering what's the best practice for coping with the variety of screen sizes. In terms of performance, is it best to adapt your code to a few selected sizes, or is it ok to use scaling, something along the lines of the autofit demo from the Monkey examples? The autofit idea seems ideal since it copes with any screen size, but would it have a large impact on performance? |
| ||
| I suspect the main issue is how you want the graphics to look, rather than performance. The reason I say this is because these devices are probably designed with the expectation of a lot of scaling, and thus are unlikely to suffer too much pain from it. But it's just a guess. That said, if you can design the layout so that a few graphic sizes will work well on any screen size (within reason), you have the advantage of pixel perfection plus any bonus there might be from avoiding scaling. Maybe people with real devices have done experiments on the cost of scaling? |
| ||
| I'm biased, but if you do end up using AutoFit, please use the newer version here as it fixes some stupid stuff... |
| ||
| Thanks DB. I was thinking about this last night and was about to start working on my own scaling when I remembered your demo, played around with it and realised it does everything I wanted anyway. Thanks for the update. Any idea about the performance hit? |
| ||
| Glad you linked me the new update, there was some kind of error in the old version where it wasn't scaling properly when I resized the window. Couldn't fathom out what was wrong - thought it was my code, but I've just used the new version and it's scaling perfectly :) |
| ||
| I've never done any speed comparisons, but I can't imagine there's much of a performance hit. (There are certainly no visible changes to the framerate on anything I've tried.) |
| ||
| One thing I noticed that autofit and scaling the screens you have to deal with different ratios on screens On more modern devices, the screens are wider and leave an unprofessional black bar at the bottom of the game. To combat this, I did a mixture and kept to the scaled gfx for easiness, but when gaps were detected it would reposiiton the play area, scores, ads and titles so that it would fill the whole screen |
| ||
| Is there a 'best' screen size to use, which fits most devices nicely? Or to word it a different way, what screen size would people recommend I start with? Right now I don't even have an Android device (working on it, my current phone contract is a bit... annoying), so I'm starting a new game idea using HTML5. A book I read suggested 480 x 800 (I assume that's common for a phone held upright?). |
| ||
| This is a good read: http://developer.android.com/guide/practices/screens_support.html |
| ||
| Cheers, that'll help a lot. Am I right in saying that I'm also best to avoid creating and destroying objects on the fly? For example, I'm doing a basic shooter - for the bullets, am I best to create say, 50 bullets at the start, and just re-use those over and over? Or even use arrays? I think I read somewhere that lots of creating and destroying objects has a real hit on performance? |
| ||
| Yes, pooling your objects it nearly always a good idea (for games on speed limited devices). You can use arrays if you are smart about it. I used answer one from here as my model: http://stackoverflow.com/questions/2152607/collection-with-fast-removal-iteration-insertion-that-recycles-objects-in-androi |
| ||
| Cheers. Having programmed since the days of the Spectrum, I don't mind this old-style messy programming. Infact, sometimes I prefer it, at least I know what's going on, which I can't say I do half the time with OOP xD |
| ||
| On more modern devices, the screens are wider and leave an unprofessional black bar at the bottom of the game Actually, that's what it's meant to do (though the black bars should be at top and bottom), to allow targeting of one aspect ratio but running on any aspect ratio -- like DVDs on different TVs, etc. I guess not everyone likes that solution, but it's something you would have to hard-code otherwise, filling in the extra space manually as you suggested. EDIT: Hang on, if your game targets a narrow ratio (eg. 4:3) and it's running on a wider-ratio device (eg. 16:9) then you should have black bars at either side, not at the bottom. Black bars should appear above and below in the reverse case, ie. widescreen game on narrow device. |
   |