Bought a GP2X

I splurged on a GP2X (the open-source handheld game/entertainment console) the other day, and it arrived today in the mail. I also went ahead and bought a couple accessories at the same time: the TV-out cable, a USB-SD card reader, and the GP2X “cradle” (which will allow for connecting USB controllers, if I figure out how to get the darn thing to sit right).

I was under the mistaken impression that either the device itself or the cradle would come with an AC/DC power adapter cord, but that’s not the case. Luckily, a quick trip down to Radio Shack to grab a “Digital Camera Power Adapter” solved that issue (although I hope to find my AA battery charger around the house somewhere…).

I also picked up an inexpensive 2GB SD card for storage—an SD card is really a necessity for any substantial usage of the GP2X. All told, I’ve dropped almost USD $300 on this little adventure.

I am “cautiously optimistic” about the potential for this device. The hardware isn’t nearly as ergonomic or solidly-constructed as, say, a Nintendo handheld, but everything seems to work. I can’t say my expectations for quality were terribly high, anyway; I knew it was a risky purchase, but it seems to have paid off. Anyway, what it lacks in craftsmanship, it makes up for in ease of development for homebrew software.

In fact, a Rubygame user had already ported Rubygame-1 to the GP2X in January 2006, and I downloaded and ran it today on my own GP2X to check for myself. It sure was nice seeing those silly pandas spinning and squishing on a handheld device! Nearly any Rubygame app that works on the PC should work just fine on the GP2X, although probably with some changes to the player controls. (“If there were any Rubygame apps, that is!”, he says with a wink and a nudge.)

I’m hoping to ‘officially’ support Rubygame on the GP2X for future versions, and possibly add some GP2X-specific features, such as dimming the backlight or changing the CPU clock speed.

Not cleaning up Instiki after all.

Creating a new project with Rails: fun!

Cleaning up someone else’s existing, out-of-date, and not very Railsish project: not so much.

Instiki is a nifty little app, and it definitely gets the “Instant” and “Wiki” parts right, but it leaves much to be desired: no proper user login/authentication, no preview on edits*, a clunky (if I could get it to work at all) file upload system, no page renaming or redirects, etc. (* On the other hand, I _do_ like the fact that you have a 30 minute grace period to make more changes, without it counting as a second new revision.)

Typo (this blog software) has everything Instiki is missing, but is missing everything I need Instiki for. That is, namely, the ability to jot quick, interlinked notes—that whole wiki thing. It just takes too much effort to make a new post with Typo (too many screens to go through), and there’s no handy way to link between them to build up a web of related notes or articles.

If I had a magic alchemy bucket, I’d throw Typo and Instiki inside (and sprinkle a little Flickr on top) and come out with the perfect application to suit my needs. (Unfortunately, I lost said magic bucket in a wrestling match against a walrus. Don’t let their lazy appearance fool you: they’re feisty devils!)

Given how much fun it is to make a new app with Rails, though, I’ve been working on my own blikimajig software. Yeah, I know people always say, “Don’t reinvent the wheel; you should just improve the existing stuff.” But that’s one of those things that everybody says you “should” do, but almost nobody actually does. Besides, if no one ever redesigned the wheel, we’d be driving Flintstones-esque cars with big stone rollers instead of proper tires, right?

Then again, this is the kind of thinking that made me start Rubygame over two years ago… which may or may not be a good thing, depending on how you look at it.

We’ll see.

Cleaning up Instiki

I’ve been cleaning up Instiki for the past couple days.

Actually, I don’t want to be cleaning it up, I want to be extending it. But I figured before I extend it, I should make sure all the tests run. That way, I’ll know when I’ve broken something with my bumbling around in Rails.

Instiki comes packaged with a vendor rails, but it’s an oldish version, so I got rid of that nonsense—who needs old versions, anyway? Pshaw!

So now I’m running the tests, and fixing things that the newer Rails doesn’t want, like using @flash and @params (use flash and params instead), or end_form_tag, or assert_template_xpath_match. Deprecated, deprecated, deprecated!

Eventually, I’ll clean up enough deprecated code that I can actually read what the real errors are. Bleh.

Looking at Rails

I picked up “Agile Web Development with Rails” yesterday. Despite using ruby for over 3 years, I have not up until this point put any concentrated effort into learning and using Rails. I’ve been running (or rolling, as it were) through the tutorial, an online bookstore app.

By and large, the impression I have so far of Rails is that it’s very convenient. It seems like Rails has built-in just about anything you’d want to do—at least, in the limited domain of database-driven web applications.

As I learn more and more about Rails, I can’t help contrasting it with Rubygame. It has been somewhat humbling, but also motivating.

There are rather different design philosophies at play between the two projects; of particular interest is Rails’ notion of favoring “convention over configuration”. In Rails, it’s extremely simple to do things, as long as you follow the conventions that are in place; if you want to do something outside of the conventions, it takes a bit more work.

Rubygame, on the other hand, tries not to make any assumptions about how it will be used (or, so I tell myself). I want to encourage out-of-the-ordinary applications; I hope to see some really cool and weird applications coming out of it. As a result, there’s no assumption that you will want to make a tile-based game, or an RPG game, or will want to use images loaded from files, etc. It’s open-ended.

Rails has a well-defined and highly-encouraged structure to it. Rubygame lets you build your own structure (or forces you to, depending on how you look at it).

There is a definite appeal to the structured approach of Rails: everything has its place, and it doesn’t take much guesswork to figure out where that should be. With Rubygame, you have to decide for yourself.

So, should Rubygame be more structured? Should it assume that you’re going to organize your code in certain ways; that you will need certain types of classes and objects and elements?

Perhaps this is a spurious comparison. Rails is a framework—Rubygame is a library. Someone could build a structured framework using Rubygame, but I’m not sure it’s appropriate for Rubygame itself to enforce structure. Still, there may be some aspects or qualities of Rails that would be useful in the context of Rubygame.

It’s certainly something to think about.

Picking apart Rubygems and Rake

I’m prepping for the 2.0.1 release of rubygame, which includes a number of bug fixes and improvements under the hood, especially in the way method arguments are processed in C methods. All the code is ready and waiting to be packaged up, but I’m tinkering with the Rakefile to make it play well with Rubygems, especially on win32 platforms.

In the 2.0.0 release, there were some snags supporting win32 users. The precompiled binaries were packaged up in gems so users wouldn’t have to compile rubygame for themselves (this is more of an issue on win32 than on linux, which has the GNU C compiler available as a general rule). Unfortunately, the gem didn’t work correctly for all users: despite the precompiled binaries being present, the Rakefile didn’t think they had been compiled, and would throw a fit when it was unable to compile them for itself.

The problem seems to be that some ruby installations on win32 expect dynamic libraries to have the .so extension (in *nix fashion), while others expect .dll (in win32 fashion). The libraries in the rubygame gem end with .so, but the Rakefile takes its hints from the ruby installation’s config: on some systems, it would be looking for .dll instead!

My first thought, then, was to have the Rakefile rename the libraries at install-time to conform to the system’s expectations. Even though they have the .so extension, the libraries are win32-style DLLs inside, so I don’t expect ruby to get confused when it tries to load them (it seems to ignore the extension anyway).

But here’s the catch: when using rubygems, the install task isn’t run. I had read online somewhere that rubygems expects the Rakefile for compiled ruby extension to respond to two tasks: extension (for compiling) and install (for installing to the appropriate directory). It turns out, though, that it presently only uses the extension task. (This I discovered only after rummaging through the source code for rubygems last night.)

Fortunately, this is not a big problem, because I can prepend a fix_filenames task as a dependency of the extension task, right before the build task (which compiles the libraries if doesn’t see that they have already been compiled):

1
2
3
4
5
6
7
8
9
10
11
12

desc "(Called when installing via Rubygems)"
task :extension => [:fix_filenames, :build]

task :fix_filenames do
  Rake::Task[:install_ext].prerequisites.each do |prereq|
    prereq = prereq.ext('so')
    if File.exist? prereq
      mv prereq prereq.ext(DLEXT)
    end
  end
end

This takes each of the prerequisites to the install_ext task (each prereq is a String pathname to a compiled library file), checks whether the file exists with a .so extension, and if so, renames it to the system extension for dynamic libraries (DLEXT is derived from Config::CONFIG[‘DLEXT’]).

Let’s see if that does the trick.


UPDATE: One more tweak is needed to the fix_filenames task, because the mv command will complain if the source and destination are the same, which causes the task to fail on systems which actually *do* use .so, like Linux. Here’s a corrected version:

1
2
3
4
5
6
7
8
9
10
11

task :fix_filenames do
  unless DLEXT == 'so'
    Rake::Task[:install_ext].prerequisites.each do |prereq|
      prereq = prereq.ext('so')
      if File.exist? prereq
        mv prereq prereq.ext(DLEXT)
      end
    end
  end
end

Ramble: Curves Roadblock

I’ve been pounding my head against the wall over these Bézier curves for the past couple days. For a change of pace, I’m going to pound my head against this blog instead, and hope that something useful falls out.

The overall challenge is to preserve the apparent position of an object (i.e. the character) along the curve while dragging one of the handles.

Currently, the character’s position is defined between 0.0 and 1.0, representing how far along the entire curve he is (0.5 being halfway around; for a closed curve, 0.0 and 1.0 are at the same location).

The character should seem to stick to a point on the curve, moving as that point moves. This means that the character’s actual position along the curve needs to be adjusted to compensate for the change in overall curve length.

Without such adjustment, the character will seem to slide along the curve, even if the curve is being modified somewhere else (because the curve’s overall length will change).

One possible solution would be to modify how the character defines its position. If it were defined as the position 0.0 to 1.0 along an individual segment, then modifying other segments would not affect the character’s position. More, modifying the segment that the character is on would cause the character to move along with the segment as it’s stretched/squashed. Problems solved.

(Even better than defining 0.0 to 1.0 along a segment, would be to define 0.0 to L, the length of the segment. This will make it easier to have the character seem to move at a constant speed.)

This somewhat complicates the way the character’s true position is defined, because it will have to remember which segment it is on, and find out what the next segment is when it walks off of the current one. This can be accomplished by having each segment remember the previous and next segments in the chair (i.e. linked list of segments).

This entails a substantial rearranging of how the curve system is currently defined. Much of the power and responsibility of th Curve class will be shifted off to other classes, especially Segment.

Cubic Bézier Curves

I spent some time solving equations for evaluating points along a cubic Bézier curve. What I find particularly elegant about Bézier curves is that they can be calculated with recursive/nested linear interpolations. It gets 100 geek points just for the phrases “recursive” and “linear interpolation” — it also wins my appreciation for how comparatively simple it is to solve by hand!

I had come up with an equation a while back for doing this same task, but it wasn’t as tight as it could be. For one thing, it required evaluating the coefficients for each curve every time a point was evaluated.

Continue reading Cubic Bézier Curves

Ambient Wildlife and Bouldered Paths

Lately, I’ve been thinking a lot about sound, color, and abstract artificial life. No doubt that this most recent bout is directly tied to my recent purchase of Electroplankton (the best, albeit only, $60 I’ve spent on Ebay), but all three are recurring themes that have been agitating my brain for years.

Wouldn’t it be wonderful to play with colorful creatures that scamper around and make musical sounds as they jump and chase each other? It sounds like the love child of Brian Eno and Will Wright, to be sure.

Continue reading Ambient Wildlife and Bouldered Paths