Having just seen the video from the Arm conference where Ricardo talks about some of the improvements to to Cocos2dx in version 3, I thought I’d take a quick look.
First I had to upgrade my version of C++ to 4.7 so I could compile it. Thanks Ubuntu for putting it in a test PPA instead of being generally available. A few apt-* commands later and I’m compiling up the source. At least this time the cmake configuration is much easier to understand. Another recompile after configuring Box2d (why do you insist on making Chipmunk the default!) and the test code is running much faster on my creaky old laptop. Using a later opengl driver has really helped.
The dilemma is should I abandon my previous code and setup and recreate everything in version 3, all the while having to mentally switch between CCSprite and Sprite class names etc. Also a lot of the tutorials are geared to version 2. It might be a bit of a mental stretch too far.
Anyway for now I’ve decided to give it a go and keep up with the latest and greatest. At this rate I might even get out a game before the stable release instead of the beta version.
So I’ll have to go through the same steps again.
All set up!
With thanks to Depeche Mode for the title.
This week I’ve been having a bit of fun with my own Jenkins setup. I use jenkins/hudson at work on a daily basis within our agile processes and thought it might be OK to set my own up for Beadbash.
For those that don’t know, Jenkins is a java based continuous integration server that will automate building, testing and deploying software for you. The power of this software comes from the fact that it has dozens of plugins for all sorts tasks. In my case I needed to
I watched this youtube video first to see what’s possible, then I got started configuring it all.
To make things a bit easier, I decided to install Jenkins on my mac in the office rather than trying to run it on my laptop. This would make doing the xcode build a bit simpler as I wouldn’t need to create a slave server and configure all that up. (I might if I end up needing lots of build servers if I were anything more than a one man band for this project but as this is my first time setting it all up I felt that adding a slave component was overkill.). Installation was painless! Download the dmg from jenkins-ci.org, run the installer package, select the custom options so it would not run as a boot process as a different user and then run it manually using java -jar jenkins.war. That’s enough to get it all running and opening localhost:8080 gives me the start screen.
I then added all the plugins I would need the bitbucket hook, git, testflight, xcode etc. I also took a moment to configure a username and password so I could restrict access and then make it available externally via my firewall.
First pest problem was getting the source from bitbucket. I tried using ssh keys, but my keys always have a password set. I can understand why people create their keys without passwords so services can use them without needing input each time (like apache ssl certificates) but for personal certs I’m not happy just letting them being used. If my laptop was stolen or I lost a backup usb key then all sorts of mischief could be done before I managed to revoke the keys. Anyways’ it seemed that other people had come across the same problem and after a few false starts I found that actually bitbucket would work with just a username and password setup instead of ssh keys. So job 1 done.
Next step was getting my repo downloaded. Because I have both the full cocos2dx tree and then a separate repo for beadbash under projects, I needed to use the multiple SCM configuration and set the second scm download to put the files in a sub-directory. That was pretty straightforward but then I came up against another problem. The cocos2dx repo was too large and Jenkins was timing out before getting the whole repo down. A few searches later and some serious stackoverflow.com reading and I found a solution. I had to create a local bare git repo of the source code and use advanced clone with a longer timeout. This is only a problem the first time the workspace tries to get a copy of the repo as the next time through it only grabs the changes.
Repo sorted, next step was to get xcode to compile the code via the Jenkins plugin. This is where things got a bit hairy for a while. I hadn’t actually tried compiling it natively on the mac, so the first time I tried a build, it failed unable to open the keystore, and dozens of errors. I opened the current code properly in xcode I had a whole lot of fixing to do:-
Add the resources, *.cpp,* .h files to the project. Modifying the linux makefile just doesn’t do it. (Note to self, I’m going to have the same problem when setting up the android build!).
Create the signing certificates in my keystore. This is the bit of voodoo that I still don’t understand fully but xcode takes care of it for you when developing. When releasing an app to the app store, then you need to create a new certificate via the apple connect interface and apply that to the .ipa package anyway so that’s fairly straightforward when the time comes.
There are a lot of deprecated warnings that I’m not going to fix just yet but will probably mean I need to upgrade to cocos2dx-3 at some point when it becomes stable. Perhaps someone will write a migration tool at the same time else I’ll have to get busy with sublime doing a lot of search and replaces.
So after several false starts, I’ve got the app to build.
The final step for this setup was to get the app deployed to my phone via testflight. This is where things got much easier. I already had a testflight account so I could grab my api keys and plug them straight into the Jenkins Plugin. A few settings later and its ready to test.
I did run into one problem which is that testflight searches the whole repo for apk’s and ipas to upload – which then also included some stuff in the cocos2dx which I didn’t need. So I fixed that by being specific to the android and ios project directories for beadbash.
A few nights work and now I’ve got a superb system for delivery to testers! Write the code, push it to the repo. Jenkins will check once a day (unless I kick off a build manually) if the repo has changed and if it has will build a new version of the code, push it to testflight and an email automatically arrives on my phone with a link to download and install the new version. Slick.
So after a lot of mucking around I now have coverage working – the next step in getting my TDD groove together.
It took a while to get to that point, because as soon as I added the flags to the makefile to enable coverage, I found cocos2dx had been compiled up by default for Chipmunk physics and not Box2D, which is what I want to use.
Just a quick rant. I wanted to add coverage logging information for my unit test stuff. So I add the flags, only to find out that libcocos2d extensions library is not compiled correctly.
Now I’m just repeatedly fixing coding errors in their tests. Grr.
I’ll be back with real info on setting gcov, lcov and getting code coverage in general soon.
Yes it begins, I’ve restarted my blog, and I’ve started developing a game idea. There I’ve said it and announced it to the world!
I’ve written native iOS, written bits of java and bits of C,C++ over the years for different projects and for this one I decided to try out a few frameworks. My preference was for something that would be cross platform so I didn’t have to fully program in java for Android, and fully do iOS etc. After a brief bit of time playing with lua systems like corona, gideros and moai I found them either closed or restrictive and not as hackable as I’d like.