Does anyone know where the various screen dimensions are for the iPhone4? I have checked the MobileHIG but alls I could find where references back to the old iPhone3G. Should I just assume that all previous values are doubled (i.e. StatusBar = 40 pixels), or is there a more accurate illustration (like the one below hidden somewhere else?
Cheers Gary
Points are the new pixels.
You keep working with the values you're used to, just like if you were still developing for 3G / 3Gs. The unit of these values is now called points instead of pixels, to avoid confusion. On the older iPhone models, a 2x2 point square equals 2x2 pixels on the screen. But on iPhone 4 the same square equals 4x4 pixels. UI elements are rendered at the appropriate resolution automatically, images and other content you provide will be scaled, unless you provide high resolution versions of those ressources.
You might want to read this document for further information.
You shouldn't really assume anything about the screen dimensions. If you need the dimensions, read them vie the API.
There is no promise that dimensions or even proportions will stay the same forever. (The iPhone, iPad and new iPhone all have different resolution size and proportions.)
That said, the dimensions on the iPhone 4 should be exactly twice the dimensions of earlies iPhone models.
Related
I am developing a game that uses levels. The levels are made at a default scene width and height resolution.
The thing i am worried about is when the game is played on IPads iphone 5′s etc, the position of sprites loaded from the level xml files will be out of place due to the screen size.
In my case, could someone tell me the best thing to do in this situation or some advice on the approach i should take?
Also if any has experienced this, please let me know.
Thanks. :)
Generally this has nothing to do with how or where you store the level data.
These are the standard approaches, which one works for you depends on your requirements and desired results:
design each screen resolution individually (error-prone, tedious)
design for one screen resolution, then scale up or down according to screen aspect ratio (can lead to skewing as the screen size scaling for width & height are likely to be different)
design for the smallest screen resolution, then center the contents on the screen (this leaves unused areas either at the top/bottom or left/right sides)
same as above, but zoom content to fill the screen (this will remove the letterboxing, but also partially remove one side's content from the view)
In essence this is the same problem as movies have in trying to fit to screens of varying aspect ratios.
In general this is all a matter of scaling the input (positions) to a desirable output. The easiest approach is to maintain aspect ratio and allow for letterboxing. However Apple may reject letterboxing apps if nothing is done to hide the letterboxes (black areas) since Apple requires apps to support widescreen resolution, and letterboxing does not normally fall into their definition of "supporting widescreen".
I have decided to have 2 set of images for my iPod game. One with 320x480 and the other for the retina one. I can switch happily between them but this forces me to add extra code to handle the change in resolution.
My game is played in screen space on a grid, so, if I have 32 pixel tiles, I will have to use 32 offsets in low res and 64 in retina (because of doubling resolution). For a simple game this can be no problem, but what about other more complex games? How do you handle this without hardcoding things depending on the target resolution.
Of course an easy way to bypass this is just releasing a 320x480 version an let the hardware upscale, but this is not what I want because of blurry images. I'm a bit lost here.
If you have to, you can do the conversion from points to pixels (and vice versa), easily by either multiplying or dividing the pixel/point position with the contentScaleFactor of your view. However, normally this is done automatically by you if you just keep it to using points instead of pixels.
This is automatic. You only need to add image files suffixed '#2x' for the retina resolution.
Regarding pixels, from your program you work in points which are translated to pixels by the system. Screen dimensions are 320x480 points for iphone retina and non-retina.
I have been doing some reading and tutorials on tile maps in cocos2d, but what i want is to have a large graphic map, not made up of tiles that the user can drag around. so my question is this.
Is it going to cause performance issues to have a large map, (this will be on the ipad so maybe x4 the screen size)?
The maximum texture size you can have is 2048x2048 for any device above the iPhone 3G (This includes all iPads, although it may be larger on the iPhone 4S, but I doubt it). You can find tons of links on google by a simple search of iphone max texture size. That means that the largest image you can have is between 4-6 iPad screens. If this is enough for you, great! If not, you'll have to tile the screen anyways, regardless of the size of your tiles. Hope that Helps!
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!
I'm trying to solve this flickering problem on the iphone (open gl es game). I have a few images that don't have pow-of-2 dimensions. I'm going to replace them with images with appropriate dimensions... but why do the dimensions need to be powers of two?
The reason that most systems (even many modern graphics cards) demand power-of-2 textures is mipmapping.
What is mipmapping?
Smaller versions of the image will be created in order to make the thing look correctly at a very small size. The image is divided by 2 over and over to make new images.
So, imagine a 256x128 image. This would have smaller versions created of dimensions 128x64, 64x32, 32x16, 16x8, 8x4, 4x2, 2x1, and 1x1.
If this image was 256x192, it would work fine until you got down to a size of 4x3. The next smaller image would be 2x1.5 which is obviously not a valid size. Some graphics hardware can deal with this, but many types cannot.
Some hardware also requires a square image but this isn't very common anymore.
Why do you need mipmapping?
Imagine that you have a picture that is VERY far away, so far away as to be only the size of 4 pixels. Now, when each pixel is drawn, a position on the image will be selected as the color for that pixel. So you end up with 4 pixels that may not be at all representative of the image as a whole.
Now, imagine that the picture is moving. Every time a new frame is drawn, a new pixel is selected. Because the image is SO far away, you are very likely to see very different colors for small changes in movement. This leads to very ugly flashing.
Lack of mipmapping causes problems for any size that is smaller than the texture size, but it is most pronounced when the image is drawn down to a very small number of pixels.
With mipmaps, the hardware will have access to 2x2 version of the texture, so each pixel on it will be the average color of that quadrant of the image. This eliminates the odd color flashing.
http://en.wikipedia.org/wiki/Mipmap
Edit to people who say this isn't true anymore:
It's true that many modern GPUs can support non-power-of-two textures but it's also true that many cannot.
In fact, just last week I had a 1024x768 texture in an XNA app I was working on, and it caused a crash upon game load on a laptop that was only about a year old. It worked fine on most machines though. It's a safe bet that the iPhone's gpu is considerably more simple than a full PC gpu.
Typically, graphics hardware works natively with textures in power-of-2 dimensions. I'm not sure of the implementation/construction details that cause this to be the case, but it's generally how it is everywhere.
EDIT: With a little research, it turns out my knowledge is a little out of date -- a lot of modern graphics cards can handle arbitrary texture sizes now. I would imagine that with the space limitations of a phone's graphics processor though, they'd probably need to omit anything that would require extra silicon like that.
You can find OpenGL ES support info about Apple Ipod/Iphone devices here:
Apple OpenES support
OpenGL ES 2.0 is defined as equal to OpenGL 2.0
The constraint about texture size's has been disappear only from version 2.0
So if you use OpenGL ES with version less then 2.0 - it is normal situation.
I imagine it's a pretty decent optimization in the graphics hardware to assume power-of-2 textures. I bought a new laptop, with latest laptop graphics hardware, and if textures aren't power-of-2 in Maya, the rendering is all messed up.
Are you using PVRTC compression? That requires powers of 2 and square images.
Try implementing wrapping texture-mapping in software and you will quickly discover why power-of-2 sized are desirable.
In short, you will find that if you can assume power-of-2 dimensions then a lot of integer multiplications and divisions turn into bit-shifts.
I would hazard a guess that the recent trend in relaxing this restriction is due to GPUs moving to floating-point maths.
Edit: The "because of mipmapping" answer is incorrect. Mipmapped, non-power-of-two textures are a common feature of modern GPUs.