This will be a more in-depth version of my other writings on BlackBerry PlayBook Development ereafter referred to as PlayBook] which is located here.A few weeks ago I won a PlayBook by entering a developer survey linked over on GamaSutra. As I submitted the form, I noticed that the competition was only valid for the Americas and Canada. Damn, I already submitted! A few weeks later, what I thought was junk mail pologies to UBM's Jennifer Sulik!] appeared in my inbox. I handed over my address and received the PlayBook in a week (well, two weeks, as customs had their way with it -_-). After paying £50 in taxes it was mine! Still better than paying £180 s of this writing] for the same model. Plus it was a unit won in a survey so I got extra points in my mind =P.Anyway, now that I had received my PlayBook, I proceeded to spend half an hour kid you not] opening the box, then the box the PlayBook was in, then the box that contained the charging cable and USB adapter. After reading the manuals (very thin ones =/) and pressing the power button (I have the one with a raised power button as opposed to flush) I was greeted with a rather nice splash screen. If you look up some videos on the PlayBook 1.x booting, that's what I went through, plus the ~600MiB upgrade to 2.0. This left me with 10GiB to use for programs (not 'App(s)', and I make a point of capitalising the 'A', otherwise I'm fine with the term app(s)). Which is a fair amount of space. A better situation than the Original Xbox Development/Debug Kit space of 4.7GiB, being pretty impractical, almost fully requiring you to send all of your development data over the network (this will probably be the route I'll take with the PlayBook due to it being NAND storage).I had worked a little bit with the PlayBook simulator earlier in the year (a day before 2.0 was launched), which was fine. The only problem is that I didn't want to use the default Makefile layout and it seemed like I'd reach a point where x86 and ARM compilation would be a problem with QCC, as in it may have been way more involved than I thought. It really wasn't =P. I'm still working on my template for Simulator and Target compilation, so far it has been pretty smooth. On top of that, I spent two days trying to get GDB (ntoarm-gdb) to work with my PlayBook. It turns out to be a bit more involved than I originally anticipated. I checked everything I could to see why launching from GDB was a problem, only, that is the problem. Instead I should have used:$ blackberry-deploy -debugNative -launchApp -package Program.bar $PLAYBOOK_TARGET -password $PLAYBOOK_PASSWORDThe -debugNative flag was the crux to the whole thing. After just running all blackberry-* tools with no arguments passed in, deploy came up with:-debugNative - hold native application immediately after the spawn to allow native debuggingI then thought that I'd have trouble getting the PID, luckily a string: "result::IDNUMBER]" comes back. Using grep and sed, the PID was piped out to a file with other GDB commands so that I could just run:$ ntoarm-gdb -command=gdbrunThe file contains three lines, which are:target qnx 192.168.1.69:8000sym ./Programattach 24682651The IP address, sym file and PID are all created from environment variables and the PID file. So they're always up-to-date and correct. I will be uploading the finished project to my website, there will probably be a Mercurial project for it, which shall be located at: https://hg.interactivelaboratories.com/index.cgi/playbook_templateCurrently, the Makefile (which doesn't compile, I did that just by invoking QCC) looks like this:## Makefile for BlackBerry PlayBook Template Project## Date: 03|04|2012# Check for environment variables that should be setifeq ($(strip $(QNX_TARGET)),)$(error Please run: $$ source /path/to/bbndk/bbndk-env.sh to set up your environment variables )endififeq ($(strip $(QNX_HOST)),)$(error Please run: $$ source /path/to/bbndk/bbndk-env.sh to set up your environment variables )endififeq ($(strip $(QNX_CONFIGURATION)),)$(error Please run: $$ source /path/to/bbndk/bbndk-env.sh to set up your environment variables )endififeq ($(strip $(PLAYBOOK_TARGET)),)$(error "You need to define your PlayBook's IP Address. Use: export PLAYBOOK_TARGET=<IP address>")endififeq ($(strip $(PLAYBOOK_PASSWORD)),)$(error "You need to define your PlayBook's password. Use: read -esp 'Password: ' PLAYBOOK_PASSWORD Then enter your password.")endifTARGET = TemplatePIDVAL = 0# Just for the deploy target (otherwise the password is visible).# This will be adjusted later to apply only to the deploy target..SILENT:## WIP Mainly just testing gdb and deploymentdebug: TARGET := $(TARGET)debug: $(TARGET)release:profile:deploy: blackberry-deploy -debugNative -launchApp -package ../Bin/$(TARGET).bar $(PLAYBOOK_TARGET) -password $(PLAYBOOK_PASSWORD) | grep result:: | sed 's/result:://' > pidgdb: deploy echo target qnx $(PLAYBOOK_TARGET):8000 > gdbrun echo sym ./$(TARGET) >> gdbrun printf "attach " >> gdbrun cat pid >> gdbrun ntoarm-gdb -command=gdbrun$(TARGET):Now I'm considering adding tags for code to my web log system =D. It's pretty simple and I have yet to add support for the Simulator as well as packaging and signing applications, and adding Debug tokens. The only reason I'm not using the default QNX make files is because they're kind of cumbersome to go through. I'm not sure how to customise it for my directory layout, either. It's probably not too hard to do but this way I think it will work out much better. Going with the default files means that there's little chance of anything breaking. That being said, I doubt anything will change too much to cause everything to break. BlackBerry PlayBook Development [ May | 07 | 2012 | @847 ]
I just spent a good part of one week plus three days getting animation curves from Maya after a pretty long break from learning any kind of new Maya API classes or functions. In itself the API is not difficult, nor is the concept of Attributes, Plugs, the DAG, or anything else like that. The difficult part, for me at the least, was getting everything to click and make immediate sense so that I knew exactly what to do. Iterating over the IKs, getting the Point Constraint(s), the target from the Point Constraint, then the final AnimCurve from the MObject's translation's plugs suddenly made a whole lot of sense. As of right now the whole Assembler project looks like a lot of scattered code, which I'll be commenting and cleaning up over the next few days, here and there.Now that the animation curves are being exported properly, I can work on the actual animation side of things. IK animation shouldn't be too hard, right? ;PI can't take all the credit for figuring out the Maya API, the documents do help =P. As does Rob the Bloke's site - http://nccastaff.bournemouth.ac.uk/jmacey/RobTheBloke/www. The Maya API [ February | 25 | 2012 | @041 ]
For anybody interested:The documentation for ZED is located here: http://docs.interactivelaboratories.com. I will make it conform to the current theme, for now it's a very quick and dirty web page. Also, it's only currently the DoxyGen, other documents can be found at the FTP site: ftp://interactivelaboratories.com. the FTP site can be viewed by Windows through Windows Explorer in+E] on the keyboard, then paste the URI given. Linux users can use the ftp:/// directive for viewing the FTP site through a File Manager.As of right now I'm concentrating completely on the Windows x86 32- and 64-bit builds until I have a solid base on which to build the rest of the engine. As time goes on, I'll still work on Linux, Xbox, and Pandora versions, but I have to concentrate on one platform at a time. Otherwise there will not be much to show until a year or two from now as development would have to occur in parallel rather than serially to get all features running on all platforms at the same time.Anyway, I'll be working on an animation technical demonstration for a while. Documentation [ January | 26 | 2012 | @918 ]
Well, this is awkward. I have been (and still am) maintaining a web log at GameTrailers since 2006. It's pretty much the only web log I've been updating. Here I'll be posting about new projects, project updates, and interesting topics that are relevant to the game industry.I'm considering creating a per-project web log, too. Just so this one doesn't get cluttered and project-specific entries are easier to locate. All projects can be found at: https://hg.interactivelaboratories.com.Username: GuestPassword: <No Password>All projects on the Projects page also have links to the Release, Browse Repository, and Source. Release and Source are .tar.gz files, so if you're on Windows you'll need 7-Zip to extract the files. You can get the project from the repository with:$ hg clone https://hg.interactivelaboratories.com/index.cgi/<project> <Local/Directory>Replacing <project> with the project name (case-sensitive) and <Local/Directory> with whatever directory you're cloning the project into. Welcome [ December | 11 | 2011 | @794 ]