Advanced graphics for Inform 7

Download the demo game here. To play the demo, you will need the latest version of your favorite Glulx interpreter, such as Gargoyle, Windows Git, or Zoom (see links at right). Users of the Spatterlight interpreter are advised to upgrade to Gargoyle.

To date, the demos that I’ve released for Glimmr Canvas Animation have been either simple visualizations, or have gestured at nonstandard interfaces that have not really been seen in parser IF before. Which naturally raises the question: what can animation do for the vast majority of text games–the ones that are just text? This new demo, Animated Title Page, is one answer to that question.

In recent years, there have been some developments in the way that IF games present themselves at start-up (and before), including the increased use of cover art, largely thanks to Emily Short’s cover art drive from a couple of years back, and the growing popularity of “title pages” (see, e.g. Make It Good, or Jon Ingold’s plug-and-play I7 extension). This Animated Title Page demo continues this trend. In contrast to most IF, which opens with nothing more than a couple of paragraphs of text and the famous blinking cursor, Animated Title Page suppresses the main text window in favor of a graphical presentation, showcasing the cover art along with a list of basic options, such as starting a new game or continuing a saved one.

Title page for the demo

The demo reimagines the art for Deadline, using a noir-flavored photo by Flickr user emdot

The demo, which pretends to be the classic Infocom game Deadline, also prefaces the title page with a fun and overly dramatic animated rendering of the original game’s marketing tagline: “A locked room. A dead man. And twelve hours to solve the murder.” This text rushes out at the player, making a whooshing soundas it rockets by. There are also fade-ins and fade-outs, animated button depresses, and other effects.

The original box art for Infocom's Deadline

The original box art for Infocom's Deadline (1982)

It is worth noting that, despite the dynamic animations, the demo is actually quite simple from the standpoint of art creation. The art consists entirely of rasterized slugs of type (made using the font Dirty Headline by S. John Ross of Cumberland Games), and of a single photo (sitting by emdot). These elements are animated together using commands provided by the Glimmr Canvas Animation extension. Similar designs  should be well within the capabilities of most authors. The source code for the demo is available at the link below, should you want to try to modify it for your own purposes.

The demo is substantially complete, but there are a few more refinements that could be implemented. It would be nice, for example, to be able to skip the animations entirely to fade in directly on the title screen; it’s probably a bit much to have to watch even 20 seconds or so of introductory animation every time that you open the game. More radically:  Nearly all other modern games, from casual to triple-A, employ an automated system of save slots so that the player never has to interact directly with the filesystem to manage her saved games. Such a feature would be easy enough to build into a Glulx project, and of course save slots would be a natural fit for a graphic interface like the one presented here.

Download Animated Title Page, or the source code and assets. Comments welcome.


Comments on: "Demo: Animated Title Page" (6)

  1. I do hereby grant you retroactive license to use Dirty Headline for this purpose!

    Very nice, BTW. 🙂

  2. Wow, I never thought I’d see that in Gargoyle!

    I was playing around with the migration track for the ‘Deadline’ title trying to make it move up and to the left a little faster; with the example code of 20 fps and 7 frames it has a slow, stepped animation. Changing it to 60 fps has a small effect, but I feel like I’m missing something — is there some fixed period of the animation declared somewhere else? What would I have to do to get a faster animation there?

    • The limit you’re running into is actually a performance issue in Gargoyle. While Gargoyle is probably the fastest interpreter when it comes to drawing smaller images, its performance declines rapidly with larger images. (Zoom for OS X, in contrast, is a hairsbreadth slower than Gargoyle with smaller images, but doesn’t suffer nearly as much slowdown with larger images.)

      If you want to experiment, try opening cover.png in your favorite image editor and halving its size. It won’t look good in-game, of course, but I’m pretty sure it will animate faster.

      This brings up an unfortunate limitation of Glulx, which is that the author can’t specify a maximum window size. Personally, I never play IF with a window that’s wider than about 600 pixels because the lines of text get too long for easy readability. However, I know that a lot of people fullscreen it, so I created the demo so that it would look pretty good even in a fairly large window. That means bigger images and poorer performance.

      On the question of the specified animation rate: Most Glulx interpreters can’t actually do much better than 24 frames per second (40 milliseconds per frame), depending on what they are being asked to render on each frame. Gargoyle and Zoom both have higher-resolution timers (with some variation by platform in the case of Gargoyle), but they will also hit performance limits if a lot is being asked of them.

  3. With respect to larger images, do you mean this, Was there a noticeable improvement after that revision I wonder?

    It would be cool to have a fps counter widget you could plug into a project to see how your frame rate is doing through various rendering tests. A limit in the 20s seems pretty unfortunate.

  4. Gargoyle’s display of large images probably did get faster after that revision, but it’s still relatively slow, at least compared to Zoom (as an OS X user, Zoom is my other benchmark).

    So, you aren’t getting the desired framerate of 20 with that part of the animation in Gargoyle due primarily to the size of cover.png. A framerate in the 20s is actually pretty darn good if you can get it, though! Movies run at 24 fps; the human eye doesn’t *really* need anything faster. I think you probably can get better than 24 with Zoom and Gargoyle (as long the calculations needed to render each frame are simple), but I’m not sure it’s necessary; some of the demos that I have posted are requesting just 8 fps.

    A framerate counter isn’t really very practical with Glulx, because what Glulx does if it can’t keep up with the desired rate is to skip ticks of the timer. The timer doesn’t report that it has skipped a tick, so there is no way to know when the computations are causing the speed of the displayed animation to lag. Theoretically, you could use Glulx’s new time functions to check the real time clock at each actual tick of the timer, then compare that to the time that you would have had if every tick had fired ideally; that would give you a measure of lag. However, I don’t think that Glulx timers are accurate enough for that even under the most favorable circumstances…

  5. Yes, very nice.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: