Podcast: “The Music of Erich Zann” by H. P. Lovecraft

The Space Toast Pages present a free audiobook of H. P. Lovecraft’s “The Music of Erich Zann.” In his impoverished days as a student, a young American makes the acquaintance of an old musician whose singular genius draws him ever closer to the mysteries beyond the wall atop the Rue d’Auseil. This short story was originally published March 1922 in The National Amateur, 44, No. 4, pages 38-40. Rasmussen hates his voice, and hopes you will too.

Listen to podcast: TheMusicOfErichZann.mp3

[17 minutes, 52 second – 8.2 MB mp3]

Creative Commons License
This
work is licensed under a Creative Commons Public Domain License.

Mid-Coast Preschool Services Development Screening Interview

Child's Name: Matthew Rasmussen Age 4yrs 4 mo. Date Dec 6, 1984

Four Years

Social:

1. How much does your child do for himself in dressing and washing up?

[X] Unbuttons and buttons clothing

[X] Washes hands and face

[X] Toilet trained day and night

[X] Cares for self at toilet mostly

2. How much does your child do for himself in eating?

[X] Spreads with knife soft things

3. Describe how he/she plays with children. gets upset w/ younger children interfering

[X] Understands taking turns/sharing

[X] Group play (2-3 children)

Gross Motor:

1. What does your child do when playing outside? Pretend play – Boats, Little puppy or Sandbox

[ ] Bounces and catches large ball -no

[ ] Pedals tricycle turning corners no – big wheel too large – snow on ground now

[X] Runs and climbs

[X] Hops on one foot

Fine Motor:

1. What does your child do with paper and pencil?

[X] Copies +

[X] Copies []

2. What kinds of toys does your child play with?

[X] Imitates bridge

[ ] Completes 6 piece puzzle

[X] Builds tower of 10 blocks

[X] Cuts with scissors

Mid-Coast Preschool Services

Developmental Screening Interview

Four years

Page 2

Language/Concepts:

1. How much does your child talk? very verbal

2. Can you give me an example of the kind of sentence he/she uses? Noah and Ethan are my very best friends

3. How well is he understood by others? very well

[X] Relates experiences, describes activities

[X] Names 3 Primary colors

[X] Says most sounds except r s th and l

[X] Repeats nursery rhyme or song for others

[X] Understood by strangers

Carolyn Rasmussen

Interviewer

Cloaking Blosxom

The correct form of a URL is where/what, as a web address exists to organize content. By default, Blosxom serves pages from www.spacetoast.net/cgi-bin/blosxom.cgi, a machine-centric where/how address which breaks the above guideline. A method was needed to disguise the address of the cgi script.

Blosxom’s main site includes instructions for hiding the …cgi-bin/blosxom.cgi address on an Apache server by means of an .htaccess file — a local preferences file. Unfortunately, the instructions did not work for this site.

The first method given for cloaking Blosxom (bullet three, step two) redirected requests for any address in the STP directory to Blosxom, including images, media files and old pages. For this site, it would have been written thusly:

RewriteEngine on

RewriteRule ^STP/?(.*)$ /cgi-bin/blosxom.cgi/$1

The second given method (bullet three) invoked Blosxom only if a real file could not be found. It had problems with directories. Since STP/web/blosxom/ is a real directory, Blosxom did not attempt to create a page there, defaulting to either listing the files in the directory or producing a missing/forbidden error. Here is how it would have appeared:

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule ^STP/?(.*)$ blosxom.cgi/$1 [L,QSA]

Venerable Apache Server’s developers are a strange, thundering race who produce suitably impenetrable documentation, but after some levelling up the following was arrived at:

Options +Indexes

RewriteEngine on

RewriteCond %{REQUEST_FILENAME} !-f

RewriteRule ^STP(.*) http://www.spacetoast.net/cgi-bin/blosxom.cgi$1

Here is a breakdown. The first line overrides Laughing Squid’s default error when trying to browse a directory without an index file. The second turns the URL rewriting engine on. The third tells it when to work — in this case, when a file can not be found. (Notice that the missing directory line is now gone.) The fourth line tells Apache to remove “STP” and send the remainder of the address to the blosxom.cgi script.

This portion of the Blosxom installation took far more geekery than it should have. Strictly speaking though, it is optional.

Why Blosxom?

I’d been meaning to add blog software to my site for some time, and of all the content management systems I looked into, Blosxom seemed to best suite my prejudices:

  • Free and open source
  • Small and easy on the server
  • No annoying .php pages, as discussed in this rant
  • No database — nothing to yell at me if I make changes with FTP
  • Plugins to add missing features

With Blosxom now up and running, I can report that it delivers all of the above, at the cost of the following:

  • Missing, out of date and incomplete documentation
  • Missing, out of date and incomplete plugins

Blosxom is ancient in web terms, buoyed along by its simplicity of design. The original site is no longer updated, and while the current developers have mirrored the site to SourceForge, they appear to have done little to update it. Newer plugins can be found offsite, without documentation or generally even descriptions of what they do. Plugins listed on the conserved original site are often dead links; mirrors of the plugin code can usually be googled, but any documentation not included in the code itself is often gone. Blosxom has only basic functionality without plugins.

It is (apparently) possible for an artist with only a modest technical background to install, configure and use Blosxom. The core blosxom.cgi script is bulletproof, and the original installation instructions are quite good. Setup is minimal, and there are no dependancies. An understanding of Perl is not required.

Plugins can be another matter. Many of the plugin problems fall under a recurrent fallacy of open source: “It’s free, so I can be lazy.” Certain plugins expect the user to be a Perl hacker, which is counter to the philosophy behind the software. Others omit documentation, or are abandoned with features incomplete. Blosxom’s stop-and-go development over the years has not helped the problem. More on the plugins used on the Space Toast Pages will follow, after some notes on basic installation and the problem of “cloaking” the cgi-bin URLs.

Notes on Installing Blosxom

Blosxom’s official installation instructions are concise and straightforward. Installation required only a standard FTP client and a text editor. (I used JEdit with the FTP plugin installed.) The blosxom.cgi script ran as soon as it was installed; SpaceToast.net’s ISP, Laughing Squid, did not require it to be “blessed” first.

Configuration was straightforward. The settings are stored in the script itself. Many settings can be left at the defaults.

Fitting the Space Toast Pages’ existing layout into the Blosxom engine was equally straightforward. An old Space Toast Page was sliced into three “flavor” files, the head.html, story.html and foot.html files, with Blosxom markup tags added where dynamic content should be placed. (An additional date.html flavor file is required. On the Space Toast Pages it is an empty file, as date stamps are part of the story template.)

Blosxom stores posts as plain text files in the “data directory” and serves them as html files or rss feeds from the “blog directory.” The Space Toast Pages keep everything in SpaceToast.net/stp. Surprisingly, this doesn’t cause a problem. Any of the posts on the Space Toast Pages can be accessed as raw text files by simply substituting .txt for .html in the address bar. The text file is a real file sitting on SpaceToast.net; the html file is a fake created by Blosxom when it’s requested. An .htaccess file makes the ephemeral page look real — more on that in the next post on cgi cloaking.

STP Relaunched

The Space Toast Page has become the Space Toast Pages, a “journal of journals” on Rasmussen’s various obsessions and experiments. The weekly issue format has been discarded in favor of a categorized, feed-friendly, commentable series of blogs and sub-blogs running on the free and open source Blosxom content management system. Thank you as always for reading, and welcome back!

Build Notes: Tape Case Bike Light

Issue 177, for the week of 8/27/2006.

Toast Note: Happy birthday to my sister Becky, who is celebrating in India. Wow. That is way cooler than a Cuisinart.

Boring Preface: Massachusetts state law requires a bike to have a forward light while riding at night. Commuting home on the city’s lit streets, I’m less worried about seeing the road than about other people seeing me. The cheapest bike lights seem to run about $20, so I’ll make that the maximum budget for this project. The light needs to be easy to attach and remove, durable enough to throw into a shoulder bag, and easy to turn on and off. I’d also like it to double as a flashlight the next time a transformer blows up in Central Square.

Theory: The front reflector seems to be the most logical place to attach the light to the bike, though I don’t want to obscure the reflector itself. It should be possible to build a bike light inside an old audiocassette case using two AA batteries, a pack of magnets, and a bright white LED upgrade for a mini Maglite. The light would clip around the bike’s front reflector. This project should cost less than $20.

Get:

  • An audio tape case
  • A three-LED upgrade kit for a mini Maglite
  • Eight (8) round 3/4″ ceramic magnets
  • Two (2) AA batteries
  • Some thin insulated wire
  • A few scraps of aluminum foil
  • Electrical tape
  • A small tube of super glue
  • A pair of needle-nosed pliers
  • A utility knife
  • A ruler or measuring tape
  • Space to work

Make sure that the cassette case isn’t one of the newer “slim” cases, but the regular kind. The mini Maglite upgrade kits consist of a replacement reflector housing three bright white LEDs wired into a resistor correctly sized for two AA batteries. They retail for about $11. You could certainly use your own LEDs (I read that Christmas lights are a cheap way to get them) but I don’t know nearly enough of a damn about electricity to figure out what size resistor to use — just that I need one to keep from blowing the LEDs out. Three-quarter inch ceramic (black) magnets usually come in packs of eight at the hardware or hobby store, and go for about $1.25. They’re fun to play with. If you don’t have a little spool of insulated wire lying around the house, I guarantee you have a broken stereo in the basement you can pillage. Utility knives seem to have been renamed “box cutters” since I was a kid, but I refuse to let the terrorists win.

Step A: Measure the width of your front reflector. These instructions are written for a reflector about 2 and 1/8 inches wide. From what I can tell from a cursory look around Porter Square, this kind is fairly common. Some of the newer bikes have smaller reflectors (why?), which should work fine for our project. A larger reflector would require a larger case — maybe a VHS-C tape case. Everything jams in pretty snugly with this design as is, so if your reflector is a different size you’ll have to play jazz a bit.

Step 1: Take the tape and label out of your audiocassette case and throw them away. Your crappy Sony deck hasn’t worked for most of a decade now anyway.

Step 2: Cut/snap the two prongs out of the tape case.

Step 3: Measure the width of the bracket on the back of your reflector — the part that connects it to the bike. Mine is 3/4 of an inch wide. The metal piece will probably be a little bit narrower than the part it screws into. If it is, just take the wider of the two measurements. Like I said, mine seems to be a pretty standard part, so if your reflector is the same size as mine it’s also probably 3/4 of an inch wide at the bracket too.

Step 4: Cut a notch, using that measurement, in the back of the tape case. The reflector and bracket together are too thick for the case to snap shut around, so we’ll need the bracket to hang out the back. Be careful to center your cut. Cut from the bottom of the case up to about even with the overhang. Mark your cut lightly with a straight edge or ruler, then go over it repeatedly until you cut all the way through. A little bit of splintering around the cut is normal, just don’t be so impatient that you crack the case. Did I mention it might be a good idea to put a new blade in your knife for this project? It might be a good idea to put a new blade in your knife for this project. Before now.

Step 5: Wrap electrical tape around all three sides of the cut. This will cover up the shattery bits, keep any cracks from spreading, and give it a nice rubberized mounting around the bike reflector bracket. Cut away the excess.

Step 6: Grab two of the ceramic magnets. We’re going to be gluing them on either side of the cut, about even with the overhang. These will be to rest against the back of the reflector, hopefully keeping it from moving too much. One by one — and with the other magnets clear — put a good bead of super glue on one of the two magnets, press it into place and hold it there for about a minute.

Step 7: Stick a piece of electrical tape along the entire length of the bottom of the case, folded over lengthwise. Half of it should be stuck to the outside of the case, and half to the inside, with the tape stuck to itself where it crosses the notch we cut. This will keep the bottom from wobbling by holding it tightly against the metal bracket. The electrical tape is a little bit stretchy, which is good. Anyone going for extra credit here might try sticking a rubber elastic inside the tape for extra holding power.

Step 8: Open the LED upgrade kit. You’ll find a little black cup with the LEDs inside and two wires sticking straight out the back, surrounded by a silver reflector.

Step 9: Remove the reflector; the LEDs are bright and directional enough without it, and it’s too thick to fit inside our tape case.

Step 10: Bend the two wires on the back to either side, being careful not to rush and snap them. I don’t really know how much abuse they’ll take, and I don’t want to find out.

Step 11: Cut four pieces of wire: three long ones (maybe 4-5 inches apiece?) and one short one (1-2 inches long).

Step 12: Strip each of the wires half an inch in from both ends. If you’ve never stripped wires with pliers before, it’s easy: Go around the wire worrying the plastic insulation with your pliers’ cutters. Don’t squeeze hard enough to actually cut the wire. The plastic cuts more easily than the metal inside. Begin pulling the wire as you continue weakening the insulation. Look for strong places, and keep pulling the wire and worrying at the insulation. Eventually, the plastic will begin to slide off the wire. Yank it off, and give the wire a twist or two.

Step 13: Take two of your longer pieces of wire. Make a little loop in the stripped portion on one side. Slide this loop around one of the wires on the back of the LED cup. Twist it a few more times, and squish it all together to get a good electrical connection. Repeat, looping the second wire to the cup’s other connection. If you want now, you can solder the wires permanently together — but I hate soldering, and I don’t want to pretend this project requires it. Either way, finish by sticking a square of electrical tape on the back of the cup.

Step 14: Slide the LED cup up under the lip of the cassette case, facing outward. Feel free to glue it in place, but it’s a pretty tight fit — I say don’t bother.

Step 15: Since LEDs only allow current to flow through them in one direction, we’ll need to figure out which side is + and which is -. Hold the wires against either end of one of the AA batteries. If it lights up (cool!) make a note of which side is which. If not, reverse and retry. (If nothing lights up, redo those connections.)

Step 16: Tear off two pieces of electrical tape, each about twice the length of a battery. Lay each strip of tape face up on the table and center the batteries on them. We’re going to be taping the wires directly to the batteries. It’s easy to do, and with the LEDs we won’t have to change the batteries much anyway.

Step 17: Tear off two small scraps of aluminum foil. Stick the wire from one end of the LED cup to the electrical tape beneath the battery contact, and then put a scrap of foil on top of it. Wrap the tape around the battery contact. Repeat for the other wire and the other battery. Wrap the tape around the battery contact. The aluminum foil is here to give us a larger electrical contact. Aluminum foil is conductive.

Step 18: Tear off two more scraps of aluminum foil. Using the same procedure as the last step, stick the short wire to the other end of one of the batteries. Grab a ceramic magnet and the other scrap of aluminum foil. Tape the loose end of the short wire to the top of the magnet, with part of the foil sticking out. Fold the foil over the top of the magnet.

Step 19: Tear off a larger scrap of aluminum foil and wrap it completely around one of the remaining magnets. This will be our “switch.”

Step 20: As in step 18, tape the remaining long wire to another of the magnets, with a piece of foil folded over to make an electrical contact. Let it stick itself to the “switch” magnet.

Step 21: Just like in step 17, connect the loose end of the wire to the remaining battery contact. The LED should light up. If it doesn’t, troubleshoot: We should have a circuit going from the LEDs to the first battery, through the bottom magnet, through the foil on the “switch,” through the second battery, back into the LEDs. Make sure your +’s and -‘s are all going in the right direction. Redo the foil/wire connections with more foil. If it did work, great job.

Step 22: Notice something. When you pull the “switch” magnet out of the stack and replace it with a bare magnet, the LEDs don’t light up. Ceramic magnets aren’t conductive. When the “switch” is in place, the circuit is on. When there’s a bare magnet there instead, it’s off. Leave the bare magnet in the stack between the two wired magnets. Stack the “switch” and the two remaining magnets with the “switch” in between. We should have two stacks of three magnets, which you’ll notice are about the same depth as the tape case.

Step 23: Push the two batteries tightly into the top right and left hand corners of the tape case so that they’re square with the edge.

Step 24: Place the stacks of magnets at the lower inside corners of the batteries. Experiment with closing the tape case. Find the position where the stacks are as close to the lower right and left hand corners of the case as possible, but the case can still close without hitting the magnet stacks or the batteries. We want everything to fit snugly.

Step 25: Once you’ve found the ideal positions, put a generous bead of super glue on top of each magnet stack and close the case. Hold the case shut as tightly as possible for about a minute, to make sure the super glue sets up properly with the top of the case.

Step 26: Flip the case over and repeat step 25, gluing the bottom of the magnet stacks to the bottom of the case.

Step 27: Once you’ve given the super glue some time to set up, flip the case back over and reopen it. Since we had to cut that notch in the back of the case, the back is the weak point: pull evenly on both sides to reopen.

Step 28: The trouble with ceramic magnets is that they don’t like sticking to anything more than they like sticking to themselves. To add strength, encircle each of the glued magnets with another bead of super glue. Let it set up, and cut away the excess if it gets on anything else.

Step 29: Tape the loose wires out of the way. You’re done. Swap the “switch” with the other loose magnet (storing the loose magnet on the other stack) place it around your bike reflector and let it snap shut. You’ve got a light on your bike — a bright one at that, which doesn’t strobe, pops on and off easily, and won’t chew through batteries every couple weeks.

Criticisms: Despite being built in a plastic case, the light is far from waterproof. I wouldn’t even call it terribly splashproof. Silly as it would look, a sandwich bag over the top might not be the worst idea on a rainy day. Opening the light takes some learning, as you figure out how to evenly pull on both sides of the case’s back. The biggest problem I’ve encountered, though, is the one mentioned in step 28: ceramic magnets just don’t like to glue down. Step 28 was an afterthought, after I had to reglue one of the stacks. It’s certainly stronger with an additional bead running around the base of the magnets, but I’m starting to think a gel epoxy (nasty as that stuff is) might eventually be needed.

Final Thoughts: It works, weirdly enough. Assuming you already have things like pliers, electrical tape and a set of batteries, you should have no trouble beating the $20 budget. (If not, they’re good things to own.) Please enjoy your antiluxury good. Build one? Send me a picture.

If you liked this project, you may also dig the previous Build Notes: Junk Mail Blinds.

[Click here for a printable version — or just turn stylesheets off.]

SGV Artillery Game: Proof of Concept

Issue 173, for the week of 7/2/2006.

Toast Note: What with the site redesign (now complete), three concurrent jobs, and a bad summer cold, the Space Toast Page has been a bit neglected lately. Still, I have a treat for you this week. Thanks for waiting.

(If the above opens as plain text, save it to the desktop and drag the file onto your browser.)

This is a proof of concept for a tile-based artillery game using Scalable Vector Graphics (SVG) and JavaScript. SVG was meant to be an open, plugin-free alternative to Flash, but it was a relative failure. To date, only FireFox and Opera 9 fully support the SVG specifications, with Safari’s support still incomplete, and no native support in Internet Explorer. Adobe has released an SVG viewer plugin for most web browsers, but Adobe’s implementation is not fully compatible with standard SVG. Still, the Safari development team is making fast progress, and Google is reported to be working on a translator for Internet Explorer, so SVG may yet see a true dawn.

To date, the game has only been tested in FireFox 1.5 for Mac and Safari 2.0.4. It is buggy, but runs in FireFox. Safari will draw the initial game state, but does not loop.

The game runs at a resolution of 700×500 pixels. In a window smaller than that, FireFox creates scrollbars, which trap the arrow keys. I don’t know a way around this yet. It should be possible to make the game scale up or down to the size of the window automatically, as SVG is resolution-independent, but that may require redoing the artwork and JavaScript to use percentage measurements, rather than pixel measurements.

The game artwork was created in Inkscape, an open-source project which is making great strides toward creating an alternative to Adobe Illustrator. As of version 0.44, Inkscape is not suitable for directly editing graphics in an interactive SVG file. It has a tendency both to mangle JavaScript and to revert custom group names to generic ones. Additionally, Inkscape’s method of saving object attributes like color and stroke width is to bundle them into one long style element (i.e. style="fill:#574736;fill-opacity:1stroke-width:0;stroke-opacity:1") rather than splitting them into individual elements, which are easier to access with JavaScript. The Inkscape team’s progress remains impressive.

My biggest concern is speed. The game currently maintains its frame rate by idling for 10 milliseconds between loops, although I think I’ve come up with a better way to do it — please refer to the JavaScript’s comments. Although I doubt that FireFox’s SVG drawing routines are tuned for game speeds, my biggest worry is the speed of JavaScript execution. Some parts of the script store game data in JavaScript variables, others assign it to the game’s SVG objects — as whim desired, really. The latter seems to be considered more “correct,” in terms of modern programmers’ fetish for object-based programming, but I’m all but convinced it’s terminally slower than the former. Accessing elements (manipulating the DOM) is also an absolute pain in the ass in JavaScript. For both reasons, I suggest doing it as little as possible.

As near as I can tell, this is the most advanced SVG game anyone has written to date — which is sad, but telling. Owing to uneven support, sluggish speed and lack of an integrated development environment, I can’t see SVG supplanting Flash any time soon. Still, SVG is not without potential. Enjoy the game.

Further Reading:

With some previous JavaScript experience, it took me about a week of spare time to get this far. The following sources and examples were invaluable.

Clip Splicing Without QuickTime Pro

Issue 170, for the week of 4/30/2006.

QuickTime Pro wouldn’t have pissed me off if they hadn’t taken features out of the player to make a paid version. Add some good stuff, charge me extra for it and keep the basics free — fine — but cripple the software and charge me extortion money, and I’m not inclined to pay. I’ve been using Macintosh computers for a long time; I remember when it was exciting that a clip could actually maintain synch! I remember QuickTime 1, QuickTime 2, and the Waterloo that was QuickTime 3. Release three was when Apple gave us some nice codecs and tried to dance around the fact that they’d started charging for cut, copy and paste. It was also when they began nagging us to upgrade to Pro, but that, fortunately, has taken a more subdued tone lately.

Since I never use the second paragraph of a Space Toast Page to actually set up the essay, let’s just take a second to mention that it’s Apple’s botched QuickTime strategy that has gotten us to 2006 with no serious alternative to Flash. Full JavaScript-based interactivity, on-the-fly transitions, realtime filters, and unlimited dynamic tracks in any supported video, still, audio, 3D, panorama or sprite format were and remain possible in QuickTime, but without a real track-based development tool (which should have come standard with every Mac) these features remain hollow bullet points.

Never mind that you can’t cut, copy and paste anymore.

So what are our options? Let’s say, theoretically, that you’re working on an animation for a local science museum. Theoretically, they’re going to be running a QuickTime movie to a video projector from within a PowerPoint presentation. Imagine that it’s about Ben Franklin, and it’s going to be fantastic. This is all theoretical, mind you. Now lets imagine that, because it’s going to a video projector, you’re working at above DV resolution. You nursed Premier along for far too long, and when Apple did a trade-over promotion with Final Cut DV you jumped at it. Here’s the problem: Any editing, even splicing clips together or adding a sound track, will cause Final Cut Express (another creatively crippled program) to first scale down to DV resolution (720×480) and then scale back up when you export — resulting in a noticeable loss of image quality, especially on the kite strings. (Don’t forget how theoretical this all is.) All you really need is the 21st century equivalent of a Steinbeck, but QuickTime paywalled clip splicing in 1998.

The solution is to go back before 1998. QuickTime 2.5 was the final pre-3.0 release and, being freeware, installers can still be found all over the internet. Download a QuickTime 2.5 installer, choose Custom Install, and install only the MoviePlayer application. At the risk of talking out of my ass, at 164k, the MoviePlayer application seems to be little more than a pass-through for features wired into QuickTime, which means that MoviePlayer can now do more than it could when it came out. For instance, it can play .dv clips, or .mov clips compressed with the DV codec, even though digital camcorder support wasn’t added to QuickTime until 3.0.

MoviePlayer can’t do everything though. H.264 (one of what appear to be three different implementations of MPEG-4 video currently in QuickTime) runs only under Mac OS-X, and opening one of its clips in MoviePlayer will return an error — thought, impressively, not a crash. “Present Movie” will crash Classic however; don’t use it. As a Classic application, MoviePlayer is limited to QuickTime Classic’s codecs: Animation, BMP, Cinepak, Component Video, DV NTSC, DV PAL, DVC Pro PAL, Graphics, H.261, H.263, Intel Indeo Video 5, Motion JPEG-A, Motion JPEG-B, MPEG-4 Video, none, Photo – JPEG, Planar RGB, PNG, Sorenson Video, Sorenson Video 3, TGA, TIFF, and Video.

MoviePlayer has the old-fashioned design philosophy of a product without a marketing strategy. It’s remarkably intuitive by today’s standards. Drag on the timeline with the shift key to select part or all of a clip; a black bar appears to indicate how much you’ve selected. You can cut, copy, paste, delete, or drag and drop to your heart’s content. (Large clips sometimes return low memory errors with cut, copy and paste — dragging and dropping seems to avoid this problem entirely.) “Extract Tracks…”, in the Edit menu, creates a new clip with either the audio or video track. Tracks may be deleted individually, or temporarily turned off and on in the Edit menu as well. Choosing “Get Info” under the Movie menu and selecting “Time” from the “Files” popup menu will allow you to view timecodes.

To get back to that theoretical Ben Franklin animation, pretend that you have spliced together a final cut of the animation and need to replace the scratch track of the live actor’s lines with a sound effects track mixed in Audacity or Final Cut Express. Open the sound clip you’ve exported from either program, select it all and copy it. Go back to the animation clip, choose “Delete Tracks…”, delete the current sound track, and click on the first frame of the clip. Hold down option and go up to the Edit menu. The “Paste” menu item has become “Add,” which will allow you to paste the sound track under the video. Selecting “Paste” without holding down the option key will perform the default insert operation, moving all the video out of the way and inserting black video for the length of the audio clip. It’s weird, but it makes a kind of dumb sense.

We have successfully edited a QuickTime clip, and we have two options with which to save it.

The File menu’s familiar “Save As…” includes two choices of its own. “Save normally (allowing dependancies)” will display a much smaller file size than “Make movie self-contained.” Chances are the latter is your best bet though. “Make movie self-contained” will copy all of the track data you’ve added to the clip into one file, rather than looking up all of the individual files you spliced together to make the clip. When you select “Make movie self-contained” a new option will ungrey: “Playable on non-Apple computers.” Select this. QuickTime used to default to saving movie data into a “MooV” resource alongside the data fork, rather than into the data fork itself; non-Apple systems never used the split resource/data fork file structure, and see only an empty or corrupt movie file. Use the “Playable on non-Apple computers” option to avoid this problem. The advantage of “Save As…” with “Make movie self-contained” and “Playable on non-Apple computers” is that the resultant movie will be exactly the data that you fed into it. Nothing is recompressed. There is no digital generation loss (and yes, there is such a thing).

What if you need to recompress the movie though? Suppose you need a 320×240 version compressed for the web. What if the computer playing the animation has too slow a hard drive to keep up with the Photo-JPEG codec at maximum quality? Beneath “Save As…” is an “Export…” option. This brings up the standard QuickTime export dialogue, from which you can export to non-QuickTime formats, as well as change the frame size, frame rate, sound and video codecs, and streaming optimizations.

As usual, I’ve gone on for far too long with a very simple idea, and one week’s Space Toast Page has become another’s. If you can run Classic, get MoviePlayer. It’s a pawn shop Swiss army knife with a rusty corkscrew and the initials P.B.R. carved into the handle, but it still basically works. If you want a Big Message, which I’m sure you don’t, onward is not always upward, and Neil Young can kick it out better in nine days than John Melencamp could in his entire wasted career. Thank you for reading.

DVCam High Resolution Photography

Issue 167, for the week of 3/5/2006.

“Copley Square at Night” 1415 x 2559 pixels. 890KB jpeg.

The picture above was stitched together from 108 smaller images using Hugin, a set of open source panorama creation tools. Each slice was captured to tape on a consumer digital camcorder by slowly moving the camera back and forth across the scene from top to bottom at full optical zoom. Once imported and converted to a series of tiffs, the autopano-sift module was run to automatically match neighboring images. Matching points were input by hand in places where the software could not do so. The combined image was exported at full resolution with the edge-smoothing “enblend” module enabled. Cropping and sky completion were performed in Photoshop, and the image shrunk by 50% to eliminate jaggies left over from the camera’s original compression.

A Random English-Sounding Place Name Generator

Issue 166, for the week of 2/26/2006.

Here is a funny request:

I'm launching my new Feudalism inspired game next week, and I need a TON of english

sounding region names. Like Woodstown, or Clapshire.

I can TRY to think of them all myself (I'll need anywhere from 45-50), but the

prospect baffles my widdle mind. SO if you have time and inspiration, and feel like

inventing 4-5 of them FOR me, I'd really appreciate it.

Thanks (in advance)

-EvilMustache

Below are fifteen randomly generated English-sounding place names. Reload the page for fifteen more. Enable JavaScript if nothing appears:

Myst V and the Way Forward

Issue 165, for the week of 2/19/2006.

Literally three steps in, I’m defeated by a low gate. I’m looking down at it. I could step over it. Still I’m trapped.

I have chosen to begin this essay with a digression.

You know those programs that change the screen resolution when they go to full-screen, and then tell the other applications that they’ve done it? It’s a kind of a slapdash Mac port thing. You quit, and every window on the screen has been squished down to an absurdly wee size and moved to the top left corner of the screen. Myst V is like that.

Ultimately, that’s not the point of this essay, though.

As with Myst [I], the exploded box of which hangs on my wall for inspiration and which I can still play under Classic, the default navigation system of Myst V becomes bothersome after a few minutes. You’re rarely quite looking where you want to be, and yet with the Obsidian/Burn:Cycle-style smoothly eased tracking shots between nodes replacing Myst’s hard cuts and simple transitions, you often find yourself looking at the interesting object during movement, only to have your camera jerked away from it as the move completes. Nodes that would appear to give access to nearby areas are often a few feet from the ones that actually do. Myst V, of course, adds two additional movement styles, a free movement mode that doesn’t appear to support game pads, and a “Classic Plus” which slaves the view rotation to the mouse cursor — something not to be attempted without a truly boss frame rate and/or a love of vertigo.

Still, we haven’t reached our ultimate point.

The engine underlying Myst V is unique to the in-storyline Myst franchise. Instead of prerendered stills (Myst, Riven) or prerendered VR panoramas (Myst III, Myst IV), the game is rendered in realtime 3D. The appeal of this method for the developers is obvious. Rather than setting up shots, rendering, tweaking, rerendering, overlaying animations, and then having to move to a wholly separate software system to construct the game play, development goes straight from modeling to game engine in one step, assisted by a glut of available off the shelf software. Besides that, it just feels more modern — an unremarked upon motivation among middle-aged tech developers like the Miller brothers.

The trouble is, it’s not better. Compare the following screen shots:

Even with the best video card, which you don’t have, and all the light baking and optimization tricks in the book, the graphical quality of a frame rendered in one 30th of a second is never going to achieve the richness of a frame rendered over half an hour. The underlying models and textures must be smaller. The lighting system must be simpler. Even with a compressed color palette and knife-sharp shadows (not entirely undesirable for direct sunlight), not to mention eight years between them, the Riven screenshot is more realistic than that of Myst V. The objects are more complex and more numerous, the textures are high enough quality to be invisible, and everything that should cast a shadow does.

Of course, the quality of a still image isn’t the end of realism, which is where we uncover one of the most compelling reasons for the move to realtime 3D: Myst V moves. Look at the water in the game’s reversed wood between the worlds starting point, and even on low texture quality you’ll see ripples. Moving ripples. No more strange, frozen glass oceans. Stand still when you arrive on the beach. The clouds move slowly through the sky. The waves roll in and fall away. Birds flit through the sky (though most seem to be part of the static landscape). The sense of immersion is heightened, until, of course, you start wishing your video card could smooth those jaggies without the frame rate tanking, you notice that the smoothness of objects’ faces becomes angular at their edges, and you’re just plain stopped while floating along like Professor Xavier by a tumble of small, ordinarily fun to climb rocks.

It’s still not our point, but it’s worth mentioning that it’s best to make an insurmountable obstacle insurmountable. Personally, I can also climb a ladder with one hand, wade, and swim — not that it matters.

We do in fact have a point, and we’re getting dangerously close to it.

Myst V, while perhaps as good a puzzle game as its predecessors, has abandoned its roots. This, in itself, would not be a bad thing if the result were actually worth the change.

Let’s review what Myst V has gained:

  • Unlimited panning. Can also be achieved in prerendered graphics using VR panoramas, as with Obsidian, Myst III, Myst IV.
  • Animated tracking shots between nodes. Unnecessary. Our brains understand a “cut” — it’s that blink we do every time we look from one object to another. The novelty wears off quickly, as game play is slowed by it.
  • Free movement. Draws attention to the character’s limitations. Movement is still on a rail, we’re simply allowed to deviate slightly from it. Not essential to this genre.
  • Dynamic lighting effects. Underutilized. Aside from the hard shadows cast by moving objects, most of Myst V’s lighting appears to be painted on.
  • Hardware acceleration. Modern video cards can do a lot.

Now let’s review what Myst V has lost:

  • Prerendered graphics. Visually superior to realtime 3D graphics in richness and complexity.
  • Video. Those motion-captured 3D people with actors’ faces look pretty creepy, and the cloth keeps intersecting the legs.

Myst V is the last Myst game, but it need not be the death knell of the genre. There is room to move forward with the graphical adventure, while learning from the mistakes of Myst V. Realtime 3D graphics simply aren’t good enough. Is there a better way? I would suggest that there is.

First, though, review this QuickTime VR panorama of a node in Myst V. The panning doesn’t quite feel right. I suspect that there are two reasons for this, one trivial and the other quite complex.

Regarding the simpler problem, real life lenses are rarely perfectly round. They tend to flatten in the middle, creating lower distortion near the center of the image and higher distortion toward the edges. We’ve come to expect this. VR panoramas, which typically distort and display a portion of a single 360 degree image, are, I suspect, correcting for an idealized lens. Distortion is lowest at the center and increases toward the edges at a rate that is mathematically “right,” but less complex than that of a typical lens. If I’m right, this should be easy enough to overcome by tweaking the lens correction algorithms.

The second problem is more complex, and it has to do with the way cameras are actually manipulated. Photographing panoramas requires the purchase or construction of a custom camera mount which places the lens directly in the center of rotation. This is unusual. Usually, the camera is mounted at its base, placing the lens above and in front of its center of rotation. Panning thus introduces a small movement to the camera’s view position in addition to its orientation. Your eyes are likewise mounted above and in front of their center of rotation. The effect is most noticeable when objects are close-up. Close one eye and hold a pen up in front of you. Turn your head left and right. You can see different things behind the pen based on where your head is turned. You expect to. It’s part of your sense of depth, and it’s something that VR panoramas completely fail to reproduce.

Here we have arrived at our point.

I propose that a slightly novel game engine can overcome the limitations of both VR panoramas and realtime 3D in the graphical adventure genre. We can regain the detail of prerendered scenery and filmed actors without sacrificing the ability to animate portions or all of a given scene. If we accept the primacy of the node to the genre, discarding arguably unnecessary tracking shot transitions and “free” movement modes, we can consider a new style of node construction I unceremoniously dub the Dented Ball.

The Dented Ball is a real ball, or rather a very close approximation made up of several hundred triangles. Inside it lies a virtual camera, slightly above and forward of center. On the inside of the ball is mapped a high resolution image of a prerendered scene. Looking outward, the virtual camera records a portion of the scene, corrects for lens effects, and sends the resultant view to the player. This ball is our basic game node.

The scenery images, not to mention the tiny amount of data needed to construct this particular ball’s geometry, are loaded from the game DVD while the player is at a nearby node. Priority is given to the nodes directly connected to the previously occupied node, with priority further given to those portions of the landscape that the player would see first upon stepping into a given node from the previous. Nodes far behind are discarded, and reloaded only when the player nears them again. The goal is to minimize or eliminate waiting time between nodes.

Animation such as waves, birds, and even people may be added to the scene by mapping movie clips, rather than still images, to a portion or all of the inside of the Dented Ball. Modern video compression algorithms nearly half the amount of data that must be pulled off the game DVD to equal the image quality of a standard movie DVD, and modern computer DVD drives are capable of reading data much faster than is necessary to play movies compressed the old fashioned way. By feeding movie clips into the priority system above, waiting time between nodes can still be kept to a minimum. In addition, a standardized set of tools for fading, overlaying and cutting between still images should be integrated to allow for such simple effects as lightning flashes and the slow dimming of the sun as it goes behind a cloud, without requiring a large and unwieldy video clip.

In an ideal scene, there are no objects near the camera. (This is of course unlikely.) The edges of the ball on which the scene is painted are too far away from the viewer for the slight position offset of the camera to be noticeable. This would be a scene of the player floating high in the air — on the whole not very useful.

Nearby objects are the reason we call this the Dented Ball. Imagine that the player is standing near the corner of a wall. Panning right, more of the right side of the wall becomes visible, panning left, the opposite. In order to simulate this effect, the ball itself has been dented inward, toward the camera, so that its edge matches up with the wall’s corner in the prerendered scene. From the outside, the ball would appear to have a large dent in it, hence our name for it. Because the camera offset is most noticeable when objects are close, gradually falling off to imperceptibility as objects move farther away, the actual dent of a perfectly right-angled wall in the ball would not have straight edges, but would in fact taper out at an increasingly gentle angle before plunging smoothly back into the outside surface of the ball.

Despite our name though, dents aren’t the only method we’ll need to produce proper foreground/background separation while panning. (We should just go ahead and call this separation “parallax effects.”) Reference the pen with one eye closed again. It, like a blade of grass, glasses on a nearby table, and any number of other real world objects exhibit a complete separation from their background. In such cases we’ll need to slice the ball into concentric layers, like an onion, and map a series of cutout portions of the scene onto each. There will be times when we’ll need to combine slices with dents. Depth maps, grayscale images representing simply how far any point in a given image is from the camera, can be rendered from any 3D animation package, and can be used to assist an automated workflow for making these dent and layering decisions.

The Dented Ball allows us to create a richer visual experience, both static and in motion, than any previously conceived graphic adventure engine. By repurposing modern video cards to draw concentric near-3D nodes, we find a new way to leverage the technologies users and game developers already possess. We unify the rich legacy of graphic adventure games like Myst V while discarding our detrimental modern preoccupations. In doing so, we glimpse a third path though the complexities of contemporary game design and begin once again simply to explore.