Lower framerate on iphone 4 than on ipod touch 2g

I think the title speak for itself but i get a lower framerate when running my apps on an iphone 4 than on a ipod touch 2g…
I have closed all application on my iphone and i did not set anything specific related to the iphone version in my apps except if unity automatically change his settings according to the iphone version.

Thanks

sounds like you need to optimize, ip4 has 4x more area to render

It may be the ipod touch 2g falling back to simpler shaders or something like that…

I’m gonna guess you have large, alpha-blended elements that cover the whole screen. This is a problem on the iPad 1 as well due to the higher pixel count - you can seriously harm your framerate with something as simple as a single alpha-blended polygon that covers the camera’s view, such as a black poly that you fade in and out for a “fade to black” effect. If you’re doing anything like that, make sure it’s renderer is disabled when it’s not being used, and make sure you aren’t using alpha shaders on anything that doesn’t really need it (like an opaque background).

Thats a good point. How do we fade to white and fade to black in a fast manner? its a common crossfade. In my old C++ app for ios, I would just change the vert RGBA of everything, but I’m not sure its that simple in unity?

Depends on how your game is setup really. I usually use a very simple shader on a black poly that covers the screen, and just disable its renderer when the fade is complete, so the performance hit is pretty much invisible. In other projects I’ve just animated my lights on and off.

Yeah well Mika your right i use a lot of alpha in my scene in fact everything use alpha and some are not very optimized so if you tell me that large transparent area may cause this lag i will fix them. I didin’t know that was causing the lag cause it was running well on earlier version of iphone. Thank you! Each of my texture are 1024x1024 RGBA Compressed PVRTC 4 bits 0.5 MB i have 6 or 7 of them i don’t really know if it’s really heavy i just changed the texture type to advanced and unchek the Generate Mip Maps option, plus on my plane i use the Transparent/Diffuse Shader i don’t know if this is the best to load alpha texture into an iphone apps.

Yea, it sounds like alpha is the culprit - it’s something that doesn’t really effect older devices, but you notice it big time with fill-rate bound devices (iPhone 4, iPads, etc.). Swap your materials to a simple diffuse with no alpha and see if the framerate gets dramatically smoother, it’ll screw up your visuals, but at least you’ll know if that’s the bottleneck.

The built-in Transparent/Diffuse is not the most efficient shader, I’d check out some of the shaders in the “mobile” category to see if you can get something that looks the same, but performs better. And above all, make sure you’re not using alpha shaders on polys that don’t need them. For example, let’s say you were making a first-person shooter, and you’ve got the player in a room with a few windows. If you were to make the whole room a single mesh with a single material, but you were using a transparent material so that the windows could have alpha, that would be incredibly wasteful. Even though 90% of the room’s surface is 100% opaque, it’d ALL be calculating alpha, and destroying your framerate.

You’d be much better off having the opaque parts of the room have a simple diffuse shader, and let the glass of the windows be a separate mesh with its own transparent material. It’s more draw calls, but less work for the GPU overall. Keep an eye peeled for any similar situations in your project, where you’re essentially calculating alpha on a large amount of screen real-estate that isn’t really necessary.

You were right all the way i have just tried using normal diffuse and no more lag. So i will make sure to optimize my scene. Thank You very much for your help !!

Building on Mika’s excellent suggestions you could try modelling a low poly version of the object instead of using a quad, for example a large spiked ball? you would model a low poly spiked ball then just texture it normally. If you are not scaling it, the added verts do not in any way make it slower than a quad because it just sits in the vertex buffer and you’ve saved a ton of fill rate.

Also, it’s not strictly “alpha” that’s a problem. According to my findings, every single blend mode has the same performance hit on these devices, so an additive shader is just as bad as an alpha blended one, for example. I don’t own any of these “fillrate limited” devices, though, so this maybe be inaccurate post-3GS. If you’re fading to black, you can in theory do a lot better than alpha blending; same goes for white.

Well thats the thing with these tests. On fixed function OGL 1.1 you probably will have a different bag of results. I am not sure thats important these days though with everything worthwhile being done in 2.0.

I suspect the real reason for alpha blending being slower than additive is because they’re using alpha test.

Right, blend is blend when it comes to overdraw. if it is add, mul, alpha, cutout or whatever, the overdraw happens and kills the fillrate and it holds post 3GS too, its the exactly same gpu, but a <25% as large number of pixels you can draw per frame

I don’t know. It seems to me that these shaders ought to yield the best performance for their respective tasks, but whether hardware quirks always stop it from happening, I can’t say at this time. All I know is that they haven’t provided me a noticeable boost over alpha blending, on an iPod touch 2G or iPhone 3GS. Feel free to use them as you please; at least they’re really easy to use. :stuck_out_tongue:

574313–20474–$Fade to White.shader (469 Bytes)
574313–20475–$Fade to Black.shader (462 Bytes)

how do you use these shaders, do you apply them to a quad covering the screen? :slight_smile:

Yeah. However, you can make it even faster, both performance-wise, and setup-wise, if you don’t work in world space (the shaders in this post fit that description). It doesn’t matter where you put this mesh, in the least, unless you’re not using OpenGL ES 2.0, where as far as I know, there’s no way to avoid transforming the verts by the ModelViewProjectionMatrix.

(Turn the mesh compression up to high and turn off the normals on this; it’s just a square that needs no lighting.)

Edit: This mesh only works within certain clipping plane ranges. If you know how to fix that, please tell me. I don’t currently have a strong enough grasp of what gl_Position corresponds to, in terms of Z values.

574337–20480–$Fade to Black.shader (431 Bytes)
574337–20481–$Fade to White.shader (438 Bytes)
574337–20482–$Fade Square.zip (47.3 KB)

thanks for this Jessy, i’ll try it out and see if there’s any performace increase over what we’re currently doing.

Sorry to bring this thread back from the dead. But is this still the fatest way to do a transition fade to black?

Obviously, these days it’s not as much a concern, but I’m always happy to find the fatest/most efficient way to do these types of things?

Cheers,

Alex