What are the limits on GMSGroundOverlay? This would be things like file size, resolution, etc..
I'm using Google Maps SDK 1.5. I created a ground overlay from an image that was 4836x5557 72 dpi 6.6 MB. That image did not show up. When I reduced the image to 3481x4000 72 dpi 4.5 MB, that overlay image did show up.
I did try some permutations of resolutions and file sizes but couldn't nail down the pattern. I did not see any documentation of limits in the docs nor headers.
This is important to me as we have customers who use want map overlays, and to be able to provide them up front with the constraints for the overlay graphics is useful and saves much time for all involved.
Thank you.
Overlay is rendered using OpenGL as a single texture, so the limitation on its size is probably the same as limitation on OpenGL texture size.
On the latest devices maximum texture size is 4096×4096:
https://apptyrant.com/2014/04/19/max-opengl-texture-sizes-for-various-ios-devices/
The solution is either to limit the overlay size or to use Tiles API.
Related
I am currently making a mobile match-3 like game in unity. I have made all the graphics for the gems(the objects with which you make the matches) in Inkscape at 256x256 and exported them(PNG Files) with 90 dpi(also tried with 360 but nothing changed). My problem is that when I run the game in the editor the graphics seem to be "pixelated" and blurry. In my sprite settings I've set Pixels per Unit to 256, checked Generate Mip Maps, I am using Bilinear Filter Mode and the aniso level is 0. I have also set the max size to 256 and compression to high quality(My Main Camera's size is 10 but I tried to change that and nothing changed as far as the quality of the sprites). What can I do to "perfectly" display my sprites? Do I have to export them in some other way from Inkscape or do I have to change some Unity's settings?
Thank you.
NOTE: My sprites are not "pixel art"!
Edit(Added photos of the purple gem as file and how it is shown in editor):
Because scaling
You're display resolution on the images isn't a 256x256 region where those images are displayed, which means that they must be scaled in some manner in order to display in the desired region. Camera rendering is notoriously bad at scaling. As your images aren't Vector (and Unity doesn't support vector graphic formats anyway), scaling will always result in a loss of detail. Detail like hard edges.
Your options are:
smaller images where you have complete control over how the image is scaled down
bilinear filtering (which is fundamentally blurry)
mipmaps (which are automatically scaled down versions of your image in powers of two)
If the later two aren't giving satisfactory results, your only option is the first.
I'm very new to AEM and I'm trying to reduce the image size by using named transform image servlet in AEM 6.3. After reducing the image size using resize property, the image quality goes down terribly.
I've also tried using attributes sharpen and quality however I'm not able to understand their proper usage even after going through the adobe docs.
This is the original image resolution
1600 x 530
This is the image configuration that I've tried so far:
bounded-resize:width=1423&height=471&upscale=true (using this only reduces the image quality a lot)
quality:quality=82 (this changed nothing)
sharpen:op_usm=3.5,20(this distorted the image completely, sort of oil paint effect)
Above configuration maintains the aspect ration but not the quality.
Need to know what wrong I've done in this and how do I REDUCE THE IMAGE SIZE WHILE MAINTAINING THE ASPECT RATIO AND IMAGE QUALITY.
You should check the order of Image Transformers in your transformer configuration. The documentation states:
Order matters when defining your image transformation rules. For example, a resize then crop can yield significantly different results than a crop then resize.
I am not a 100% sure which makes more sense: Resize and Crop or Crop and Resize. But that would be easy to validate:
Create two transformer configurations. Both should just contain the resize and crop setting but in a different order. Call both of them (with the right URL) and then compare the resulting images.
how do I REDUCE THE IMAGE SIZE WHILE MAINTAINING THE ASPECT RATIO AND
IMAGE QUALITY.
As a best practice, to achieve a high image quality and small file size, start with the following combination of parameters:
fmt=jpg&qlt=85,0&resMode=sharp2&op_usm=1.75,0.3,2,0
This combination of settings products excellent results under most circumstances.
For further reading and learning, Refer to this
I want to implement zooming of sprites with a pinch gesture in Cocos2d.
How do I achieve it without the image getting pixelated?
I tried with vectors but with no success, I'm doomed using raster bitmap images.
Do I need the largest possible image with the highest resolution to make it look
nice?
What is the size limit for pngs in cocos2d?
What other pitfalls do I need to consider?
Yes. For example if the sprite should cover an area of 1024x1024 pixels when zoomed in to maximum, you need to create the image as 1024x1024 and set the scale property to below 1 in order to create a smaller version. If you use scale greater than 1.0 the image will always lose detail and become ever more blurred as scale increases.
There is no size limit in cocos2d, it's the devices that impose the limit. Most devices can handle 2048x2048 except 1st and 2nd generation which support only 1024x1024. You wouldn't normally support these older devices though, so 2048x2048 should be the default. Several newer devices (iPad 2+, iPhone 4S+) can use up to 4096x4096 textures.
Memory consumption. Not sure what you're trying to do, but often developers have little understanding about how much memory textures consume and what amount of memory is available. For instance, 2048x2048 as PNG with 32-Bit color consumes 16 MB of memory. Don't plan on using more than 4-5 of these, unless you're able to reduce color bit depth and use TexturePacker to be able to use the compressed .pvr.ccz format. Read my article about optimizing memory usage for more info.
The restriction of 1024x1024 as the largest image for an iPhone is a problem with iPhone 4. However if an #2x image is used with maximum dimensions of 2048x2048 everything looks equally good on the 4 as it does on a 3 - tried and tested in simulator and device. Question is, does the image dimension restriction relate to the UIImage or the resource that it contains? I can't imagine resources of more than 1024 pixels are discouraged with the 960 pixel height of the screen.
The right answer is really to use tiles so that things look even better, but the deadline for for this deliverable is too close - it's a future thing.
From UIImage class reference:
You should avoid creating UIImage
objects that are greater than 1024 x
1024 in size. Besides the large amount
of memory such an image would consume,
you may run into problems when using
the image as a texture in OpenGL ES or
when drawing the image to a view or
layer. This size restriction does not
apply if you are performing code-based
manipulations, such as resizing an
image larger than 1024 x 1024 pixels
by drawing it to a bitmap-backed
graphics context. In fact, you may
need to resize an image in this manner
(or break it into several smaller
images) in order to draw it to one of
your views.
That is, views are rendered and composited with the iPhone's GPU. If your view, for example, overrides drawRect and tries to render a very big UIImage you might run into problems. Newer generation iDevices, such as iPad and iPhone 4 support bigger textures than 1024x1024 (2048x2048 I think).
I didn't realise there was a restriction, I'm using an image 15198 × 252 as the scrolling landscape in Scramble... works really well, though I must say I did have reservations before I tried it out!
Is it possible to use an image captured with the iPhone's camera as a texture that is then manipulated in OpenGL ES (flag wave effect, etc.)? The main problem being the size of the iPhone screen being 320x480 (no status bar) and thus the image won't have dimensions that are power-of-2. Is the main option copying it into a 512x512 texture and adjusting the vertices?
Yes, that's the way to do it.
Just use a larger texture. It's a waste of memory but unfortunately there is no way around this problem.
An alternative would be deviding the picture into squares with a length and height of 32 pixels (aka tiling), resulting into 15x8 tiles. Displaying it would however involve many texture switches while drawing which might become a bottleneck. On the other hand you would save a lot of memory using a tiled approach.