I'm having issues with the "postprocessing / glitch" example on mobile. It's just the snow effect that's causing trouble. On desktop it covers the entire view port during a glitch. On mobile it's only appearing at the bottom. I think this is the line responsible. It's within DigitalGlitch.js.
"vec4 snow = 200.*amount*vec4(rand(vec2(xs * seed,ys * seed*50.))*0.2);",
I don't see why mobile should be effected.
This issue is most common in mobile devices one of the reason behind this device pixel ratio
Normally mobile devices have pixel ratio > 2
a pixel ratio of 2 means 4 times more pixels to render
to optimize the performance we have to normalize this, and You can try -
renderer.setPixelRatio(Math.min(window.devicePixelRatio, 2));
Related
I'm totally new when it comes to xcode, but there occured a problem:
I'm designing an iPad-App(Retina Display) in html/css with the standard retina resolution of 2048x1536px...the problem is, that when I open the app on the pad, the page turns out to be way too huge. If I'm reading out the UiWebView-Resolution I get 1024x768...am I able to change this to get the real iPad dimension?
thx for your help!
Best regards,
daft
Dimension values on iOS are described in points. Each point can have different number of pixels - depends on screen's pixel density. UIWebView interprets html document size value as point - so 1 html pixel means 1 point.
I suggest you two options to cope with that:
1. Design you're web app to resolution 1024x768 and insert images which are scaled to 50% size to have more pixel density.
2. Leave page in 2048x1536 resolution and use UIWebView api to scale content.
I am working on a game in Unity3d and I am facing a bizarre problem. My NGUI elements are turned into a black area when I run the game into iPod4 and iPhone4. However it is working well in iPad, iPod5 and iPhone5.
It seems to me that in iPod NGUI is not able to get the corresponding Atlas. Even the UIlabel are being shown as a black area in NGUI. Does anybody know what the problem might be?
Is there any memory problem on a lower capability device that might cause this?
Black sprites in NGUI on mobile platforms are usually caused by your atlas being larger than what is supported by the hardware. It's a simple physical limitation. The hardware simply does not support textures of a larger size.
The iPad and iPad2 (originally, though this changed) are limited to 2k textures. The iPad 2 (now), 3 and 4, as well as the Mini, the iPhone 4S and 5, and the iPod 5 do have 4k texture support.
So that explains the issues you were having. A simple hardware limitation.
Hey guys I got the solution. The problem caused by NGUI Atlas which was of 4096*4096. I have lower the atlas's resolution 2048*2048. Now everything is fine.
Black sprites in NGUI on mobile platforms are usually caused by your atlas being larger than what is supported by the hardware. It's a simple physical limitation
i am building windows store app. I am using windows 8 and WPF with visual studio .net 2012.
UI of this application should be scalable to different screens. I have created a page where the controls (buttons, images, texts) fits correctly when running the app on simulator with resolution 1920 x 1080 for 10.6" screens. The problem is that when i change resolution, controls do not behave correctly
when resolution or screen sizes are increased (ex. 1920 x 1080 for 23" screens) empty spaces are created on the page;
when resolution or screen sizes are decreased (ex. 1024 x 768 for 10.6" screens) controls sizes are increased too and some of them are not visible in UI because they are displayed too far in bottom.
Is there a way to build "scalable" store app which are independent of screen sizes or resolution? Control sizes and font sizes should increase and decrease when resolution change or from one screen to another but all of them should fit in the space and shouldn't create empty areas.
Any help would be very appreciated.
thank you
This MSDN article discusses the guidelines for scaling to screens.
it touches on Screen size, Screen resolution, and Aspect ratio. It provides a table which shows best practices recommended for apps that use scale-to-fit functionality and it touches on adaptive layout. there is a reference to [Guidelines for layouts] at the end of the article as well.
Hope this helps!
http://msdn.microsoft.com/en-us/library/windows/apps/hh780612.aspx
joelcitizen
With the new screen resolution and aspect ratio of iPhone 5 it seems there are two approaches to take advantage of the new screen real estate when handling images that are full screen (or mostly full screen) images:
Include two images bg#2x.png and bg-h568#2x.png and check the device's main screen bounds to figure out which to load.
Only include the one file but make it the full iPhone 5 resolution
(There are other methods also: stretching, tiling, and / or drawing with Quartz.)
Both of these options have drawbacks:
Including two files is going to increase your app's bundle size
Loading a iPhone 5 retina image on a 4 will clip the image data when displayed on screen, but will still consume the same amount of memory resources
I am particularly interested in understanding the details of the second drawback better.
I am thinking it would save the app bundle (and my designer) if I could use this consolidating images idea further...
Let's say I have an image that take up 320pt x 480pt in portrait and 480pt x 320pt in landscape (width x height).
(EDIT: Initially I hadn't considered a couple of other important tidbits. For sake of completeness, I'm including those thoughts here)
If we create a single image file at a 480pt x 480pt resolution instead of landscape and portrait files, it would prevent the app bundle from having two files that which each contain 320pt x 320pt area of duplicate image data. However, this large square image would include four 80pt x 80pt quadrants in the corners that won't be seen. All things equal, we should still have 20% less image data in the app bundle.
Having re-read Bill's "iBooks Author Experiment", the memory requirements are very easy to figure out:
Landscape or Portrait: 640 * 960 * 4 = 2,457,600
Large Square: 960 * 960 * 4 = 3,686,400
The memory required to load the large square is 50% more then loading the image sized correctly for the screen. Clearly the savings in the app bundle don't measure up to this hit on resources!
But, what about extending this to a giant square that would encompass iPhone 5 and iPhone 4 - 568pt x 568pt? Instead of four files (iP4 landscape, iP4 portrait, iP5 landscape, iP5 portrait), there would be only one file in the app bundle (giant square). The savings could be about 60%.
What about the resources hit?
iPhone 5 Landscape or Portrait: 1136 * 640 * 4 = 2,908,160
Giant Square: 1136 * 1136 * 4 = 5,161,984
That's 110% more memory for iPhone 4, and 77.5% more memory for iPhone 5.
My original question was roughly two parts: 1. Do I understand this correctly and 2. is this tradeoff a wise one to make.
I hope my edits (spurred by Bill's answer) show that I do understand this stuff now. And, if the new found knowledge is correct, then #2 pretty much answers itself. :-)
Generally you get it.
Assuming that you have the big square image and it's some kind of tiled pattern (linen etc) then you could use ImageIO to load the cropped image at the size you need which would use some extra memory decompressing the image but once done it would consume only what is needed to fill the background.
I would suggest against scaling the image.
On the flip side though, shipping an app with 3 images (foo, foo#2x and foo-h568#2x) instead of 1 makes way more sense. The only way I'd say you should go with one image is if you are close to the 3G/LTE download size of (I think) 50MB.
Screen resolution has increased in iphone OS4. Since lot of UI stuff have hardcoded co-ordinates, will my app run properly on OS4? I still haven't got Snow Leopard, so cant test run the simulator for OS4.
It is publicly known that the number of points vs pixels is 2:1 so point 320 has 640 pixels in hi-res and 320 pixels in low-res. Low resolution images will be somewhat jaggy, but their positioning on the screen would remain the same.