I am making a 2d game in Unity.
when i put a background sprite that will cover the whole screen it drops my frame rate from 60 to about 40 on my android device (galaxy tab).this is really strange i would not expect this degrade in performance from a single sprite. Did any body else encounter this?
A large sprite can absolutely affect frame rate, especially if the image you use matches the display resolution. It can also vary per device, as not all GPUs are equal - higher resolution displays with lower-end GPUs are bad in these cases.
To minimize the performance impact you try the following:
Ensure that alpha blending is disabled before rendering the background image. Rendering a large image (even one without any alpha) while alpha blending is enabled will affect your framerate severely.
Remove all background "clearing" operations (those that clear the frame buffer). These are redundant since your image will cover the entire background (effectively clearing it).
Use a smaller image and stretch it to fit the entire background (use filtering to smooth out the enlargement).
Use lower bits per pixel (such as 16 bit) for the image.
All of these impact performance to some degree.
Numbers 1 and 2 are essentially "free" optimizations, which you should definitely implement. Numbers 3 and 4 will degrade the quality of your image, but may improve your framerate - it will be up to you to decide whether the tradeoff in quality is worth the speed improvement.
Related
Does it matter, how high the resultion of my graphics are (the picture of my player is 1500 x 2000 px) or are there any problems, that the game couldn't work very well or smooth or something like that? (Unity, 2D Game)
This really depends on the target device, as well as the scale of your game. I wouldn't think that it would cause issues, but it really depends on how many large images you have rendered at the same time. You can also always change the max size in the sprite settings if it becomes a problem.
Also keep in mind that if your player is small it really doesn't need to be that large, so I would just go ahead and decrease the max size in the sprite settings if that is the case.
I'm assuming that you are asking about texture size.
modern hardware can handle resolution such as 1500 x 2000 very easily and I would not worry about rendering speed.
However, texture loading (affects both CPU & GPU) may become issue if you have large textures (or large number of textures). if you have 1000 textures of 1500 x 2000, it will become hard to load the texture without affecting user experience.
Im having some memory issues with my app. It can pick an image from the users personal gallery and store it in a file to be rendered on the screen. The issue is that the limitation on the imagesize is very small. Which I have discovered lead to pretty much every image on my device being to large to handle. So the method itself became useless since it can't handle moderate sized images. I'm experiencing this only on ios devices so far.
Is there a solution? Can I compress/minimize the size of the image to a smaller one in any way? Cutting all images to the same resolution? (Like Instagram's system).
If you want to reduce the image size in bytes, there are at least 3 areas you can work on:
Reduce image dimensions (pixel resolution). This almost always
causes loss of quality, but if your users are viewing on small
screen devices, and you don't resize too much, the loss won't be
significant. You can also use interpolation to minimize the visual
degradation when resizing.
Reduce bit depth (color resolution).If the image is full color (32
or 24 bits per pixel), you can sometimes get away with reducing it
to a lower color count such as making it 8-bit. Again this will
cause quality loss, but you can use dithering to reduce it.
Use better compression. Most images are
already compressed these days, but in some cases you can re-compress
an image to make the file smaller. One example is JPEG which
supports different quality factors. There are also different
sub-types (color sampling frequencies) in JPEG. So if you save an
image as 4:1:1 instead of 4:4:4, it will contain less color content
and become smaller in byte size, but the difference is usually not
noticeable to the human eye. This post has details on changing
JPEG Quality factor on iOS.
I am developing an android application. I have a custom view which is a functional circular progress bar. It has 12 circles uniformly distributed over a bigger circle.
Since the design is simple and geometric I can achieve the desired results by having a one small circle and rotate it around the center. That will cost me one file on disk, one bitmap on memory - which is kinda small, around 300kb on memory- and some amount of cpu power on rotating and drawing the bitmap.
Another option come to my mind is that I can have all 12 images ready on disk, load all of them on memory, and draw the appropriate one each time. This option doesn't have rotating overhead.
Now my question is, which one is more viable/reliable in general, and specifically for android. You can assume 10 fps is more than enough. And if you think it wont make a noticeable difference please let me know.
I'd rather have 1 image and rotate it at runtime. That isn't too costly an operation, and loading N bitmaps into memory can take up a bit of memory, which apps are already hurting for.
In general. I prefer having minimizing my resources as much as possible. Rotating a small bitmap like that won't cost too much power and packaging 12 of those (12*300kb) is a considerable increase in app size. However, you have to consider this in relation to your overall app size and requirements. If you need to minimize size, rotate it and if not, load them all into your app.
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.
My current project is about android image processing.But if my phone camera is about 1-2 megapixel, will it affect the result of preprocessing like grayscale and binarization?
Your phone camera won't affect any pre-processing you perform in that your pre-processing code will act just the same regardless of the number of megapixels in your camera. Garbage in, garbage out still does apply. If you start with a low quality, poor contrast, blurred picture, you aren't going to be able to turn it in to something fantastic you want to hang on your wall. Additionally, as Mizuki alluded to in his comment, a 1-2 megapixel phone image is far higher resolution than the average image used on the internet, and these can be binarised and greyscaled just fine.
As for the two methods of preprocessing you mentioned in your question:
Binarization
This just converts an image into a two colour version. Normally black and white, though other colours are possible. The number of pixels in the image doesn't matter for this, other than it taking longer if it has more pixels to process. Low quality mobile phone cameras can sometimes produce low contrast photos and this may make it harder for the binarization algorithm to correctly determine the threshold at which pixels should be displayed in either colour.
Greyscale
Converting an image to greyscale is done by manipulating the colours of each pixel so, again, the number of pixels should only increase the preprocessing time, not change the result.