I did an wave animation to explore features of sgx chip which is tile-based rendering (TBR) architecture by comparing the performance on iphone and laptop.
An advantage of TBR architecture is it allows the GPU to perform hidden surface removal before fragments are processed, so I draw many overlaped layers of animated waves, and only the wave in the top layer is visible.
I did this program on both iphone 3gs (using gles 2.0) and my laptop, a macbook pro(using opengl 2.0). I recorded the fps numbers of different layers, and I assume trends of fps changes on iphone and laptop are different. I guess the performance's decreasing of iphone should be slower than on laptop, when the number of layers is increased. But they have very similar trends.
I have 2 questions.
1. why it doesn't show the advantage of TBR architecture, while there are alot of overlapped triangles
2. why the performance of iphone simulator is much much much much slower than just running on laptop(without simulator)? As documentations say the simulator does not enforce the memory limitations of MBX and SGX and take the advantage of laptop's CPU, i guess its performance should keep up with the laptop.
anyone can help?
thanks alot
The OpenGL ES implementation in the iPhone Simulator is a software rasterizer and does not use the GPU in your MacBook.
What kind of framerate trends are you seeing, and in what way is only the wave on the top layer visible? Your primitives typically need to have framebuffer blending disabled and not issue discards in the fragment shader in order for hidden surface removal to skip fragment processing for what’s underneath.
Related
I imported my artwork in the simulator and this is how it looks like:
The alpha channel is not honored in the simulator.
The pnb is made on a win xp machine in Photoshop and imported
on a mac.
Is this only a simulator issue? I don't have a device to test.
In case its not simulator specific, what should I do to improve the png quality?
This will also happen on devices too. The phenomenon is called 'colour-banding', caused by the limited number of bits used to represent each colour channel, and affects all images but especially images with slow gradients. You can lessen the effects by applying some dithering algorithms (I believe that the TexturePacker tool has some post-processing dithering capabilities). See this article for an example of the effect of some dithering algorithms.
I recently ported a project from Cocos2d 1.1 to 2.0. So far everything is working great, but I've noticed that the frame rate drops from 60 fps to around 40-50 fps on the iPhone 4 and the iPod Touch 4. Other devices I have tried (iPads 1 & 3, iPhone 4s) still run at 60.
At first I thought I had too many draw calls, but after reducing the calls from 54 to 17, I still had the same fps on both devices. I should note that I don't have this problem on the default Hello World template, nor do I have any openGL errors in the console. My memory footprint is around 50mb, so I don't think that's the problem either. Any ideas?
Looks like you have a simple performance problem. The other devices running at 60 fps (at least iPad 3 and iPhone 4S) have more computing power and better graphics processors than the iPhone 4 and iPod Touch 4.
Since this happened after upgrading from cocos2d 1.1 to 2.0, there's the possibility that the 4th generation iPhone devices don't run OpenGL ES 2.0 code (shaders) as fast as the other devices. It could also be an issue with cocos2d 2.0 itself. Unless you really need to use a feature of cocos2d 2.0 (ie shaders) the easiest approach would be to simply go back to cocos2d 1.1. If you aren't writing shaders, cocos2d v1.1 is just the same as 2.0 in terms of features (at this point in time).
Finally, test performance only with release builds. If you run Debug builds things like logging and assertions can totally skew any performance results.
I've had experience writing a cocoa touch app as a universal app (for ipad, iphone) and it wasn't too hard. I only needed to use different .xib for each device but atleast it was the same binary.
Is it possible to have a universal opengl es app as well? Is it difficult given I have to have the resolution different for each devices (iphone 3gs, iphone 4, ipad)? So most probably my code would be different for each device???
While difficulty is a subjective measure, I would argue that it is a simpler process to develop an OpenGL-ES-centric application for the various devices than one based on more standard user interface elements. Where an iPad version of a standard iPhone application may require a completely different interface layout, if you are doing fullscreen OpenGL ES drawing, you just simply need to have the rendering layer scale to the appropriate screen size.
For example, take a look at the code to my Molecules application (it's available under a BSD license). It is a universal iPhone / iPad application and shares a lot of code between the two interfaces. In fact, almost none of the OpenGL ES portion changes based on the platform.
When it comes to something like the Retina displays, you just need to add one little bit of code in your CAEAGLLayer-hosting view's initialization to account for the new scale factor:
if ([self respondsToSelector:#selector(setContentScaleFactor:)])
{
self.contentScaleFactor = [[UIScreen mainScreen] scale];
}
Nothing else needs to change, and your OpenGL ES content will now render at the higher resolution.
Probably the biggest issue you will encounter is that by going to the higher-resolution displays you may find yourself being fill rate limited where you weren't before on the older iPhones. If you see the Renderer Utilization getting near 100% in the OpenGL ES instrument, that's what is happening. For the Retina displays, you may then want to not render at the full 2X scale factor, but something a little lower.
I can't speak to your particulars, but I have a universal app and it uses OpenGL-ES. For my purposes, glViewport() call takes care of things.
I am writing an application which contains some graphs drawn in OpenGL ES. each of these graphs are in a table cell, when I press some of those graphs, it is being opened in full screen mode.
Everything worked perfectly since I upgraded to iOS4.2. Now the problem is in simulator, I can't see the drawn graph in cells, but in full screen mode I do see the chart. There are no changes no the device, it is only on the simulator and only in a case.
The behavior is the same for other Mac's here.
Does anyone have a clue?
As explained in this answer to this similar question, there has been a change in the way that 4.2 handles renderbuffers in Core Animation layers. From the OpenGL ES Programming Guide:
In iOS 4.2 and later, the performance
of Core Animation rotations of
renderbuffers have been significantly
improved, and are now the preferred
way to rotate content between
landscape and portrait mode. For best
performance, ensure the renderbuffer’s
height and width are each a multiple
of 32 pixels.
It appears that if your renderbuffer isn't an even multiple of 32 pixels, it doesn't display in the Simulator. This is a bug in the Simulator, but you should probably make your renderbuffer a multiple of 32 in either dimension in any case to improve performance.
Same things with my App. My textures are broken sporadically on the simulator (4.2). On the hardware everything looks fine.
I don't know if this helps much, but I've seen all manner of strange behaviour on the simulator implementation of OpenGL ES: spurious images appearing; strange lighting on the first render pass; broken rendering to bitmaps, depending on when I call it. I'm no expert in OpenGL programming, so I could just be writing crap code, but there is definitely a noticeable difference in the behaviour of the simulator vs the real hardware.
Your experience suggests that maybe my problems aren't entirely my fault. :-)
I have a really weird problem with PVR textures on the iPhone simulator- the framerate falls through the floor on the iPhone simulator, but on the iPhone itself it works just fine. Has anyone had any experiences similar to this? I'm using SDK 3.1.2
The iPhone simulator is known to be extremely slow for certain rendering scenarios.
One especially bad case we experienced was that creating (glGenTextures+glTexImage2D) and destroying (glDeleteTextures) a big texture (title screen) will kill all performance until a hard simulator restart.
Testing your "logic" on the simulator and "assuming" it will be fast on the device has been working pretty good for us.
As always: Try avoiding state changes!
And yes: PVR textures are supported, but simulated in the shader.
Yes, simulator supports PVRTC textures, but probably does decompression into RGB format during upload or when texture is used for the first time. In my game it causes big slowdown until every PVR texture is shown at least once. Of course, those slowdowns appear in simulator only and on actual device PVRTC textures are very very fast.
The iPhone simulator is notorious about being almost like the iPhone.
I cannot speak about PVR textures, as I am not sure. But, from other things I have done (and from what I read on the internet) most developers give up on the simulator rather quickly due to its minor differences from the real thing.
In the end if it works on the iPhone, then the simulator doesn't matter.