When I first started working with AutoLayout, I couldn't find any example which helps understanding for what stands the Aspect Ratio NSLayoutConstraint.
Does someone have an example of usage? Thanks!
I have a demo example of keeping a square view centered in all devices and orientations here.
The constraints are set up in IB, but you could just as easily set them up in code. Most of this was meant to explain how to prioritize margin constraints to let the auto layout engine know what to break and when, but what makes the view square is the aspect ration - it's 1:1. If you want a rectangle, you make it 2:1 (or 1:2 depending).
Once you understand these two pieces (prioritization and aspect ratio), the last piece is the actual margins values - I set them for 10 points, meaning the square will have 10 point margins on the smallest axis. If the device is an iPad Pro 12.9 inch, you get a very large square. If it's an iPhone SE, you get a very small one. No matter what, you get the 10 point margin. Set the margin values up for 50, and the square view is relatively smaller. The important thing is with an aspect ratio of 1:1, it will always be a square.
Related
I want to set a screen size for my view (Making it for iPhone 6). Problem is, I don't know if the input scale in point or pixel
Is it 600 pixel or 600 point?
Thank
It is in point. In retina devices, 1 point equals two pixels (or 1 point equals three pixels for #3x supported device). In non-retina devices, 1 points equals 1 pixel.
To answer your question, these are points, not pixels.
I am not sure why you want to set a fixed size only for iPhone but I think you might be interested in checking out some Auto Layout tutorials like this one. It will help you build interfaces for multiple devices at a time !
Like KDeogharkar said, there are different factor between points and pixel depending on the device. Usually you don't want to work with pixels.
I just noticed an interesting thing while attempting to update my app for the new iPad Retina display, every coordinate in Interface Builder is still based on the original 1024x768 resolution.
What I mean by this is that if I have a 2048x1536 image to have it fit the entire screen on the display I need to set it's size to 1024x768 and not 2048x1536.
I am just curious is this intentional? Can I switch the coordinate system in Interface Builder to be specific for Retina? It is a little annoying since some of my graphics are not exactly 2x in either width or height from their originals. I can't seem to set 1/2 coordinate numbers such as 1.5 it can either be 1 or 2 inside of Interface Builder.
Should I just do my interface design in code at this point and forget interface builder? Keep my graphics exactly 2x in both directions? Or just live with it?
The interface on iOS is based on points, not pixels. The images HAVE to be 2x the size of the originals.
Points Versus Pixels In iOS there is a distinction between the coordinates you specify in your drawing code and the pixels of the
underlying device. When using native drawing technologies such as
Quartz, UIKit, and Core Animation, you specify coordinate values using
a logical coordinate space, which measures distances in points. This
logical coordinate system is decoupled from the device coordinate
space used by the system frameworks to manage the pixels on the
screen. The system automatically maps points in the logical coordinate
space to pixels in the device coordinate space, but this mapping is
not always one-to-one. This behavior leads to an important fact that
you should always remember:
One point does not necessarily correspond to one pixel on the screen.
The purpose of using points (and the logical coordinate system) is to
provide a consistent size of output that is device independent. The
actual size of a point is irrelevant. The goal of points is to provide
a relatively consistent scale that you can use in your code to specify
the size and position of views and rendered content. How points are
actually mapped to pixels is a detail that is handled by the system
frameworks. For example, on a device with a high-resolution screen, a
line that is one point wide may actually result in a line that is two
pixels wide on the screen. The result is that if you draw the same
content on two similar devices, with only one of them having a
high-resolution screen, the content appears to be about the same size
on both devices.
In your own drawing code, you use points most of the time, but there
are times when you might need to know how points are mapped to pixels.
For example, on a high-resolution screen, you might want to use the
extra pixels to provide extra detail in your content, or you might
simply want to adjust the position or size of content in subtle ways.
In iOS 4 and later, the UIScreen, UIView, UIImage, and CALayer classes
expose a scale factor that tells you the relationship between points
and pixels for that particular object. Before iOS 4, this scale factor
was assumed to be 1.0, but in iOS 4 and later it may be either 1.0 or
2.0, depending on the resolution of the underlying device. In the future, other scale factors may also be possible.
From http://developer.apple.com/library/ios/#documentation/2DDrawing/Conceptual/DrawingPrintingiOS/GraphicsDrawingOverview/GraphicsDrawingOverview.html
This is intentional on Apple's part, to make your code relatively independent of the actual screen resolution when positioning controls and text. However, as you've noted, it can make displaying graphics at max resolution for the device a bit more complicated.
For iPhone, the screen is always 480 x 320 points. For iPad, it's 1024 x 768. If your graphics are properly scaled for the device, the impact is not difficult to deal with in code. I'm not a graphic designer, and it's proven a bit challenging to me to have to provide multiple sets of icons, launch images, etc. to account for hi-res.
Apple has naming standards for some image types that minimize the impact on your code:
https://developer.apple.com/library/ios/#DOCUMENTATION/UserExperience/Conceptual/MobileHIG/IconsImages/IconsImages.html
That doesn't help you when you're dealing with custom graphics inline, however.
I got a tiled map and I want to make lava lakes. I wish to have some kind of lava texture image on the background looping diagonally slowly. I could make it with four 960x640 images and move all of them diagonally etc. But when I do, a black/white line appears between each...
... and someone suggested me "CCParallax". I have never used it and am not sure if it really can achieve the effect I am seeking.
Also note that as the player moves on the map, the parallax will need to simulate that as well etc.
So my question is, what would you do for this effect? Four looping images or "CCParallax"?
CCParallaxNode is pretty limited because you can't specify endless parallax scrolling without modifying the class. It also doesn't quite fit your use case.
Using four 960x640 images is wasteful. Just to make some lakes underneath the background this is overkill and will negatively affect performance.
The solution depends a bit on how big the lakes are. For example, if these are just 1 or 3x3 tiles in size you could add a textured sprite underneath each lake. If on the other hand your tilemap consists mostly of a few narrow pathways while the rest is lava lakes, then you need a different approach.
You might want to try GL_REPEAT to repeat a single sprite's texture over a defined area. That allows you to use a relatively small texture, for example 64x64, that will be repeated over the rectangle you specified.
You can then modify the sprite's position each frame to scroll the texture. Every time the sprite has moved 64 pixels in horizontal or vertical direction, you subtract 64 pixels (sprite.contentSize.width) from the sprite's position to reset it back to its original state. That means the sprite will never move further than 64 pixels from its initial position in any direction but you still get smooth scrolling.
I'm using following ratio for pixel to meter conversion,
PTM_RATIO=32;
v3BodyDef.position.Set(2848/PTM_RATIO, 102/PTM_RATIO);
This this produce weird output many times on the screen, so does setting position(v3BodyDef.position.Set) take floating point variable or not I don't know, but I think this conversion making trouble.
Please help me with this.
Thank you.
There isn't a recommendable ratio for that (though some will try and convince you there is).
The scale of objects in your physics engine should depend on the average scale of your dynamic objects. What I mean is, that if your player interacts with a lot of objects "slightly larger" and "slightly smaller" than itself, it's probably best to make player an average size in the optimal range (for example, Box2D is optimized for objects between 0.1m and 10m in size, so make player 1m, or 1.5m).
As for your pixel size, that all depends on how large you want your world to be on the screen.
If you want your hero to be 1/10th of the screen in height, and 2 meters away from the camera, then do the math :-p Others may want their here to be 1/8th of screen height, or 1/12th.. that really depends on how the game will look in the end. If the camera zooms in, the pixel to physics ratio would change. If the screen resolution changes (like a retina display), your pixel to physics ratio will have to change accordingly.
So in practice: there is no set value. It really depends on the game, and depends on what feels best for the hardware you're on.
It's most likely an integer division problem, change PTM_RATIO to a float (or if you are defining it, use #define PTM_RATIO 16.0f )
I am facing this problem while trying to rotate the map in my iPhone app
The view gets clipped and rotation also happens. I want to avoid the clipping. Any tips ?
heres the code:
viewToRotate.layer.transform = CATransform3DMakeRotation(0.8, 0., 0., 1.);
You need your map rotated in 3D ? If not (which is what I think you need), then just use CGAffineTransformMakeRotation (be careful, as it requires the angle in radians).
Also, if you don't want your map to be clipped, you need to make your map bigger, like in the image below (open in new tab to see it bigger)
http://img593.imageshack.us/img593/4498/calculatemapboundswhenr.png
First, you need to calculate the diagonal of the rectangle (your visible map) as instructed in the image above (which I call "radius" because that would be the radius of the smallest circle bigger than your rectangle).
Second, using the radius, you need to calculate the (smallest) square that will allow your map to be seen without clipping. This square will be used to set the bounds of your map (caution: NOT the frame - Apple specifies that, when using rotation, you should not use frame - just bounds and / or center).
Make sure this square is centered on the center of your visible map rectangle (i.e. the square should have X pixels above AND below the small rectangle ... and Y pixels left AND right of the small rectangle).
Hope it helps !
Did you ever figure out the solution?
The only way I could do it was to make the MapView in Interface Builder much bigger than the actual size of the screen area its supposed to cover, then I centered the MapView such that its center was in the center of the narrower viewable area.
Rotation seemed to work similarly to how it works in the built-in Maps app.
My guess is that you have to do this so that the image tiles streaming in from Google cover a wide enough area to "fill in the blanks" so to speak, even if they're not always visable.
If you apply a little math, you could probably programmatically size and position the MapView such that you void clipping, but don't require more tiles than is absolutely necessary.