In my app I want use images for every product item. This image must be added to product when user create new item product. What the best approach about size image? (e.g. re-size image in 100x100 px or 200x200 px)
About size of Images and memory consumption of an application. This information can save you some painful time with android development.
take under account that most of the time this will affect your app performance
e.g. on most cases the used memory of the app will take:
x pixels * y pixels * 4 (bytes)
(you can change rgb encoding code to make the last parameter 2 or 1 that will effect image colors)
So 100 * 100 * 4 = 40000 bytes = 40 KB
but below and behold:
let's take a tablet setup of 1280 * 800 * 4 = 4096000 bytes, which is approximately 4 mega bytes. Taking under account that some devices max RAM for app is 16MB you might be scratching the limit at that setting.
And don't do what I did with:
2560 * 1600 * 4 = ~16MB
That will crash many android devices RAM limit with a little bit more than 16MB per image!! not so adaptable to most devices.
Personally I think that the image in Android development is not very convenient, but maybe they are working to improve it.
All you need to know about what resolution to use for what is given in the android official documentation. The best guide lines are posted here
Related
i want to record 120 sec video from my application and want video size only to 3-4 MB maximum, so is there any way to reduce that instead of using FFmpeg ?
I'm not sure whether this is possible whilst still making it look good.
A video with a size of 300 x 300 px, a color-depth of 16 bits and 10 frames per second (which isn't to good looking and not very smooth), takes ~200 mb uncompressed: (300 * 300 * 16 * 10 * 120) / (8*1024*1024)
Scaling that down to 4 mb would be a compression of 5000%. I might be wrong with my math and trying the answer of #mehul might be good to start with but I guess it won't be possible. But again, try it, I might be wrong.
You can - of course - reduce the quality I mentioned above but I don't know if that is wanted by you (For example, half the colors and 8 fps results in 82 mb uncompressed).
I have a viewport (360x640), but if I render fonts on that they are ugly. So I made higher size's and downscaled them. But now they go disoriented. (size == 30)
I made a 4x bigger viewport then so I didn't need to downscale them. But now my game instead of taking 15mb ram takes up 50mb. (size == 120)
And this is not acceptable. That my textures take 30x less ram than shitty 3 TTFs.
See https://github.com/libgdx/libgdx/wiki/Coordinate-systems#world-coordinates.
Use 2 viewports:
One which is near pixel perfect (around the same as the screen resolution of your reference target device), which you use only for the GUI like labels, buttons, etc.
And one which fits your game logic best (although 360x640 gives the impression you are using banana units (imaginary pixels), which you shouldn't do) and you only for rendering game objects and such.
Either way, the size of your assets (either on disk, in RAM or in VRAM) are not in any way related to the size of your viewport: when you change the size of your viewport then you should not scale your assets. The size of your assets should be around the same size as they are when they are projected on the screen. So it doesn't matter whether you use a viewport of 3 by 5 meters or a viewport 1440 by 2560 bananas. What matters is the size in pixels on the actual screen (e.g. take a screenshot and measure it). The size of the assets should be around that same size for best results.
If that means that you need a very large font, e.g. because you use a reference target device with a very high resolution (e.g. Retina Display), then that's how it is. You could work around that in several ways, e.g. by rendering to a smaller FBO, using texture filtering, etc. But reality is that devices with such large resolutions are equipped with at least enough memory to hold the assets for such resolution. So, in that case using more memory isn't really an issue.
If you like to target multiple resolutions which have different restrictions on the asset size then you can use multiple assets sets. For example by using ResolutionFileHandleResolver.
Although not related to your question, note that BitmapFont by default assumes a near pixel perfect projection and therefor uses integer positions to prevent aliasing. If you really don't want use a near pixel perfect projection then you disable that using the BitmapFont#setUseIntegerPositions method.
I am accessing images from android resources folder.
i am using asynctask to load images.
On first time i used images with resolution of 1024*768 the app opens and one by one image is shown into imageview.
on second time,
For experiment i used images with resoltion 1920*1080 the app is giving runtime error and force closed.
The same happens with image resoltion of 1280*720.
but it perfactly runs with 1024*768 resolution
why this happens????
i m not posting code cause it doesn't seem to have programatical issue.
Simply you got Out Of Memory exception because your image size is large, consider this calculation:
In order to show each pixel in ARGB_8888 we use 4 bytes so:
your first image: 1024 * 768 * 4 = 2MB
your second image: 1920 * 1080* 4 = 6MB
your third image: 1280 * 720 * 4 = 3MB
I do not know how many images you are loading to your RAM but your RAM is limited and it is at least 16MB so with other 4-5 images you will have no RAM to other objects. look at
Loading Large Bitmaps Efficiently to solve your issue.
I am about to make my second game on android. The first one, jackheart- slot/jackpot like game (image based game (non OPEN GL)) like a programming training so in the making i didn't really concern about the size or resolution of all the images i used in the game. the result was, some of my image didn't look good in tablet.
now i am making 2D OpenGL game, it will be a super mario bros alike game. my largest target screen resolution is 2560 x 1600 pixels (samsung tablet 10.5), and my smallest target is 320x480 (galaxy young).
what i am about to do is creating images based on that 2560 x 1600 screen resolution:
create background picture = 2560 x 1600 pixels (as it covers all
the screen)
sprite/character = 120x120 (I used 32x32 for my first game)
could you really give me some input and advise regarding this..is it okay or not ?, i actually no clue and enough undestanding about this image thing.
i read some article out there that said that i can provide images for different target by storing it in folder drawable m,l,x dpi.. , i don't really know about that, is it automatically read by android or what ? because i am storing all my images in Assets folder and load it all in the load Asset class before launching the main menu.
Nah, I do checking in my load, read user screen res and load the proper image.
that's worked.
I'm trying to specify the art sizes for an Android game with ~10 screens. I want the game to run on API 8+, and on all size screens except "small".
Since we're using API 8, I use the old "4 categories of screen" feature - I plan to support
normal (480 x 320, and up to 640 x 480)
large (640 x 480, and up to 960 x 720)
xlarge (960 x 720, and up to 1920 x 1200)
A 1920x1200 png file is ~4.1MB. So 10 of them is 41MB, and we've almost blown our 50 MB app size limit (Play Store).
So three questions:
1. how do people support detailed artwork for game screens? Do I have to use bland colored 9 patch pngs files for the backgrounds? Or is it feasible to store all art at the 960x720 size, and allow it to be resized by Android for large and normal screens? 10 background files of this size total to about 15 MB, which leaves 35 MB for everything else.
What if I used jpgs instead of pngs? How much quality would I lose? Since I would only ever be downsizing, this should be OK, right? 10 jpgs of 960x720 is only 4.3MB.
If I allow Android to resize it, how do I support screens that have a different aspect ratio than the 4:3 of 960x720? Is there a way to specify in the layout XML "use the drawables from the large folder, but "letter box" it onto the screen, so that the longest dimension just fits" ? (And for xlarge screens bigger than 960x720, just put the drawable in the middle of the screen - don't stretch it at all)?
DPI resolution of the screen doesn't factor in this at all? DPI only needs to be taken into account when you want something to be roughly the same size on different res screens, like an icon or button. Correct?
Seems like this should be a solved problem with a well known pattern or template to follow. How have other people done it? Does everyone use either huge downloads post install (want to avoid) or 9 patch backgrounds?
Thanks in advance for any advice. I searched here on several terms, and looked at about 25 past answers, without finding what I am looking for.
Peter
Resurrecting the dead (thread): one way of doing things could be to provide just one set of bitmaps and do the scaling yourself. You can either provide large bitmaps and scale them down, or provide middle of the road bitmaps and scale them up (for large screens) and down (for smaller sizes).
The benefits of the former are that your art looks great on large screens and you are a bit more future proof (if you provide for this in your code). The downside is that you could (and actually likely will) run into Out Of Memory/Exceeding VM errors when decoding/loading these bitmaps on lower-end devices, even when doing it carefully. So I usually go for the second approach.
Scaling up can be done a number of ways, but one is to just load in the bmp at it's default size (use getResources().openRawResource(id) or BitmapFactory.decodeResource(etc) or even better use inputstreams or [according to some the best method] load/create using the FileDescriptor methods) and then scale it either by creating another bmp using createScaledBitmap() or if drawing to a canvas draw it to a destination Rectangle (better memory wise).
For scaling down you can either use BitmapOptions like .inScaled or, again, use a smaller destination Rect in your canvas drawcall.
Doing it this way is way better and (for a game) faster than letting Android scale for you using those buckets (hdpi etc) and uses less memory if done right.
But beware as some bitmap loading methods are a bit buggy and create 'the bmp is too big for the VM' errors. Also learn to dispose of your bmps properly; a lot of people and Google/Googlers say Android does this and you don't have to set your bmps to null and recycle() them, but so far I've found that you do. Another caveat is to set the proper options (filtering/antialiasing etc) to prevent blurry bmps. And take care of un-optimal color/format/dpi settings on BitmapOptions/canvasses/SurfaceViews and even windows.
There's much more, but this should help anyone get started.