There’s an engine I haven’t seen before, Minko. Cross platform, free and open source, is Minko worth a shot? Maybe. One thing that’s not very clear from their blurb is whether they mainly target HTML5 or if we can run native iOS apps (seems like the latter). Minko looks C++ centric but… okay.
One good point (from a coder point of view) may be that, in their own words “ the world editor (Minko Studio) and the 3D engine (Minko Engine) are two separate things”
Seems like we have a candidate for the first public release of our OpenGL-ES2/3 engine, O-C3D.
I set the following requirements for this library:
This library powers the latest release of our new iPhone/iPad game, Darwin’s nightmare (aka The Strain)
SVN repository: https://xp-dev.com/svn/oc-es3/trunk
The package includes:
In a coming article I will explain how the demo project was setup.
This is not a Game Centre integration tutorial, but includes useful notes that can help you troubleshoot your GC integration.
Confusion about network connectivity
Some developers seem to think that the game centre sandbox is ‘local’ because GC will accept submitted scores and authenticate users while devices are offline. GC sandbox is definitely a hosted, network-enabled service. AFAIK what happens is
Issues with multiple leaderboards:
When setting up multiple leaderboards, it can take time for all the leaderboards to show in the game centre widget. This is what I observed:
Issues with opting out
After logging out of an app 3 times, it appears that a game is opted out of game centre. This rule applies to sandbox builds.
How to opt back in to continue testing? Apparently the only thing that does the trick is re-setting the settings of the test device. Inelegant maybe, but at least, it works (See the SO item here).
Caveat: After you reset the device settings, remember to log back into your WIFI network.
Quick notes for drawing point sprites:
If you forget to disable GL_BLEND after rendering your sprites, unexpected results may occur…
In ES 3.0, 2.0, you can draw lines of variable thickness. Somewhat surprisingly glLineWidth(GLfloat) is still supported. It appears that glEnable(GL_LINE_SMOOTH) is deprecated since ES 2.0; consider using MSAA (or maybe a dedicated shader) to support line antialiasing.
Check Jay Fuerstenberg’s blog for a workaround.
If, like us, you have a rendering API based on OpenGL ES1, you should start feeling… uncomfortable. Additionally, as I accumulated knowledge about 3D rendering, I think that the design of our rendering engine is outdated.
There are not many resources out there for learning OpenGL-ES3, so I will try to track my progress on the blog.
OpenGL-ES3 is backwards compatible with OpenGL-ES2. To learn about the latter, I recommend Philip Rideout’s “iPhone 3D programming”, available online.
Migrating from OpenGL-ES1 to OpenGL-ES3 is not a trivial matter. So I will attack the problem from several angles:
Apple provide an introduction to OpenGL-ES on iOS. Recent documents may require an apple ID.
In XCode, selecting new project, we find “OpenGL game”. As well as providing a stub for new OpenGL-ES applications, this doubles as an example featuring spinning, shaded cubes. As such it is comprehensive:
This is a ~400 lines program, running like this:
Ray Wenderlich describes an alternative setup on his blog.
I will not cover this template in detail here. I started refactoring the template to create a simple (yet usable) renderer.
Upgrading to XCode 5 is causing me headache; our setup for unit testing, migrated from XCode 4, doesn’t work.
“RunUnitTests is obsolete”
In XCode 4 (and earlier), the TEST_AFTER_BUILD flag allowed running tests after building a test target. In XCode 5 we receive the following message if the flag is set to YES:
error: RunUnitTests is obsolete. To run unit tests for your target, use the Test scheme action in the Xcode IDE and the test action in xcodebuild.
So, we have functionality that is now phased out, and we are left with concise hints regarding alternatives:
The run destination My Mac 64–bit is not valid for Testing the scheme ‘SCHEME_NAME’.
The scheme ‘SCHEME_NAME’ contains no buildables that can be built for the SDKs supported by the run destination My Mac 64–bit. Make sure your targets all specify SDKs that are supported by this version of Xcode.
Sadly, this makes sense. We have libraries (and tests) built for iOS (checking ‘Architectures’ in build settings), so we’d have to do some (re)configuration to get this to work on OS X. The question is: how did it work before?
I can live with this for now.
Calling xcodebuild after running a build?
Pre/post-actions won’t do
Under ‘edit scheme > build ‘ (unfold it), we find ‘Pre-actions, build, post-actions’. I’m hoping that I can run xcodebuild using a post-action. While not ideal (for lack of integration with… xcode) I don’t have a better idea at the time.
It took me a while to convince myself that pre-post actions are actually being run. A comment on SO explains why:
“In Xcode 4 [and 5] you could run this script as a pre- or post-action script on the “Archive” action. However, pre- and post-action scripts are not considered part of the build itself; their output is not part of the build log, and a failing script will not cause the build to fail.”
( http://stackoverflow.com/questions/5471396/running-script-only-for-an-archive-build-in-xcode-4 )
This is no good. I don’t just want to run tests and get no output, let alone have broken tests go un-noticed – quite the opposite.
adding a build phase
So, instead of a post-action, I added a build phase: editor > add build phase > add run script build phase. XCode doesn’t hide the output of a custom build phase. Additionally, running tests as part of a build phase is actually helpful:
My build phase script is simple, looking like this:
xcodebuild -workspace MY_WORKSPACE.xcworkspace -scheme MY_SCHEME -destination ‘platform=iOS Simulator,name=iPhone’ test
where DIR is the directory containing the target workspace.
Yea that’s it. But there is a caveat. You probably can’t include this as part of the build action for the project that you are testing. This is because the test action tends to invoke the build action, causing recursive invocation of the test action and build action.
I’m guessing it could be done using an additional target in the same project. Because the project realising our app does not really contain code, what I do is add the custom build phase to that, calling xcodebuild for every library needed by the app.
Pending a merge of my related articles, I put together related info and also include interesting finds related to unit testing and setting up linkages.
The ‘symbol not found’ error: setting up linkages correctly
This typically includes:
This means that you may encounter this error several times, and fix it in a variety of places. Say you have the following workspace:
Assuming that FunkyStuff uses a class in Base, I have highlighted places where you probably need to add a dependency.
More linkage errors (important!)
Beyond the above, typically you have setup a workspace and sooner or later you’ll run into cases where you make a change in the library source code, but can’t see the result when running your app unless you do a full clean and rebuild (this is an awesome productivity killer) . I found two SO items that are rather helpful in this case, and they’re probably not the ones everybody’s looking at:
Setting up for unit testing
While XCode kindly creates a unit test target for you by default tests will not run when you want them to: unless you have some kind of continuous integration setup (if so, why are you even reading this post?) you want tests to run whenever-after the library is built.
I’m still wrapping my head around exactly what all the related buttons and fidgets do, in the meantime here’s a couple of things that work well: