When programming for the iPad, font (and other) sizes are specified in "points." I have seen reference to a point as a pixel that is independent of screen resolution. But I am having trouble finding definite confirmation of how big a point is in real terms (that is, in terms of inches). Is a point equal to one pixel on the standard iPad screen, so 1pt = 1/132in? And then, to confirm, this means that an "iOS point" is a different unit than the printer's point = 1/72in?
Thanks.
See here and here (scroll down to points vs. pixels) for the official word. Basically, a point is one pixel on a non-retina device (so the size varies between the iPad and the iPhone - it isn't related to a printer's point) and 2 pixels on a retina device (which has twice the number of pixels in each direction).
Drawing and positioning is done in points to allow the same code to run on both types of device - the frameworks will fill in the gaps to make drawing smoother on retina devices.
An iPad point is different to an iPhone point, which is different to a printers point, to answer your question.
Related
I am trying to calculate the physical size of a shape (diameter of a circle) on an iPod touch.
According to the apple website, the screen size is 4" and the aspect ratio is 16/9. Using pythagoras and taking into account the relative size (CG points). I should be able to calculate the physical dot size.
However it always seems to be just a tiny bit out. E.g. instead of a dot size of 1" according to my ruler it will be 1.1"
Unless I am making an incorrect assumption in above. I feel like the only source of error could be due to the constants: incorrect screen size, incorrect aspect ratio or rounding error
Stolen from wikipedia:
The display of the iPhone 4 is manufactured by LG under an exclusive contract with Apple. It features an LED backlit TFT LCD capacitive touchscreen with a pixel density of 326 pixels per inch (ppi) on a 3.5 in (8.9 cm) (diagonally measured), 960×640 display. Each pixel is 78 micrometers in width.
There could be many factors, pixel pitch or some other. Don't break it down from the device size. Instead use the size of the pixels, including any pitch between them and multiply up.
There's a library here you might find useful for different devices to get this information, I haven't used it but it looks recent and useful.
I am quite new to Gideros and game development as well.
I am trying to build a game, it looked fine with the Gideros player, but when I tried with an Android phone, the background was way too small. I changed its properties to autoscaling so as to fit in with the width. The background now fits in the width, but other objects seem to go to absurd locations.
Though I was using W = application:getDeviceWidth(), H = application:getDeviceHeight(), and while setting up the location, used W/2 and H/2 instead of hardcoding it.
However, this object that seems to shift to rightmost bottom end(in landscape left mode) was right at its center if I do not apply fit width property.
What can I do to fix it?
You should use W = application:getContentWidth() , H = application:getContentHeight() which would return logical dimensions that are used when in scaling mode.
Basically it all brings down to these points:
1) Choose the scaling mode that is proper for your game (Letterbox being most popular)
2) Choose logical dimensions for your game and create all the graphics for logical dimensions you set in the project properties (recommended 480x800 or 640x960)
3) Create backgrounds a little more bigger than logical dimensions to cover whitespaces on devices with different ratios
4) Use absolute positioning (http://appcodingeasy.com/Gideros-Mobile/Ignore-Automatic-Screen-Scaling-when-positioning-objects) for objects that need to stick to sides of the screen as on screen buttons for example
5) (Optionally) prepare bigger graphics in in some fixed ratio coefficient and use Automatic Image Resoltuion feature to automatically load them for bigger devices
More information available here:
http://members.giderosmobile.com/knowledgebase.php?action=displayarticle&id=79
Addition: (Difference between device and logical dimensions)
Device dimensions is exactly what device has. Meaning on an iPhone 3GS it will return width as 320
But logical dimensions are exactly what you set in your project properties. No matter what resolution you have, the logical dimensions will always be the same. They basically will be scaled based on the scale mode you choose.
Here are more specifics on that topic: http://appcodingeasy.com/Gideros-Mobile/Difference-between-content-logical-and-device-dimensions-in-Gideros-Mobile
So if you are developing only for one specific resolution, you can use Device dimensions, otherwise it is suggested to use Logical dimensions with the scale mode you find suitable.
I'm building an iOS-based core text application (iOS 5, iPad), and have a view within which I'm performing some typographic calculations (in drawRect).
I've noticed that when I use CGContextConvertRectToDeviceSpace, the result I get on a retina device is double that of a non-retina device. It's my understanding that within drawRect there is an implicit transform applied that should hide any retina/non-retina device differences, so I'm confused why I should see any difference at all.
More specifically, I'm trying to calculate the location in user coords of a given CTLine in user space coords. I first use CTLineGetTypographicBounds for my line, and use those values in CGContextConvertRectToDeviceSpace to get a rect... but the rect I get back has double the width and height on a retina device versus a non-retina one. Is there something I'm missing?
I've noticed that when I use CGContextConvertRectToDeviceSpace, the result I get on a retina device is double that of a non-retina device.
Sounds normal to me. "Device space" represents the actual pixels on the output device, which in this case is the retina display. It's normally scaled 2x larger than the CGContext's user space coordinate system.
Normally it's rare to need to convert to or from device space -- you would only do it if you absolutely positively needed to align your drawing to real pixels.
What are you trying to accomplish by using CGContextConvertRectToDeviceSpace? There may be an alternative.
Kind of a fun question. I am hoping that is generates a lot of good thinking.
I am in the design, early alpha stage of my current orthogonal game project. I am experimenting with different tile sizes. A few questions as I would like to step off on the right foot.
Should we differentiate tile size (80x80, 32x32 etc) on retina vs. non retina displays, iPhone vs iPad displays?
What is a good recommended tile size that accommodates both the designer and the artist... and why?
Goals:
I would like to a clean, crisp visuals no matter the display format. Cartoony, colorful 16bit to 32bit images no matter the display.
I would like to keep to a 1024x1024 texture size for my atlas. I am hoping this will give me enough tiles to make the world look good and not crush my tile map system.
My current map size is 200 tiles wide x 120 tiles high. The map will be a a low detail (nautically focused) mercator projection of Earth.
Thanks in advance for all the good advice.
E
I usually try to make my games for iPad screen aspect where I'm making sure that the important elements are in a smaller Safe Zone. And the UI can be anchored on specified distance from the edges. Then for iPhone screen aspect I crop a small portion of the screen and layout the UI accordingly.
So if you are working in landscape here are the sizes you need to support:
480x320 - iPhone (0.5)
960x640 - iPhone Retina (1)
1024x768 - iPad (1)
2048x1736 - iPad Retina (2)
The number in brackets indicate the scale. I just like picking iPad (1024x768) for my ingame units. At this point I have all textures in 3 sizes, since I'm using OpenGL I use different mipmaps for each resolution I need. My texture loading function can skip mipmap levels so that on devices that I don't need high res I safe memory and loading time.
Depends if you need to click on individual tiles. In case you need to I'll suggest using 64x64 on iPhone (480x320) 256x256 on iPad Retina (2048x1736). Having all your art in power of 2 is always good. If the size is too large then consider 48x48 for iPhone and 192x192 for iPad Retina. If your game requires you can have smaller tiles but consider having larger active zone around the entities that you have to click (hopefully not every tile will be clickable).
I faced a similar issue a while ago and realized I was tackling the problem from the wrong angle.
You first need to consider the average finger/thumb size of the user and determine how many pixels/points consume that space.
From there you can derive the non-Retina Display pixel units and Retina Display point units to use.
N.B. that a game that might play well on the iPad might not work on the iPhone if the user's fingers obscure the view.
since the iPad 3("The New iPad") has twice the pixels I obliviously have my make any images twice as big. But my question is since it has twice the pixels if I am manually placing an object on screen, with say CGRectMake, will it appear in different places on the iPad2 from the iPad3?
say I'm using the code below to position a button on screen:
CGRectMake(375,500,125,125);
since its positioned at 375 pixels on the X coordinate wouldn't it appear in different places on the iPad 2 vs the iPad3 since the iPad3 has twice as many pixels?
I'm sure this is a dumb question that any mildly experienced iOS developer would laugh at but since a simple Google search didn't turn anything up I figured id ask.
Thanks!
-Shredder2794
Though the amount of pixels may differ among devices, Core Graphic's coordinate system does not. This is because CG expresses itself in points, not pixels.