It looks like when I shoot video with UIImagePickerControllerQualityTypeMedium, on an iPod Touch it comes out 480x360, but on an iPhone 4 it's something higher (can't say just what as I don't have one handy at the moment) and on an iPad 2 presumably the same as the 4, if not something different again.
I'd like to shoot the same quality on all devices -- I have to add some frames and titles, and it'll make my life a lot easier if I just have to code that for one resolution. Is there any way to determine what the different UIImagePickerControllerQualityType values correspond to at run time? (Apart from shooting video with each and then examining the result, that is.)
Or is my only choice to use UIImagePickerControllerQualityType640x480?
If you need more customization/power on iOS than you get wish the higher level objects, such as UIImagePickerController, it is recommended to work at the next lower level: AV Foundation Framework. Apple has some excellent documentation on AV Foundation programming that should come in handy for that purpose.
Unfortunately, even there you are limited to capturing at 640x480 if you do want it standard across all devices. There, however, is a great chart available at the same link (but anchors are broken in the docs, so Ctrl+F to "Capturing Still Images") that lists all the resolutions for various devices under certain quality directives.
Your most solid bet, assuming 640x480 is too small, is to work out some sort of scaling algorithm that would allow you to scale according to the overall resolution.
Related
I recently create a small puzzle game in Unity, just a simple one, not fancy effect or anything. It really smooth when I test run on Unity.
FPS normally cap at 200 and on the largest resolution its around 80 - 120 FPS - super smooth. After that, I build an iOS version and test on ios device, it's quite laggy. I tested on iPhone 6+, iPhone X, iPad 9.5 inches, and the outcome still the same, its a little bit lag. Maybe be I need to adjust some graphics settings on Unity ? Please I need some advice from you guys. Thanks for reading.
You can try a few things.
At the very beginning of your app, keep a target frame rate to 30.
Application.targetFrameRate = 30;
Downgrade quality settings to medium. Within that, also disable or dull down things related to lighting in case yours is a simple 2D game.
Optimize art. Pack art in packing tags, and on iOS, keep their compression at PVRTC. Only the ones looking really bad after compression should be RGB24 or RGBA32. Disable options like Generate Physics shape(if you're not using that), and Generate mipmaps.
Have a look at your UI. Anything in UI that is not interactive(like simple images, or texts, which are not buttons or input texts, etc) should have Raycasting off. The Rich Text option in texts too should be off if that is not affecting your app specifically.
If most of the devices are not supported ARCore, then why is Pokemon Go running on every device?
My device is not supported by ARCore but Pokemon Go is on it with full performance.
Why?
Until October 2017, Pokemon Go appears to use a Niantic made AR engine. At a high level, the game placed the Pokemon globally in space at a server defined location (the spawn point). The AR engine used the phone’s GPS and compass to determine if the phone should be moved to the left or to the right. Eventually, the phone pointed to the right heading and the AR engine drawed the 3D model over the video coming from the camera. At that time there was no attempt to perform mapping of the environment, surface recognition, etc. That was a simple, yet very effective technique which created the stunning effects we’ve all seen.
After that Niantic has shown prototypes of Pokemon GO using ARKit for iOS. It is easy to notice enhancements: missed pokeballs appear to bounce very naturally on the sidewalk and respect physics, it feels like Pikachu naturally walks on the sidewalk as opposed to floating in the air with the currently released game. Most observers expected Niantic to replace the current engine with ARKit (iOS) and ARCore (Android), possibly via Unity 3D AR APIs.
In early 2018 Niantic improved the aspect of the game on Android by adding support for ARCore, Google’s augmented reality SDK. And a similar update to what we’ve already seen on iOS 11, which was updated to support ARKit. The iOS update gave the virtual monsters a much greater sense of presence in the world, due to camera tracking, allowing them to more accurately stand on real-world surfaces rather than floating in the center of the frame. Android users will need a phone compatible with ARCore in order to use the new “AR+” mode.
Prior to AR+, Pokémon Go would use rough approximations of where objects were to try and place the Pokémon in your environment, but it was mostly a clunky workaround that functioned mostly as a novelty feature. The new AR+ mode also lets iOS users take advantage of a new capture bonus, called expert handler, that involves sneaking up close to a Pokémon, so as not to scare it away, in order to more easily capture it. With ARKit, since it’s designed to use the camera with the gyroscope and all the sensors, it actually feeds in 60 fps with full resolution. It’s a lot more performant and it actually uses less battery than the original AR mode.
For iOS users there's a standard list of supported devices:
iPhone 6s and higher
iPad 2017 and higher
For Android users not everything is clear. Let's see why. Even if you have an officially unsupported device with poor-calibrated sensors you can still use ARCore on your phone. For example, ARCore for All allows you do it. So for Niantic, as well, there's no difficulties to make every Android phone suitable for Pokemon Go.
Hope this helps.
As a preset, AVCaptureSessionPresetHigh makes a lot of sense to me. Hardware is always changing and it makes sense to have an option to tell AVCapture that "I want the highest quality you can give me given current hardware" What is driving me nuts though, is just because I want to set the session to an abstract value, doesn't mean I don't need to know the resolution it's displaying.
The only way to figure out the current resolution is to actually capture a frame and check the size of said frame. Or even worse, manually find all these resolutions, create a lookup dictionary, ask the device for it's model and then fetch the hardcoded resolution. This is a complete hack, but still better than forcing a frame capture and then asking a UIImage for its frame size.
I desperately need this information, in order to dynamically make decisions based on the aspect ratio the camera is providing. Why does apple not have an interface for such a simple query?
Does anyone know of a resource that lists all of the possible resolutions for both cameras across the entire apple hardware market? I can google my way through some, but I cannot track down a complete list.
Given the AVCaptureDevice, you should be able to enumerate at formats or examine activeFormat, and then look at highResolutionStillImageDimensions of the resulting AVCaptureDeviceFormat.
I would like to create custom tabbar items similar to the ones shown here:
I assume these have to be designed and created first in Photoshop or a similar application. Are there any resources or tutorials available that demonstrate the creation of such items in Photoshop and how these are then used in MonoTouch?
Creating and bundling bitmaps is one option - and likely the most common one (for which googling should turn up several tutorials). Now in order to get optimal quality you need to supply multiple sets for the old iPhone/iPod, the newer retina iPhone/iPod, the iPad (1,2) and the retina iPad 3. This can takes a lot of space to cover each case with beautiful icons (or it won't look as good).
An alternative is to create the bitmaps at runtime, e.g. using the CoreGraphics API. This might seems counterproductive (and can surely be in many cases) but it has the advantage of requiring less (storage) space and/or getting better quality (see note).
Why ? because if you create them at runtime then you'll only create the ones for the specific device you're executing on. You can even cache them and re-create them when missing (e.g. if iOS flush your application cache).
If you're not an artist (and I'm not) you might want to look at easily licensable vector icons. The ones from your screenshot looks monochrome and could even use (bundle or extra the outlines from a) custom font - like the one provided by FontAwesome (CC BY 3.0) or similar sources.
Note: Maybe you noticed (I know I did) that some iPad applications looked beautiful (compared to others) on the iPad3 even if they were released months before the hardware become available. Vector graphics wins ;-)
UPDATE: Someone already made a script to convert the FontAwesome characters to iOS tab bar icons. However since it's done outside the app you'll need multiple versions of each bitmap to get the best look on every devices.
A few days ago a client asked me if the transition to the iPhone 4s retina display was a difficult one, development-wise.
This made me ask myself whether I should have considered iPhones with high resolution dispays even before the iPhone 4 had been announced - creating artwork with higher resolution, preparing codepaths... (while, of course, creating high resolution artwork is never a bad idea, considering its use for marketing, porting to other platforms etc.)
Now, with the iPad being around for some months, first rumors of a future iPad with retina display emerge from the depths of the www. And I start wondering - would it make sense to prepare new projects for such an iPad? I'm pretty sure that apple will in fact release a retina iPad at some point in the future, because it would be quite a logical step. So, I guess the important question is "how soon can we expect such a device?". There is much to consider when thinking about that, most of all production difficulties and the impact of a resolution of 2048 x 1536 (if apple sticks to simply doubling the "old" specs) on a mobile devices performance...
So, what do you think? Will it pay up to prepare new projects for a retina iPad, starting now? Or do you think the overhead is not worth it, yet?
Maybe some of you are already developing with the retina iPad in mind..?
I'd be glad to hear some of your thoughts! Thanks alot, guys!
Edit:
Well, Apple just answered my question. Yes, it was in fact reasonable to consider a Retina iPad..!
I wouldn't spend too much time making your app work on a theoretical device. But that doesn't mean you can't be prepared. Ever since they started changing things around I've been considering the following:
Use vector art wherever practical. That way resizing should be simple
Don't assume that the screen is 768x1024 or 320x480. Try to make your views gracefully resize
Don't assume that there will be an on-screen keyboard
So far Apple have allowed time between announcing products and making them available, and even there un-optimised apps have still worked.
Most of my work is for a client who has their own designer, who provides me with layered Photoshop files to pick image elements out of. I now have a policy with them that ALL images will be provided to me at double resolution. I don't care if it's just text, if it's only going to be on the iPad, I want it at 2x no matter what.
That takes a lot of thinking and judgement out of the hands of the designer (who's a good designer but not a particularly good technician or strategist), and allows me maximum flexibility in what I'm building.
Right now, I don't think I'd build #2x support into an iPad app just now (although presumably 4.2 will allow you to do it and have it downgrade nicely, just like 4.1 does), but I have the graphics here ready to install when needed.
A few of Apple's apps (such as iBooks) have already been seen in the wild with #2x iPad graphical elements (mistakingly?) left in, so it is clear that a retina iPad is coming as soon as it is practical for Apple to affordably include such an incredibly hires panel.
It might be later this year, it might be a year from now, or it might be two years from now.
It doesn't hurt at all to prepare now though. It is easy to downres graphics, but it is often impossible to upres graphical elements without redoing them from scratch.
So short answer - do everything in #2x resolution now, but wait to include it with your app until the time is right. When Apple issues the call for retina iPad apps, you'll be ready to go and able to be featured on day #1.
I'm going to agree with the others. I'll go out on a limb and say I think it is highly likely that a Retina iPad will have 2x horizontal and vertical resolution compared to the current iPad screen, just like the did with the iPhone, because it is such a freaking clever idea in terms of the relative ease of support of the new resolution for developers, the backwards compatibility with apps that have not been updated, and it also gives Apple a mechanism for preventing developers from making a I'll-cram-in-more-UI-on-the-high-resolution-version interface...
So absolutely, planning ahead for this is a good idea. That said, the ideal would be to plan for full resolution independence where possible, using vector artwork and so on so you can re-export at new resolutions with minimum hassle.