PAlib

I’ve been working with two very handy C++ development libraries over the last two weeks: OpenFrameworks and PALib. We started working with OpenFrameworks in the Atelier hypermédia last week — I’ll write more about that later. As for the other library, most of you probably will never have heard of it: PAlib is a library for Nintendo DS homebrew development which I ignored for too long. Antonin told me about it ages ago, I should have listened. It’s been a godsend for getting back into development for the Nintendo handheld platforms. And it’s amazingly easy to use, once you’ve gotten everything configured correctly (see below).

Of course, the library can’t do everything I want. For example, I need some pretty advanced sound capabilities, and I’m not sure the included sound functions — which do seem useable — will be robust enough. I might have to give up that library and switch to another one, or it might be the one place where I’ll have to barrel down into the registers, setup interrupts, deal with FIFO registers, etc. myself. But that’s fine, because everything else is so easy: generate the graphics in whatever — making sure you stay within a limited range of colors —, convert those images using one of the included tools (or make your own using Processing or whatever, it’s pretty easy), load that data into the sprite registers, and then let the DS do all the work: all you have to do is set the sprite’s x and y positions and the DS hardware does all the rest.

I’m still amazed at Nintendo’s hardware style. I always loved how the Gameboy and Gameboy Advance were just tiny little processors, surrounded by all these well-chosen chips dedicated to putting sprites and tiles on the screen, and generating the necessary beeps and boops. I’m all for specialized chips and processors, and I think think they’re going to be even more important as we move more as a society towards serious power conservation. So I love these crazy japanese designs and extreme efficiency. But it also amazes me the extent to which the DS is just a souped-up Gameboy Advance. It’s exactly the same strategy they came up with for the Wii: start with the previous platform (Gamecube), and tack an interesting interface onto it with some minor audiovisual improvements. Also, make sure there’s N64-style 3d graphics capabilities. This of course is great for me: all the original registers that I know all-too-well are still there, but with an added processor for handling the second screen, and new functions for handling Wifi, the stylus, and so on. There are also more sound channels, and even some of the old-skool Gameboy sounds are still hanging around (which is really tempting me right now in the current project). But again, I haven’t gotten around to the sound yet because that’s when the real work starts. For now, I’m just having fun finding new movements for the stylus.

It’s also interesting, after sitting through the (eye-opening) iphone sdk video, and now playing around with the DS touch interface, to see how far we have all come on physical gesturing, no matter what the input format. I’ve found myself adding a lot of iPhone-style touch gestures using the very limited input of the DS, which is very eerie for me, because a lot of these gestures hark back to efforts I made back in the 1990’s (remember when CD-Roms were all the rage?). These gestures take on new meaning for me, now that they’ve been placed into this new historical perspective offered by the Wiimote and the iPhone. For example, a lot of the work I did with Claude Faure (see video) was already playing with the physicality of the interface. This was quite clear to us, even then. But that said, this work takes on new meaning now that all these gestures have come of age — or are simply breaking out in all their pimply pubescent enthusiam (it all depends on how much you like or dislike these new semiotics).

The DS, the Wii, and the iPhone are important indicators on where we’re at on this subject. For example, there was a very prescient moment in the iPhone video (you’ll find it at 00:40:23) where the ‘undo’ function is converted from its previous semiotics of ctrl-z (remember F7=SAVE anyone?) into a simple shaking of the device itself. Okay, okay, I know what you’re thinking — this is just a gadget-geek-moment, a golly-gee-wow somewhere up there at the level of sophistication of the blink tag (thanks Netscape). And probably after we’ve all transformed into premature parkinson’s sufferers after shaking our iPhones all day — with some new neurological disorder similar to what keyboards did with carpal tunnel syndrome —, we’ll have had enough of all this goddamn gestural computing. But I still find it amazing to think that ctrl-z can be transformed so easily into a simple flick of the wrist. The same goes for the game they showed at 00:41:03, « Touch Fighter ». There, the iPhone itself is the joystick — uh, yeah, Douglas, I think that’s what the guy already says in the video — and it will be hard to go back after that realization, just as it is now hard to imaging gaming (and DJ’ing) after having played with the Wiimote.

Anyway, to get back to the development nitty-gritty, how do you develop for the DS from a Mac? Since I explained this already to Benoit this afternoon in the Atelier, I should mention it here for later reference. You need to:

• make sure you have installed xCode (free)
• follow the instructions of either: Nintendo DS development for Mac or PAlib Wiki Mac OS X (the later worked fine for me)
• download this PAlib xCode Project template and install as instructed (this will allow you to create a new PAlib project from the “New Project” menu in xCode)
• create a new project in xCode and “build” it
• find a workable emulator to test before loading the “program.nds” file onto the physical DS (no 100% solutions here — I’m currently using NO$GBA from Parallels running Windows inside of my Mac, since I was too lazy to get any other emulators working on my Mac)
• buy some sort of programmable cartridge for copying your program to the DS