OpenGL ES -> _OES suffix - xcode

I'm interested in learning OpenGL, so I started reading the book 3D programming for iPhone by O'Reilly. And guess what, I got stuck at the first exercise.
Even though I followed the guidelines, my Xcode application won't allow me to use the _OES suffix in the functions glGenFramebuffers and glGenRenderbuffers.
I did some research, and it appears that this is related to the 2.0 version.
However, I did in fact add both:
#import <OpenGLES/Es1/gl.h>
#import <OpenGLES/ES2/glext.h>
and the added OpenGL framework also includes the header files for both ES 1 and 2.
So I did some more research, and downloaded the project that I found in this thread:
Example from Chapter 1 of iphone 3D programming book not drawing to screen.
When I run it in my Xcode, it works.
I don't see any difference between our projects, so why does the _OES suffix in fact work for him and not for me while using the same version of Xcode? I even copy - pasted his code into my own project, but my Xcode project won't allow it.
Well, I don't get bugs either by just leaving out the _OES suffix, but I only get a black screen when running the app so it must mean something is wrong.
As a second problem is also that I get a lot of linker errors when I try to run the app on the iPhone simulator; I don't get these errors when I try it on my iPad. And I don't get these linker errors on my simulator when I use the downloaded project; it works for both the simulator and my iPad.
I'm terribly confused, has someone an idea what could be the cause of all this?
I'd like to continue, but I'm stuck :-) Thank you very much for your attention and help!

Related

Should I start making apps with Xcode 6 or 5.1?

I was starting to make simple iPhone apps using online tutorials and books and then I realized that I upgraded to OS X Yosemite and can only download Xcode 6.1 and all the tutorials are based on Xcode 5.1. I can't learn anything with Xcode 6 since there aren't many tutorials out there for Xcode 6. Can someone please suggest me what to do? basically I'm trying to learn objective-c but before learning objective-c I'd like to make a simple app through tutorials and get the hang of Xcode and learn further..
don't worry, proceed with the current version. Any differences will be made obvious by compiler warnings or errors, at which point you can deal with them. This might be considered preferable to learning to do something in a manner which is no longer current

Fixing old cocos2d project on iOS 7

I've created an iPhone game which utilizes some code from an old version of the Cocos2D iPhone game development framework and I've got a wee bit of a problem running it on iOS 7.
The version of Cocos2d from which the code was used was probably 0.98.
The actual class is called QuadParticleSystem (in newer versions it's been deprecated by CCParticleSystemQuad).
The actual issue is that the game runs fine on iOS 6 and below. It even runs fine on iOS 7 if the deployment target is set to iOS 6.0 and SDK version set to 7 (at least when put on the device directly using XCode).
The problem is that when the game is uploaded to the appstore, Apple seems to strip out the whole iOS 6 compatibility thing and the particle emitters fail to show up among other things like alpha transitions, invisibility etc.
(They initialize correctly and everything, but they simply DO NOT render).
I've considered (and tried somewhat) upgrading the Cocos2D version, but due to the old third-party frameworks I've used for other things there is a hell of a lot of linking/dependency/deprecation errors which could take forever to fix (if it's at all possible, which I doubt) In other words, I've wasted too much time on the project already and am looking for a quick fix.
If no one knows any solutions could anyone at least direct me to docs where I can see how to create/insert a new particle emitter system in the existing code?
I've thought about using SpriteKit's native emitter system, but I don't know how to incorporate it within the current code (as I've never had dealings with SpriteKit) and am not sure if it's even possible.
I've also thought of maybe upgrading the GL ES framework within that old version of Cocos2D just in case Apple have killed off some functionality of older versions of OpenGL. Then again that could take a while.

What does The destination does not support the architecture means?

I have the same problem with Xcode Cannot Run on the Selected Destination
The destination does not support the architecture for which the
selected software is built. Switch to a destination that supports that
architecture in order to run the selected software.
I tried the solutions there and it doesn't work.
So I'll try to do something more reasonable.
What does the error means anyway? What is Xcode trying to say when it says to switch to a destination that supports that architecture? Where is the archtecture specified? What software? What is the problem?
While solutions may be nice what I am looking for is understanding of what it really means.
The project used to work
The project still work in real iPhone but not simulator
I used the newest facebook SDK. However, it run before even after the SDK. It's after I clean project it doesn't work.
While I don't have a solution for your problem, I can answer your question, namely, what does Xcode thinks is wrong and what does the error means.
So, the destination is actually your simulator in this case (could be the iPhone as well, if you're building for it). The architecture is decently explained here. What you need to understand is that in order for a software to run on a specific architecture it needs to be build for it(or assembled for it, to be more precise). That means that for the same software the CPU instructions are not the same for an iPhone (which has an ARM CPU) as they are for your iMac (which is x64).
Now, with the above in mind, what Xcode is trying to say is that you are trying to build the wrong architecture for your simulator and you should switch to a different destination that supports that architecture (as you mentioned, you can build just fine on the iPhone, which is a different architecture) in order for the software to run.
It could be an Xcode bug or a misconfiguration. You're probably better off creating a new project and copy all your classes into it than hunting it down.
You'll be happy to know this problem has a very simple solution. Select Info.plist in your project navigator tree and make sure it is not assigned to a target. I have confirmed this is the correct solution. If building for iOS 6 or earlier you may also need to add armv6 to supported architectures

Setting up Xcode to work with SDL?

So I know C/C++ but I'm having so much trouble setting up SDL to work with XCode so I can start making actual applications. I've looked at tons of tutorials on the web, but they always have a part or two that make no sense what so ever in them. For example, a lot of tutorials say to download the Mac runtime and development SDL libraries, but there is no development library for the mac, only runtime. So I was hoping that the lovely people here could step me through the setup.
The following article shows how to work around the lack of SDL project templates for Xcode 4:
Using SDL with Xcode 4

iOS: 4.2 or lower must include ARM6 object code? [duplicate]

In iOS5 Apple drops the armv6 architecture from the ARCHS_STANDARD_32_BIT.
In order to keep the support for iPhone3G I still want to compile in armv6 even in iOS5.
Did anyone find a solution for this?
I just built something today specifying a deployment target of iOS 4.0. With only armv7 specified in Architectures, Xcode warned me that to support anything below iOS4.2 I had to include armv6 in Architectures. Just edit that field, click the "+" button when the dialog pops up and enter the literal "armv6".
In my case, we want our app to work under iOS4 and iOS5. We had to make some modifications so it would work correctly under iOS5, but all those changes were done with iOS4-friendly code changes.
We also added some iOS5-specific capabilities in a manner that allows the app to run without crashing under iOS4. Specifically, we tested for iOS5 capabilities before trying to use them, and linked iOS5-only libraries as Optional.
So, supporting iPhone3G in an iOS5 world could just as easily mean "we want our app to run on iOS4 and above (regardless of any iOS5 feature use)" rather than "we want to make sure our app runs on an older device running iOS5". There's a difference here; think about it. :-)
Anyway, adding armv6 support back in is very easy. And I guess the point is this: At some point, when there are no more armv6 devices out there to worry about (for whatever reason) you won't have to build for it. Apple's view is everyone should upgrade to the latest hardware as soon as possible. So in that world, there is no need for the tools to default to anything but the latest and greatest too. :-) Fortunately (or not), we developers live in the real world and recognize that you have to support older stuff for a while. And I guess the Xcode dev team knows this too, which is why you can add armv6 support back in quite simply.
The simple answer is that you have to change the current settings from "Standard (armv7) - $(ARCHS_STANDARD_32_BIT)" to just be "armv6" and "armv7". See the image below. You have to delete the line with the previous settings for it to work.
also make sure you set this in Project AND Targets ... cost me an hour to figure that out. had set it for one but not the other. hope this helps. GLTA
I think there's a reason why Apple dropped armv6 from the standard setting.
I have compiled armv7/armv6 with iOS5 SDK, however, the armv6 compiler produced wrong code in release mode. After hours of finding a workaround (trying llvm or gcc with different optimization levels) I give up.
So, I am going back to iOS SDK 4.x as long as I support older armv6 devices.
Example of code:
// myView center=(160, 100)
CGPoint p=myView.center;
// now p=(100,100) (what the heck?)
p.x=myView.center.x;
p.y=myView.center.y;
// now p=(160,100)
p.y+=100;
// now p =(200,200) (what the heck?)
Maybe I'm have some memory corruption, however, on the armv7 compiler and on iOSSDK < 5.0 it behaves as expected.
Best regards
Not sure if this is actually a solution yet, but I have discovered that replacing the defined string in "architectures", which was $(ARCHS_STANDARD_32_BIT), with "armv6 armv7" allowed me to compile with iOS5 as a base and iOS4 as a deployment target, and pass validation .
I am not using any IOS5-exclusive libraries or calls, but intend to in my next release.
I did not need to replace $(ARCHS_STANDARD_32_BIT) with just armv7 for the app to compile and be uploaded to the App Store.
As suggested by MarkGranoff, I simply added armv6 as plain text, by hitting plus and just typing it in on line two.

Resources