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.
I've been using ARkit and I'm loving it, but I noticed that during load tracking can gut a little jumpy (suddenly objects jump from their position a little bit off, like 1-3 cms). I've been wondering if there's a way to smooth out these jumps so it wouldn't be so distracting. Here is a short video demonstrating it.
https://youtu.be/wmMBjlLyK7w
I have been using ARKit and am also loving it I have been experiencing these issues as well and I have my theories but I am positive it is an issue with the hardware (comment which device you are using and I might be able to give a better estimate)
I believe it is the cameras on our devices and if that is the case then I would not worry about it too much because that would mean a behind the scenes problem we cant change or alter
If I'm not mistaken I remember Apple saying something about this in one of their developer classes earlier in this months keynote as I said before I wouldn't worry about it because older devices will have a harder time with the tracking because of the poorer cameras
How does someone check if an Apple device is suitable for playing a game a developed. I realised that in some cases, the devices that are 3 years old have too humble performance and my games have a lag because of that. Is there a test I can run to determine if my app can be played on for example iPad3 or iphone 5.
The only way to tell is to run it on that device. Apple has made a few of these options better by allowing you to test things with Xcode server, unfortunately most of the time it has to be done manually.
It's also worth noting that you could optimize for older devices by making changes to the game such as lowering textures, particle effects, shaders and more.
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.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
In the very near future my development setup will be upgraded and part of the deal will be dual monitors (yay!)
At least one of the monitors, possibly both, will be widescreen.
I've heard of developers using a second monitor, especially a widescreen monitor, in portrait mode. It allows for many more lines on the screen (albeit narrower) and runs a bit like having a long page of code.
Does anyone out there use this and think it's more effective?
I actually have 3 widescreen monitors in portrait mode and yes, it's a fantastic way to work. There's so much less scrolling around and you can fit all your debug / output / reference windows on screen at once.
The problem with using two monitors is that you'll generally be working on one main one and have output (or whatever on another). If you do have two, set it up so that your primary monitor is directly in front of you and the other (less frequently used) one is off to one side. I find that to be the best way to use a dual-monitor set up as it reduces RSI from being permanently twisted to look at a particular screen.
Additionally, there are some programs available to provide virtual screen splits which I've fund very useful for large/widescreen monitor setups.
[edit] ..and yes, you should write functions short enough to fit on a single page, but being able to see more functions at any one time can often make development easier in my experience :-)
[edit2] Running Visual-Studio-esque IDEs in portrait on a widescreen monitor is fantastic when it comes to debugging compile errors as you have more useable space to see code and errors at the same time. I suppose you could argue that if you compile regularly enough though, you shouldn't see that many errors at one time? ...but who codes like that? ;-)
Since you shouldn't write functions that are longer than a screen, making the screen much longer is a little bit of cheating, isn't it? ;)
Anyway, I found portrait mode not really better when coding, and only with my old 17" widescreen in portrait mode was viewing / editing documents better. With two large screens in landscape mode, You can put two pages on a screen when viewing documents, and have many tool windows open at both sides of the IDE's text editor. So no, portrait mode is not better, unless you have four of them to make up a really large screen (there was a photo of such a setup on a Microsoft blog, but I don't remember where).
There are some applications where portrait is still better, though, e.g. if you have to show a document in large resolution, or if you have some monitor (as in network monitor) running and want to see more lines at once.
I can't imagine how that would speed up productivity. In my opinion, it is always easier to scroll up/down than left/right.
It depends on which IDE you use, if any.
Microsoft Visual Studio likes to take up a lot of the width of the monitor with its “Toolbox” and “Solution Explorer”, so I find it works better on a landscape monitor. As it will not let you undock an editor window, you could not even drag a code editor to a second monitor that was in portrait mode.
Also consider how your customers are most likely to have their monitors set up. You may wish to write any UI code with the same setup, so you get a feel for what the application will be like to use.
Depends how big your monitor is. We have 1 28" monitor in landscape and 2 24" monitors in portrait which flank the big monitor.
Works great for pair-programming!
At work, I run my primary monitor (secondary is the laptop screen), in portrait mode. I really like it. I've become spoiled to seeing more code at once. I don't find that it encourages longer methods at all. Occasionally, I run across code that is a bit too wide since the IDE sidebars cramp it a bit, but I largely use Eclipse (Rational Application Developer, but Eclipse-based), so s quick double-click maximizes the code window, and it's very useful. Another double-click and I have my sidebars back.
I also find it a very useful orientation for my email.
I recommend it highly.
Portrait mode widescreen monitors work very nicely for edting code, thank you. However, some monitors have poor viewing angles on one dimension, which would usually be vertical but becomes horizontal in portrait mode. This can make the colours bad or unusable if everything isn't aligned correctly.
I have never given it a try but I would imagine it would work pretty well. I personally like to keep my lines fairly short, and wide screens tend to give me fewer lines of code, so I would give it a try.
It all comes down to personal preference however, what ever allows you to be the most productive and works best for you is the way to go.
For me it's not effective at all. I use IDEs, so in landscape mode I have sidebars to navigate code, navigate project etc.
It's not silly but a matter of opinion. A widescreen in portrait is very nice for writing code, code width has never really been an issue, and being able to see more line of code on the screen is always nice.
The other reason to put a widescreen in portrait is so it matches the height of your other monitor, for example a 30" widescreen next to a 22" widescreen in portrait have close to the same height.
It all comes down to your preference.
I just have one big monitor at my home office.
I tried it once. I didn't like it. I usually have an IDE and IDEs are perfect for widescreen. It's faster to jump around if you can see your function list on the right, file list on the left, etc.
Also, I try to keep my functions small so this usually isn't a problem (I have dual 24"). If your functions are reasonably small, and you have widescreen, you can show two files side by side which is often more useful. Some editors allow you to split the window and scroll to two different parts of the same file. This is also very useful is far better than having 100+ lines on the screen. With my settings, I have 60 lines per screen on an editor. If I split the editor, I can see 120. If I do it again on the other monitor, I can see 240. That's quite a bit of code and generally only useful for very different parts of it.
If you're working mostly with text (as most programmers or other technical folks do), or even documents, then portait mode is much more valuable. In fact, the general trend in displays is all the wrong direction: aspect ratios are squishing landscape displays to a mail slot to better fit the format of movies. Personally, I have never watched a movie on my computers (laptop or desktop), and I'm not about to start now - that's what I have a TV for!
In reality, vertical pixels are the most valuable asset in computing - do whatever you can to get more of them - you won't be sorry you spent the money! I won't even buy a laptop with less than 1024-1080 vertical pixels, since that's the minumum required to display a full page PDF at a readable resolution, and (much) more is better. (Since PDFs make up a large portion of today's online documentation/manuals, that's a very big concern.) You should only think about width after you've got enough vertical pixels.
What I really want is a 15.4" or 16" laptop with a portrait screen - these should still be wide enough to package a full-size keyboard into the base - a FlyBook-style pivot arm would be nice, but isn't required.
I found understanding the intent of related functions are easier when you print them first on paper than understanding them directly from screen, never fails, why? Because you can easily review many lines of code at one glance, no need for incessant scrolling.
The same thing with monitor oriented in portrait mode, you can easily understand the intent of multiple related functions, re-factored or otherwise. But don't let having portrait screen be an excuse to write a function with many lines.
Writing this on stackoverflow using portrait screen :-)
I can easily see many posts at one glance :-)
If you are working with print material, yes, as for source, why not full screen your IDE and close the task panes you do not need?
I find portrait is only useful to me if I'm working on a web site, being able to see the entire page at once helps.
I would say if the monitor is large enough you don't need portrait mode (24" and higher) for writing code.
If the monitor is smaller than that, then portrait mode is preferable.
Ideally what you would have is a single 30" (2560 x 1600) as widescreen to work on your code along with utilities comfortably open nearby and a second smaller monitor nearby to preview the results (I am speaking about web coding specifically here but it would probably apply to most other coding as well - a screen the size of your target audience's screens).
The 30" screens have really come down in price now so it's probably worth the jump up. A 24" screen does have the advantage of significantly larger text at default font sizes. The text on 30" monitors can get to be a bit of grind unless you move up to 14pt.
Good luck.
I have 2 19" monitors currently. One I keep in landscape and one I keep in portrait mode. I find that working on documentation or reading long web pages is easier on the portrait screen. I have used this setup for coding also and find that it does help, however it was a learned habit. lol