I am fairly new to OpenGL development on iOS. I'm working on software that will create 3D reconstructions of objects in the form of *.ply files. I'm trying to make an iOS app to visualize these simple vertex-only *.ply files. Everything works as intended on the iPhone and iPad Simulator, but when I run it on my iPhone, the points rendered in the view are glitchy and covered with large squares. Here's the comparison: iPhone and simulator. Has anyone run into similar issues with OpenGL?
It's important to understand that when running OpenGL ES code on the simulator, you're actually running it on the simulator's software implementation and not on the GPU.
The simulator's implementation is close to, but not identical to the implementation on the device GPU. This means that faulty code may render fine on the simulator. I've experienced it myself on a couple of occasions, like when using glbuffers and not allocating enough storage.
It's obviously hard to say where your code goes wrong, but I'd suggest you to go through your code and look for subtle errors.
Related
Im just wondering if there is any code needed in application to utilize the new HDMI output ability with the iPad 2? Or is it the fact that you just plug it in and it will just replicate what is on the iPad screen?
Thanks
I wrote this game: http://itunes.apple.com/us/app/blaster-through-asteroid-field/id414827482?mt=8 before the iPad2 came out, without any specific code to output the display. When my iPad2 came in I was able to plug it into a projector as-is and display it live on both the iPad and the projector simultaneously (no noticeable latency either.. pretty impressive I think). So no, you probably don't need any special code. I would still test if you're doing any non-standard rendering.
Hey, I got kind of a weird issue here.
I have an iPhone-only OpenGL ES app which runs fine on all iPhone and iPod touch models supported.
When running on the iPad, it runs on an iPhone-sized window as expected, and pressing the "2x" button once scales up the window to twice the size, as expected, and the app continues to run without problems.
But if the user taps the "2x" button 3 or 4 times quickly, the app is killed with the Program received signal: "0" message (which, from what I understand, means the OS killed my app for using too much memory, is that right?)
What I really do not understand is what in my app could possibly be using up more memory when the iPad scales the window up and down? As far as I know there's not even any way for my app to tell if and when the iPad is doing that. I don't know if the fact I'm using OpenGL ES is related or not, but that issue doesn't happen on any of the Cocoa Touch apps I have - though it also doesn't happen on the other two OpenGL ES apps I have. And this app does use more memory than any of the other ones.
Anyone ever had or even heard of this problem? Googling gave me nothing.
Since no one has posted with a direct answer (your situation might be a little vague), I have a suggestion for how to move forward and gather more information on what might be causing your problem.
Check out the Instruments in Xcode which can identify memory leaks:
Instruments User Guide
Or for an even friendlier introduction, here's a video that address performance issues, including memory leaks (and how to find them). iOS Performance Optimization Video
Just adding this so there's some kind of an answer here...
I never figured out what the hell was going on with the 2x button.
The way I fixed it back then was to optimize memory usage as much as I could, lazy-load all that I could and unload again when not in use.
Weird that it never complains about memory when running on any of the supported iPhone or iPod touch models, even the older ones, but it got killed on the iPad ONLY when pressing the 2x button repeatedly and quickly... I guess that's always gonna be a mystery to me.
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.
I'm running this sample code located here:
http://monoclestudios.com/cocos2d_whitepaper.html
using cocos 2d-iphone 0.7.2, and the sprites are being drawn coloured blue. But this is only happening on the simulator. On an actual device, everything looks fine.
Has anyone else run into this problem?
Don't test OpenGL ES on the simulator. It just isn't the same. The simulator renders slightly differently. Since cocos2d-iPhone is heavily based on OpenGL ES, your only choice is to test on the device!
Unfortunately the simulator isn't identical to the physical iPhone. I haven't encountered this particular bug, but I did have issues with sounds. Wouldn't play on the simulator but worked fine on the device. If you're only having problems on the simulator I'd suggest ignoring the bug and moving forward. The simulator is just for convenience after all.
Checkout #cocos2d-iphone on freenode if you have more questions like this.