Our game is a 2D sprite game (not using Unity’s new sprite engine), so almost every single thing on the screen is rendered with alpha, since they are all 2D shapes surrounded by transparent pixels. In addition, we have some occasional effects that cover large parts of the screen with translucent objects, and on iPad 1, our framerate drops below 10fps at those times (it’s still not great even on iPad 3). We are using atlases tuned for different levels, so our draw calls don’t seem that bad, it seems to just be the transparent bits causing the majority of our slowdown.
Our game is set to run only on OpenGL 2.0 devices, the shader we are using for almost everything is Mobile/Particles/Alpha Blended:
// Simplified Alpha Blended Particle shader. Differences from regular Alpha Blended Particle one:
// - no Tint color
// - no Smooth particle support
// - no AlphaTest
// - no ColorMask
Shader "Mobile/Particles/Alpha Blended" {
Properties {
_MainTex ("Particle Texture", 2D) = "white" {}
}
Category {
Tags { "Queue"="Transparent" "IgnoreProjector"="True" "RenderType"="Transparent" }
Blend SrcAlpha OneMinusSrcAlpha
Cull Off Lighting Off ZWrite Off Fog { Color (0,0,0,0) }
BindChannels {
Bind "Color", color
Bind "Vertex", vertex
Bind "TexCoord", texcoord
}
SubShader {
Pass {
SetTexture [_MainTex] {
combine texture * primary
}
}
}
}
}
Any ideas? I’ve seen some pretty damn fast games on iOS, but I can’t think of much more optimization to do for ours than removing some of the transparencies, which unfortunately isn’t really an option.
Get rid of as much of the overdraw as possible; the new sprite system in Unity does this by automatically making meshes that conform to the shape of the sprite (if you have Pro) so there are relatively few 100% transparent pixels being wasted. Also, if you have shapes that have large solid areas, you can make meshes that have two submeshes, one for the non-transparent parts that uses a non-transparent shader, and one for the transparent parts. That will increase draw calls but get rid of a lot of the overdraw problem.
Are you using rectangular planes for everything? Just wondering as it has been pointed out many times before to actually create geometry that fits the sprite shape tightly. Reducing areas not needed in this fashion adds up to good optimization in regards to fill and overdraw … every bit helps. Where possible if the sprite shape is not to complex fit the geometry exactly and dont use a transparent shader at all.
EDIT: Eric posted while I was typing sorry for repeat info. His point on having two material submesh for large items is very good as well. eg a large rounded corner menu. only the corners need to be transparent, the rest can be opague.
We’re using tk2d, pretty sure it uses quads for everything, that’s definitely an optimization we could do to use non-square meshes, though it might be a bit of work. Any ideas for when we have large translucent things on the screen? Is there a better shader we could use?
That’s still over 2.5 million iPad 1’s (iPad sales numbers are insane). Anyways, it’s not up to me, my company has set the low-end at iPad 1/iPhone 3GS, and other 2D games have managed decent framerates on those devices. And our framerate is bad on iPad 3 too, when large transparencies are on screen. We are rendering our game at 768x1024 on all devices, extending the rendered area vertically a bit more for taller aspect ratios such as iPhone 5.
Render the game with less fill. Unity - Scripting API: Screen.SetResolution - render a smaller display. It should internally just render to a smaller texture and scale it up for you, which will save on fill quite a bit. You probably only need to do this for iPhone 4 and iPad 1. If it’s happening for iPad3 as well, you need to reduce fill.
This would not work as the 3GS can run iOS6. The 3GS at native resolution should be no problem at all unless you have really expensive shaders (not just overdraw, it can handle really a lot of overdraw) - the problem of the 3GS is that like the iPad 1 it just comes with 256MB RAM.
One reason why I don’t think it’s time to stop supporting it is the fact that Apple was still selling it 15 months ago. Those people who bought it with a 2 year contract within the last 24 months maybe aren’t that rare.
The stats are Unity stats. I would not take them too serious, not all Unity developers activate the stats for their Apps and possibly a lot of Unity developers itself are messing these stats up with their own testing devices while testing their own apps. At least they just does not fit to the other stats I saw.
The VIC20 was also one of the first machines I’ve wrote code on, first one was really weird: a Magnavox Odyssey² with assembler cartridge.
Unfortunately they called the VIC20 VC20 in germany “Volkscomputer 20”, no joke:
