Waxing Rhapsodic

This was a week to remember the good ol' days. The early archives of Computer Gaming World was released to the public, harking its imminent rebranding. Be sure and check out the ads... Apple II, DOS 3.2 required. John Romero released the source for all the Quake maps, allowing us to see the actual art and design of each level before it was BSP-fragged. And my vote for the longest running easter egg goes to Nintendo's Totaka Kazumi.

Nvidia's CPU

Now that ATI and AMD are one, Nvidia is working on a CPU as well. There are a lot of people saying they're working on a "GPU on a chip," but I seriously doubt it. It seems a lot of people are wagering this will go toward the embedded or low-power market, just like when VIA acquired Cyrix. But to do so would be extremely narrow-minded of ATI and Nvidia, even considering the boom of embedded devices and the increasing horsepower needed by set-top boxes.

I'm much more inclined to think that Nvidia is working with Intel (which would be a huge surprise, considering how they've been fighting with SLI on nForce vs. Intel chipsets) to compete with AMD & ATI working on bringing vector processing units to CPU's.

I incessantly bring this topic up, but I had to mention this since it seems that my predictions are actually going to happen. I don't necessarily think this will cause GPU's-on-CPU's to happen, although it might be a by-product. Instead I think this is going to allow for increased parallelization, faster MMX instructions (or 3DNow! if that's your taste) and a movement of putting the work of those physics accelerator cards back on the CPU die.

We may see a CPU with four cores, each with integer and floating point units then a handful of separate vector processors (a la IBM's cell) along side them. Given how the Cell reportedly absolutely sucks for many types of algorithms, this may give developers the best of both worlds. Rapidly branching and conditional logic can be done on the integer units with branch prediction and short instruction pipes while long, grinding algorithms can go to the vector processor. This has already worked for projects like Folding@Home, and could work for many similar algorithms.

Or AMD/ATI and Nvidia could just go for a stupid, embedded GPU's sitting on die with the CPU. But they'd be passing up something much cooler.

ODE to Qt

I've been working on a small game with Qt and ODE - both cross-platoform APIs that are GPL friendly. While I'm still trying to decide whether or not I like Qt's cross-licensing, I'm definitely sold on its ease of use and elegance of design. And ODE has been great so far... a lot of trial-and-error and late on the 2D scene, but released with a BSD license which makes it very easy to use.

AI Modelling Clay

Physics sandboxes have let us play with tossing objects around, particle interactions and launching things across the room. In-game character and model generators let users have fun creating caricatures of ourselves for avatars. So why not have AI sandboxes that let us create weird and wacky AI patterns?

linux.com recently turned me on to N.E.R.O., an interesting title from a university class written with the Torque engine and the open-sourced real-time NeuroEvolution of Augmenting Topologies (rtNEAT) library authored by Kenneth Stanley. If nothing else, it shows why AI can be hard and why current AI in FPS' doesn't seem to "get it" all the time.

Think Moster Rancher meets Creatures and you can kinda get an idea of the attraction. It's definitely in a new "sandbox" genre of its own. It's worth at least 15 minutes of your time... and a free download. The tutorials themselves are worth it.

To Brew or Not to Brew?

After my recent addition to the family, I've been flogged with writing papers, doing research and trying to emerge as the Prime Minister of Uptime at work (and failing). But I've also been in the midst of a life-affirming decision: to hack my new DS or not to hack it?

Allowing execution of unchecked code isn't as heinous as it was initially - evidentally gone are the days of reflashing one's DS in order to skip the cartridge validation. Now all you needs is one cartridge that passes itself off as "verified" and then allows arbitrary file execution from another source, a second GBA cartridge to act as a flash memory reader, some type of removable flash memory such as MicroSD, and a flash memory interface for one's PC to upload applications to said removable flash device. No more toothpicks wrapped in tinfoil, no more hoping your DS doesn't get bricked. If you're willing to spend yet another $150 you can have a DS that runs homebrew software.

While there are some compelling reasons to run homebrew, I've decided against it. Doubling the price of my DS Lite just isn't worth it, even though the idea of writing software that would run on my DS does give my spine a-tingle. I could argue I'd rather not support cheaters who mod ROM's or warez thieves who distribute them... but that's not necessarily it either. I have this major hangup, where adding too much hardware or doing too many work-arounds because a splinter in my mind. When you have to re-engineer so many things, it becomes too inelegant to be pallatable in my mind.

Now I've seen the DS Lite flash drives, and how they seamlessly merge with the base unit. Truly, a modded DS can be indistinguishable from an unmodded one. But the fact that someone would have to pay double the price for a modded DS is just too much.

That doesn't mean, however, I'd absolutely love to find a way to author my own DS cartridge. If I could find a way to produce a standalone DS cart and upload software to it, I'd be all over that in minutes.