A lot of different questions were asked around the question "How to deal with Textures for different devices in Libgdx". I would like to summarize information here and ask what is not clear for me still.
Tips for the good quality of Textures:
Forget about the approach to build huge Textures with transparency. RAM will be destroyed on low devices. explanation
Use Viewport. Aspect Ratio for Textures will look the same for each device. explanation
Avoid raw textures. Apply the TextureFilter. explanation
Use AssetManager. It allows you to load, dispose, make screen loading progress in the easiest way. example
Use different resolutions for different devices. Use ResolutionFileResolver. It allows Libgdx automatically to choose the most appropriate Texture for each device. example
Note: feel free to add ideas to this list
The question is about the last point. Android platform has a huge amount of different phones and tablets. I understand that it doesn't make sense to create each Texture for each Resolution.
How many resolutions to cover separately? I suppose to take 3 categories: for lower, middle and high devices.
If so - how to choose the most appropriate one for each category?
Are there any cases to use the same Texture somewhere? (small icons, HUD, etc)
Related
So, we're developing a game and the artist asked in what resolution is he supposed to prepare the graphics.
I've done some research
http://developer.android.com/guide/practices/screens_support.html
developer.android.com/about/dashboards/index.html
and from what I gather I should ask him for 1920x1200 resolution graphics, and then
from these I can prepare graphics for lower resolution devices.
That would be a major screw-up if I asked him for wrong resolution art so I want to make sure.
Is that the case ? When he does these 1920x1200 graphics, am I going to be able to produce all the other popular sizes/resolutions with no problem ? My biggest fear are ratio differences.
Thanks.
If clipping isn't a concern, you can use 1920x1200. However, you'll have to do some editing for different aspect ratios, like you guessed.
I would create a large one for each target aspect ratio, if that is your concern. The most common ones are probably 16:9, 15:9, 4:3, but you might want to do some research on what your focus devices are.
If you have one in each aspect ratio, it makes scaling easier. However, the artists I've worked with generally provide me more than that, since a general scale doesn't always look good in a l/mdpi setting. They normally work with vector graphics for the base images, and then can scale to whatever resolution and put it in a raster format. You might want to ask your artist about that, though, since I'm not much of an expert on it. All I know is he sends me pretty pictures in many different resolutions.
All in all, though, aspect ratio isn't very important for most graphics. A fullscreen background, maybe, but all your UI components should be fine with just an mdpi/hdpi/xhdpi version.
Please use larger graphics. The accepted answer is alright for year 2013 when it was posted, but there are devices with 2560x1600 now and graphics don't look sharp and crisp on them.
If you want to support everything properly and make your life easy, ask the artists to supply everything in at least 2733x2134 pixels (for fullscreen images like backgrounds, etc.) You can use smaller sizes for sprites (just calculate which percentage of the screen it would occupy).
BTW, that 2733x2134 might look odd, but it was carefully calculated. See the details here:
http://bigosaur.com/blog/31-android-resolutions-definite-answer
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 trying to write a libgdx livewallpaper (OpenGL ES 2.0) which will display a unique background image (non splittable into sprites).
I want to target tablets, so I need to somehow be able to display at least 1280x800 background image on top of which a lot more action will also happen, so I need it to render as fast as possible.
Now I have only basic knowledge both about libgdx and about opengl es, so I do not know what is the best way to approach this.
By googling I found some options:
split texture into smaller textures. It seems like GL_MAX_TEXTURE_SIZE on most devices is at least 1024x1024, but I do not want to hit max, so maybe I can use 512x512, but wouldn't that mean drawing a lot of tiles, rebinding many textures on every frame => low performance?
libgdx has GraphicsTileMaps which seems to be the tool to automate drawing tiles. But it also has support for many features (mapping info to tiles) that I do not need, maybe it would be better to use splitting by hand?
Again, the main point here is performance for me - because drawing background is expected to be the most basic thing, more animation will be on top of it!
And with tablet screen growing in size I expect soon I'll need to be able to comfortably render even bigger image sizes :)
Any advice is greatly appreciated! :)
Many tablets (and some celphones) support 2048 textures. Drawing it in one piece will be the fastest option. If you still need to be 100% sure, you can divide your background into 2 pieces whenever GL_MAX_TEXTURE happens to be smaller (640x400).
'Future' tables will surely support bigger textures, so don't worry so much about it.
For the actual drawing just create a libgdx mesh which uses VBOs whenever possible! ;)
Two things you dindn't mention will be very important to the performance. The texture filter (GL_NEAREST is the ugliest if you don't do a pixel perfect mapping, but the fastest), and the texture format (RGBA_8888 would be the best and slowest, you can downgrade it until it suits your needs - At least you can remove alpha, can't you?).
You can also research on compressed formats which will reduce the fillrate considerably!
I suggest you start coding something, and then tune the performance up. This particular problem you have is not that hard to optimize later.
I am working on android app. I see lot of apps say they have hd graphics and i can see some difference in their graphics and mine. I searched on google also but cannot get exact answer as to what actually hd graphics means? Is it some kind of format like .png or is it resolution like 400*800. I mean if i want to make hd image of a simple button how can i do that? Can anyone please explain in deatail keeping android apps in mind. Thanks in advance!
Basically you need to check out the definition of HD. That stands for High Definition and it's main idea is that by making resolution big, on bigger screens the quality of an image or a video won't look bad.
About Buttons, in Android or any other OS most of the times vector graphics are used instead of bitmaps. Vector graphics are just some coordinates which make up graphic, so when you zoom in or display a vector graphic on a big screen it won't lose it's quality. Bitmaps are collections of pixels. Check this out to get a basic understanding of dpi and pixels: http://en.wikipedia.org/wiki/Dots_per_inch
In order to use bitmaps efficiently for buttons and that kind of controls I'd suggest taking a look at this: http://developer.android.com/reference/android/graphics/NinePatch.html
I have a client that gave me a .psd file that contains the entire screen of an Activity with all the graphics. The resolution is 480x800. The client wants the application to look identical to the one in the .psd file. The problem is that different devices have different resolutions and sizes. I know that the density is what really matters but how can I scale the graphics to look the same on all the devices? For example, I exported all the layers and recreated the screen in Android but, for some reason, the screen looks more crowded on a Nexus One (480x800).
One idea would be to create 9 patch images from the graphics and use for ImageViews android:background instead of android:src right?
Isn't it better to have a 320x480 resolution for the graphics? Or do I need for both resolutions? Also, I have to consider the height of the status bar which I understood it is 25dip but I am not certain about this.
So, to summarize, I am interested to find out what is the best way for a client to give you the mockups and graphics so that it is easy for the developer to implement according to the specifications.
That's something that's not easy to solve. Think of a webdesigner, one can't know all the possible resolutions and settings of every browser so he has to scale things accordingly.
In my opinion there are only three approaches here.
First: Let him state what devices he wants to support and only support those devices. Extract the layers with the size of the device with the highest resolution and scale them down on other devices.
E.g. If you have to support two devices with 480x800(2) and 240x300(1), export all images to be 480x800 and scale them down accordingly. Don't write a single application for every device.
Second: Export the graphics with the highest resolution possible and scale them down on all devices relative to the device being used. Imagine, again, a webdesigner. All he does is define margins, paddings, etc. and it will look nice in almost any browser. You should do the same and resize your elements on demand.
Third: Make the application fixed, e.g. define a size of 200x200 for your whole application and just fill everything larger than the screen with a certain color, e.g. black. This happens a lot with java ME applications, they look great on the hardware they were made for and are still playable on hardware that is beyond their time though they look pretty ugly.
Hope this helps,
Robin.