Right now my game is using direct x and y values. I realized that my the S3 was scaling my images double size along with some other size inconsistencies between devices. I read around and learned a bit about android dpi and scaling and stuff.
I'm wondering whats the correct way to do locations and stuff so that it takes into account different screen sizes.
I'm thinking it can be done by setting a target dimension and then scaling all positional values according to the ratio of the target dimension to the actual screen size.
I also read somewhere that you can draw onto a buffer and display that buffer stretched to the screensize, however for this method would android's auto resizing affect the drawn bitmaps?
Thanks
The idea is to use aspect ratio, android auto resizing to your benefit. Every android screen has its own aspect ratio, your game should use the aspect ratio and fill blackborder where ever there is a need to fill space on the screen. So use appropriate root layout fitting attributes.
Android resizes drawables automatically that dont fit. So if you keep only 1 set of drawables, the resizing work for Android increases and it uses Bitmap's internally to do the resize. More the bitmaps more the memory utilization, more the cleanup, more the GC and slower your game. So the best practice here is to create different dpi different image sets to use.
To start with I suggest that you purchase 3 phones, samsung y (small screen), samsung s2 (good screen) and a tab 7 or 10 inch. Copy your original drawables to all the folders, just to get a feel of the game and to eliminate all memory issues. Once your game works nicely, smoothly without any memory issues on all the phone sizes, just walk into a graphic designers office and show him how bad your game looks on some phones. He will create graphics that will work for that dpi.
Its a game of intelligent drawable resolution, sizing and A WHOLE LOAD OF TESTING :).
Hope this has helped.
Edit : Read my answer in memory issues
Related
I currently have a note 4 which has a high resolution screen (2560x1440) that, when playing in the native resolution, doesn't perform well somtimes.
I have found apps on the play store that will allow resolution changes but all require root (at&t version is currently unrootable).
I can however change the density of the screen without root.
I'm curious if I would receive the same performance boost changing density as I would changing resolution?
Highly unlikely.
The resolution defines number of pixels displayed on the screen. When you change the resolution, the system changes the size of all image buffers used for rendering. It means that there is different numer of pixels to shade and draw.
On the other hand there's the density, which define, how much pixels you can fit on one inch of the physical screen. The density changes an internal matrix used for scaling images. The operation is always same. In apps with native Android UI you may gain a small boost, because by changing the density value you can change the density type of your screen (medium, high, xhigh, etc.). This will change the drawable folder used by the app to the (potentially) smaller one, which will result in faster image loading and messed up UI.
This trick won't work for the games, because in most cases games don't care about the drawable folders.
I understand that Andengine gives us option to scale our scene to any size screen that the user may have.
My question is if it would be better to develop for a larger resolution, say 1280/800 and scale it down for smaller screens OR to go for smaller resolution, say 800/480 and scale it up on bigger screens?
I did try to test this in a sample game by developing it for 1280/800 and scaling down (by ratioResolutionPolicy) to 800/480, and the results weren't satisfactory, there was stutter every here and there the framerate on the debugger though showed 60+. Is it bad programming on my part or does it have to do with the scaling down of the pixels, should I develop for smaller screen and scale it up?
I guess it depends on what kind of graphics you are using.
Say, for example, you want to create something in a retro-gameboy-pixel style, then it makes more sense to use small images and develop for a small resolution (like 480x320). Pixel graphics can be scaled up without loosing quality, but not down (then the pixels loose form).
But if you want high resolution graphics you are most likely better of developing the whole thing for a big resolution and let the AndEngine scale it down.
In both cases the quality of the pictures also depends on the TextureOption of your TextureAtlases as well.
Anyway, I can imagine that neither scaling down, nor scaling up is more efficient. Scaling is done by openGL and should go quite quickly. The downside of using big resolutions though, is that the device has to hold huge images in it's memory and the of course processing big images always takes more time than processing small images. So maybe the best way is to develop for middle-size devices (e.g. 960x640) ?
I know this isn't much help, unfortunately it is a lot of try and error to get the best results for your specific requirements.
christoph
To achieve good result on all type of android device you have two ways to follow from my perspective.
First, you have to develop and use two graphics to handle all the type of devices. For example one with resolution 1024x600 and other with 480x320. Based on device current resolution you have to load specific one type of graphics.
Second, you choose any single resolution that best suits to you and have great share in the market. Develop and use graphics only for that resolution. For other resolution scale that graphics based on aspect ratio. For this you have to create super class of sprite and change value of x,y,height and with based on aspect ratio calculate.
This was my experience that I share with you. If you have any doubt then feel free to ask it.
i am NOT an android developer and im trying to understand what they need in terms of graphical resources to make an app that functions across many android devices.
i have (tried to) read this page http://developer.android.com/guide/practices/screens_support.html , but find it somewhat bewildering. they talk as if screen density is the important thing "Supply alternative bitmap drawables for different screen densities" but then, if you dont know the size of the screen, you cant really think in terms of layout. is the idea to make buttons and logos that are the same size on all screens with the same density, such that on a large screen there is just a bunch of space, and on the small screen its all packed in tight? i dont understand how just thinking in pixel density gets me any closer to knowing what to provide.
are you supposed to create resources for every screen size AND pixel density? say it aint so.
anyway can somebody tell me... if you were developing an app what do you need for graphics? is it possible to provide graphics that are large and just let them scale down? is it inevitable that the devloper will have to mess with the graphics himself anyway? or can he be provided with sets of png files of certain sizes that will be ready to use?
thanks!
Here's what we do at my work place. Suppose we get a desing for the app. We make our designer create 3 psds versions for the same desing. the 3 psd's are for the 3 ranges of desnity. The size used for the psd are
240*320 (Low Density)
320*480 (Medium Density)
480*800 (High Density)
Most of the time when I write layouts, I use wrap_content which means a view must take the size of the content it wraps. Which works most of the time as I have a density specific version of the design so the image i use as background should be suitable. The thing to note is that, in android you can can put the 3 sizes of the same image in different folders such as drawable/ldpi, drawable/hdpi.
Eg: you have a bg.png and have a version for large phones and a version for small phones. You put the big bg.png into hdpi folder and the small png in the ldpi folder. Android will automatically select the appropriate image based on the phone density. But you need to make sure the file name is the same.
There are cases where you need to resize you background images without makeing the image looking too scaled. For this android uses the draw9patch tool. With this tool you can specify areas which can scale and areas that shouldn't scale.
9 Patch png's are your friend. Read up on them here:
http://developer.android.com/guide/topics/resources/drawable-resource.html#NinePatch
and here:
http://developer.android.com/guide/developing/tools/draw9patch.html
Those are your best bet for any kind of graphic that will stretch nicely (i.e. not gradients, they will come out slightly pixelated on some screens probably) The power of these types of images is that you can tell the system which pixels to repeat if it needs to stretch the graphic. This means that stretching can be done without loss of image quality (again depending on your image and how you choose to make the nine patch. The "show bad patches" button in the draw9patch program will show you potential problems. Hint: keep your repeatable pixels down to 1 on left and 1 on top and you'll have no problems with bad patches) Any graphics that can be made in to 9 patches will only need 1 size since the system can effectively make it whatever size it needs.
are you supposed to create resources for every screen size AND pixel density?
You may if you like. This would ensure that the application will look great across all devices. I understand that this is not feasible for all projects though. In general if you make separate resources for the different densities you'll get something that looks acceptable on most of the devices out there. All of the devices are classified as ldpi, mdpi, or hdpi (there may be an "extra high" level now too, I am not certain off the top of my head) So if you supply graphics for those 3 densities then the system will know where the device falls under and will pull the correct graphics.
is it possible to provide graphics that are large and just let them scale down?
Yes the system will scale down your graphics if needbe. But be aware there are consequences with this approach. First every time the system hast to scale a graphic up or down it is going to taking up CPU and memory to do so. This may not be an issue if you have relatively few things to scale, but if you have many it could cause noticeable lag time during on the lower power phones. Second, To my knowledge all of the graphics in android are raster, which means if you are letting the system scale something up or down image quality is going to decrease some. Again depending on the specific images this may be more or less noticeable on the actually device at runtime.
My best advice is supply them with resources of a few different sizes and run the app on as many different devices as you can. Once you see how your different resources look on the devices of different sizes you'll have a much better feel for which ones you need to supply to get the UI looking as consistent as possible across the largest swath of screen sizes and densities.
I'm quite new to Android game development (and Android development in general).
My first question came when I was creating the background for my first game: which size should I choose?
If I choose 800x480 for example, will it show good on any other resolutions?
And what about my main character? If I make it move 5px/frame (I already know how to make it fps independent, it's just an example), it's not the same to move 5 pixels on a 320px-width screen than on a 800px-width one.
Any advices on this?
Thanks
You should have separate resource files for each of the screen densities you wish to support.
Pick the background size that's supported natively on the device you plan on developing on, and worry about supporting non-native resolutions or adding resources for other resolutions when you're near the end of the project. Don't get bogged down in the weeds.
As #PaulSonier said, don't worry about supporting multiple resolutions until the end.
For now just develop on one device and use 'dp' or 'dip' units whenever possible. This will make it easier at the end to support multiple screen sizes and densities.
As for the background, consider using 9-patches.
You should have a separate set of graphics for each of the resolutions you want to support. If you really want to cover all the current devices and have the crisp and sharp graphics on every one of those and you want to make sure that the aspect ratio doesn't make your game look weird on some devices, you need to prepare your assets in the following resolutions and scales:
854x600 scale 100%
1024x800 scale 120%
1280x1024 scale 160%
1536x1152 scale 192%
1920x1200 scale 240%
2560x1600 scale 320%
Source: http://bigosaur.com/blog/31-android-resolutions-definite-answer
The best solution is to draw all full-screen images at least 2733x2134 pixels and then scale it down. Well, you can scale down images, if you have text, better to use smaller font size and put it over the image. You can do this at run-time or pre-render the text in advance. You can use ImageMagick to automate all that for 6 different sizes so you don't do it manually.
I've determined an estimate of the size of my Android emulator's screen in pixels, although I think its resolution can be changed to other numbers. Quite frankly though that doesn't eliminate the general problem of not knowing how many pixels on each axis I have to work with on my Android applications in general.
The main problem I'm trying to solve is this: How do I make sure I don't use a faulty resolution on Android applications if I want to keep things' sizes constant (so that if the application screen shrinks, for instances, objects will still show up just as big - there just won't be as many of them being shown) if I wish to do this with a single universal resolution for each program? Failing that, how do I make sure everything's alright if I try to do everything the same way with maybe a few different pre-set resolutions?
Mainly it seems like a relevant question that must be answered before I can come across a complete answer for the general problem is how big can I always make my application in pixels, NOT regarding if and when a user resizes the application's screen to something smaller than the maximum size permitted by the phone and its operating system.
I really want to try to keep this simple. If I were doing this for a modern desktop, for instance, I know that if I design the application with a 800x600 canvas, the user can still shrink the application to the point they're not doing themselves any favors, but at least I can basically count on it working right and not being too big for the monitor or something. Is there such a magic resolution for Android, assuming that I'm designing for API levels 3+ (Android 1.5+)?
Thanks
Hmm, I suggest you read this: Supporting Multiple Screens. That gives a wealth of information on how to handle different screen sizes. In particular, read about its concept of density independent pixels versus absolute pixels. Density independent pixels are essentially pixel sizes that the system automatically scales for you depending on the screen size you're working on. It considers the 'standard' screen as that of the G1, Hero or similar devices, i.e. 480x320 pixels with a density of 160dpi. If the screen you're working with is bigger than that, i.e. the Droid or Nexus One, it adjusts all density independent pixel sizes by 50%.
Alternatively, if you're really talking about canvases, as in, Canvas for animations etc, you can just call canvas.getWidth() and canvas.getHeight().