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.
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'm new to computer coding and have just finished coding an app and tested it on both 3G and 3GS. On 3GS, it worked as normal as on the simulator. However, when I tried to run it on 3G, the app becomes extremely slow. I'm not sure what's the reason and I hope someone could shed some light on me.
Generally, my app has a couple of view controller classes, with one of them being the title page, one being the main page, one is setting, etc. I used a dissolve to transition from the title page to the main page. But even this simple transition shows un-smooth performance on a 3G! My other part of the app involves zooming in to some images by scaling up the images, switching images by push or dissolve upon receiving touch events, saving photos into photo library and storing and retrieving some photos in a folder and some data in a SQlite database, each showing un-smooth actions.
Compared with some heavy graphic or heavy maths app, I think mine is pretty simple. I totally have no clue why the app would behave so slow and un-smooth that it is barely useful on a 3G. Any help/ direction would be much appreciated. Thanks for helping out.
You might want to try profiling your application with Shark to find out where the performance bottlenecks are.
I don't know how relevant it is to your case, but my game (shameless plug) MultiMaze is quite undemanding graphically, and worked beautifully on my 3GS. But when I tried it on a 3G, the frame rate dropped to a glacial 10-20 fps. I ported the whole code base from CoreGraphics to OpenGL ES, and that made a world of difference. It now runs at the limit (60 fps) on my 3GS and very close to it on the 3G.
Are you using a lot of memory? 3G has 128MB while the 3GS has 256MB RAM.
Are you getting memory warnings? In my debug builds I have an NSLog in didReceiveMemoryWarning so I can see if/when I get warnings.
EDIT: Check the size of your photos, are they resized for the iPhone screen or are they original sized?
OK, finally found the problem and got the solution. The problem was that I have about a dozens of transparent images laying on each other to form my main view. So when in any animation, the system needs to redraw on every single layer and calculate their transparent effect and so on. (actually I'm not quite sure, but that's what I think)
The solution I have is to make a temporary composite view containing of them all, and placing the composite as an image in a full screen view before starting any animation. It delays starting the fade a moment, but the fade itself is a lot smoother now.
I have heard of apps not working properly on the simulator but working properly on the actual iPhone device. Has anyone experienced an app that runs perfectly in the simulator but not on the actual iPhone device?
Filenames are case-sensitive on the iPhone, but not in the simulator.
So, for example, if you try to load an image with UIImage *iconImage = [UIImage imageNamed:"MyIcon.png"], but your resource is actually named "myicon.png", then it will work on the simulator, but not on the device.
If your app is graphics intensive, like say a game, the performance of the simulator DOES NOT resemble at all that of the hardware. Your application will probably be smooth and work great on the simulator, but on hardware it'll likely render at a crawl unless you know what your doing. You can easily go from 60fps to 3fps between Simulator and hardware.
The order in which function/constructor parameters are evaluated is different:
int i = 0;
int f() { return ++i; }
int a, b;
int test(int p1, int p2) {
a = p1;
b = p2;
}
test( f(), f() );
//simulator: a = 2, b = 1
//device: a = 1, b = 2
Trigonometry functions may return different results:
float a = cosf( 0.108271248639 );
printf("%.12f", a);
//simulator: 0.994144439697
//device: 0.994144380093
I know there are some differences in the OpenGL ES implementation between the device and the simulator. From what I understand this is mainly because of the graphics chip on the iPhone (PowerVR MBX) having vastly different capabilities than other mac machines. Many of the hardware limits are not enforced in the simulator, so it is entirely possible to get something running in the simulator that will totally crash on the device.
There are also some OpenGL ES extensions that are supported by the iPhone hardware that are not supported in the simulator. I believe the major one is PowerVR texture compression (PVRTC).
Another problem area can be memory footprint. Anecdotally, I have not seen the simulator automatically enforce the memory limitations of the device. Therefore, it is possible to have something that runs in the simulator fine, happily consuming copious amounts of RAM and never bothering to free any of it only to be swiftly terminated after a short continuance of such behaviour when running on a device.
There are certain bits of code that won't work on the simulator (using the iPhone Keychain, for example), but for almost all applications, the simulator will work exactly like the iPhone.
That said, there's absolutely no replacement for testing on a real device.
I had a problem running a relatively simple 1/30 sec timer to do updates for a game. It runs fine in the simulator, and freezes out input on the device.
Also note that you will be compiling against the OS X frameworks (where applicable) when building for the simulator so you could be using methods and classes that aren't available on the iPhone versions of the frameworks.
One example I can think of off the top of my head is NSPredicate. I was able to compile and run an app using NSPredicate in the simulator, but it wouldn't compile for the device since that class isn't available.
Fingertips are larger than the 1 pixel endpoint of a mouse cursor. To do proper, even minimal, usability testing you should deploy your App to a device.
If you enable GCC_ENABLE_FLOATING_POINT_LIBRARY_CALLS, your app will crash all over the place in the simulator but work on the iPhone.
Quartz graphics calls in the iPhone simulator are faster than Java2D calls on the same computer--wicked fast.
I've had issues in memory-hungry applications where the Simulator would work just fine (because it would assume the iPhone/iPod Touch's memory was all yours to play with), while the device would crash (because other apps had leaked and Apple background services had eaten up some memory) and I hadn't implemented proper memory management or a response to the didReceiveMemoryWarning selector.
One big thing that took me a while to spot was that the simulator does not support device tokens, so any code that involves those will not run on the simulator.
I had a bug where the app would work fine on the simulator, but would crash when I ran it on a device because there was a bug in the device token code. I couldn't figure it out for the longest time!
There are many trivial examples. For example you can allocate far more memory on the simulator than on a real phone. You cannot receive push notification on the simulator if you don't have a retina Mac, the display dot pitch is different.
At a more fundamental level, the simulator is just that, it simulates the iPhone OS X using Mac OS X. This is evidenced by the fact that the filesystem on the simulator may not be case sensitive but on the phone it will be. More subtly, it does not emulate hardware so things like location will not work the same and 3D is going to be very different - especially if you are using Metal.
You should always test on real hardware.
Without considering the performance differences between the two, there used to be some things that the simulator didn't do correctly - i.e. it would mess up audio in some cases (see this question). However since the 2.2 SDK this issue has been resolved and the sound seems to be fine in the simulator. That's not to say that there is some other incompatibilities lurking down there! (Just none I've run into)
Regarding sounds, I was having the same problem. The issue was that the sound encodings that the Simulator supports is a different set of sounds than the device. I hope that helps.
I had many problems with libraries and frameworks when moving from the simulator to the device. Not least that they seem to have different architectures!
I have seen the positioning of objects, like toolbars be different on simulator than on the phone. Very annoying.
Yeah....
Apps compiled for 2.x will work fine on 3.0 device, but it will crash on 3.0Simulator
Note: 1. If you compile for 3.0, app will work fine on 3.0 simulator also...
2. a)Compile for 2.x and launch the app in simulator.
b)Now change the iPhone Simulator Hardware to "3.0".
c)Then launch the app we installed earlier in step a).
CRASH !!!!!!!!
movie file (m4v type) as my exprience is first time playing properly
but at second time it flickers screen of simulator...
whereas in iPhone device it works fime...
I had some sound effects that played fine in the simulator, but not on the device. I had to change the format to something that the device would handle.
If status bar of application is hidden,In case of simulator it still consumes touch event. But in the device it behaves perfectly.
Yes - it happened to me the other day. I'm new to the iphone, and so had deleted MainWindow.xib thinking it was unused. The app worked perfectly on the simulator - but crashed when installing on the phone.
Another issue we ran into was our three20 dependencies, which were set to ios 3.2 instead of 4.1. Worked perfectly in the simulator, but bombed on the device (since the files were compiled for the wrong arch).
iphone video library is not accessible
in simulator but code work fine on
actual device
Resource loading in the simulator is MUCH faster than in the device. For example, loading and displaying a sequence of full-screen UIImages (like a rudimentary video) can look very smooth in the simulator, and choppy on a device.
In fact, remember that there is a huge speed difference between different devices. The original iPhone and the iPhone 3G are slower than the iPod touch 2nd Gen, which is also much slower than the iPhone 3GS, and so on.
When trying to access the UIDevice.currentDevice(), it returns iOS Simulator instead of the actual device you're testing. This sucks, since you can't do certain things on the simulator.