I’m trying to figure out what factors are the most important reasons for the significant performance difference between the iPhone and the iPad.
I the case of the game I’m making the iPhone 3Gs is much faster than the iPad.
The level I have runs about 60 frames per sec on the iPhone and about 20 on the iPad.
the level uses the following objects
lens flare
fog
10k triangles
1 skinned mesh
two animations
blob shadow
no lights
texture only shader
partice simulation
GUI text
fixed timestep 0.06
max timestep 0.1
time scale 1.5
Occlusion culling.
What I’m looking for is iPad specific optimisations.
I know they both have to same GPU and the iPad has to fill a larger screen.
What does this mean in terms of optimisations?
Should textures be reduced?
I wish not to disable fog and lens flares as it a large part of the games atmosphere.
reduce the particles, they are the main reason of overdraw in this case likely.
replace everything you can with mesh effects that does not pile surface over surface to the ipads point of death
Dreamora is right, overdraw kills the iPad. It’s fillrate is awful to say the least.
I found Blob Shadows were really bad for this as any objects they hit are re-drawn, and any particle effects will also cause re-draw of pixels.
I haven’t used fog at all, but I would assume it also causes re-draw of pixels.
Draw calls are less significant as the A4 is far more powerful, however one thing I did find worked really well was to break objects down into smaller separate meshes, using the same material on all to allow for batching to kick in. Any environment objects that don’t move, make sure you mark them as static as well, as this will bring down the number of verts/triangles that need to be send to the GPU in the first place. How you break them up will be different on a case by case basis depending on your environment and other game art needs.
The way I speed things up with Cocos2d is to render the screen as TWO textures, this is way faster (and also less memory) than trying to do it as one texture due to the power of 2 requirements (if speed is a concern). Doing that and the iPad blows the 3GS out of the water
I know we don’t, hopefully UT does the required optimizations. They are very well known by all OpenGL ES developers, and make a huge difference in FPS.
As mentioned, double buffering has always been used by Unity.
That has been a standard for game related rendering since old cpu and Dos game days
So if its something that you need to do extra in Cocos2D I would be shocked, cause then something went totally wrong or they missed the target of what they wanted to achieve seriously before that point.
But perhaps you talk about something else thats not engine related at all but has to do with how you setup assets
I may be completely on the wrong track, but I think Hoff is talking about automatically splitting images into square power of two textures, even if it means taking two or three draw calls to draw one “virtual image”. I assume he means that the draw calls are insignificant compared to the speed boost you get from being able to compress your textures.
As I say, I may be barking up the wrong tree, but that’s the only “two texture” method I’ve heard of with regard to iPad.
Ah I see, would make sense.
Kind of an Anti - PackTexture
But wouldn’t that though require at least a quad split as you get 4 distinct sectors from a single image, at very least.
But above Anti PT also makes clear what you could do: You don’t need to go anti, you can really pack textures to expand a non pow2 texture to a pow2 texture and include other textures that are also not pow2
And thats already very well possible, for 2D, you can even buy a system with editor doing this (SpriteManager2) for you including image strip animation etc
Yeah, I guess it would depend on the size of the images. If they were small images, packing lots onto a single atlas would make more sense. If you were dealing with quite large images, making atlases of them would take you over the 1024x1024, which I gather you don’t really want to do with iPad.
and why would you not?
OGL ES 2.0 and 3GS+ support up to 2048x2048 and if you compress the texture, which you want to do otherwise the whole splitting was useless as you don’t gain anything aside of more management work (power of 2 is no requirement without compression), its still smaller than previously uncompressed, much smaller potentially
Here is what I mean, and forget about 3D and everything else for now…
The iPad has a usable game resolution of 1024 x 768.
Note that 768 is not a power of 2, so the texture size would be 1024 x 1024 if you used a single texture to draw to the entire screen. This takes up roughly 4MB of ram. If you were to instead use two textures 1024x512 and 1024x256, and not only will it draw to the screen faster, it will also take less memory (only takes 3MB).
You can do the test in OpenGL ES, note that the 2 texture version will run at 60FPS (the max), the single texture version will run slower).
BTW: Yes, I know you don’t need power of two textures unless you are using PVT compression. But, using power of 2 textures is still faster.
I don’t know. I only know that I’ve read a lot about not going over 1024x1024, even with compression. Yes, it’s certainly true that a 2048x2048 wouldn’t be using more resources compressed than a 1024x1024 uncompressed, but that’s not the sole factor in things “videocards” don’t like. If it was, everyone would be using 4096x4096 atlases on the desktop, whereas the sweet spot is typically closer to 2048x2048 there. Anyway, it’s only third hand stuff that I’ve read. I won’t have any first hand experience of 2048x2048 textures on the iPad until this weekend.
EDIT: That was in response to Dreamora. I cross-posted with Hoff.
On the desktop its a bit different cause there are millions of configurations and you commonly want to cover the trash too.
on the ipad you have 1, I repeat, 1 configuration you have to support, so nothing prevents you from opting for that(and future generation can only get better, we already know what the next and next-next generation beyond 2009 GPU are capable of. its direct successor is seen in action in the Galaxy S and Galaxy Pad)
What commonly speaks against going too large is the amount of data you need to load and that you need to push through on texture binding.
There it can have an impact but not needfully has to, that depends on your setup in general. as mentioned, a 1024x1024 uncompressed requires more bandwidth to push through than a compressed 2048x2048, from 2 to 4 times as much
