See, guys be buyin' laptops like this but ladies be buyin' laptops like that.

via Unfogged

---

Ah, this has been tried before.

Item one: drskipper and I each have an extra ticket to see Star Trek this Saturday 5/9 at the Kabuki at 7:15. Assigned seating, cocktails in your cushy seats, and nearby nerds. You know you want some of that. Contact me if you're interested. Never mind.

Item two: I'm generating some HTML that is going to include a large number of thumbnail images. Each thumbnail image wants a text caption right below it. I would like the thumbnails to fill the width of the browser page, however many happen to fit, then spill over to successive lines.

If I just had the thumbnails and no captions, I'd just put a bunch of <img /> tags in a row and it would do what I want.

If I make each image-and-caption pair into a table, it won't put them side by side. If I make each image-and-caption pair into a <td> cell in a single table row, it doesn't wrap.

Is there a good way to do this?

<style type ="text/css">
.gallery table { float: left; margin: 0 5px 5px 0; }
</style>

 ...

<div class="gallery">
<table><caption align="bottom">caption 1</caption><tr><td><a href="img1.jpg"><img src="thumb1.jpg" /></a></td></tr></table>
<table><caption align="bottom">caption 2</caption><tr><td><a href="img2.jpg"><img src="thumb2.jpg" /></a></td></tr></table>
<table><caption align="bottom">caption 3</caption><tr><td><a href="img3.jpg"><img src="thumb3.jpg" /></a></td></tr></table>
</div>

...no, I didn't just fly in from the coast. I finally broke down and got the Meinl Trejon. It's an oversized cajón with three separate face pieces to give more variety in tones.

I've been practicing since it arrived, trying to go half an hour or an hour at a time. I don't keep very good time alone, but I've been setting iTunes to shuffle my whole music collection and trying to play along with whatever comes up. I fast-forward through anything that's just not working, and occasionally pick something specific when I think of it. It's more inspiring than a simple metronome.

After an hour of that tonight, my hands and arms are definitely tired.

Anyone else done much hand drumming? Any tips or suggestions?

Sound Designer B has just demonstrated a cool little game-polish feature.

Me: "Is that for [Title 1] or [Title X]?"
B: "[Title X]. And I'm glad you asked me that because I was about to break into a Bon Jovi song."
Me: "Guess we dodged a bullet there."

I dreamt that I was in an argument with a religious zealot about his sacrament. I knocked the cup from his hand. It spattered all over the floor between us, much to his shock and dismay.

I screamed at the guy that while maybe God had a part in creating the cows and the bushes and trees, the fruit smoothie itself was not a sacred thing, but merely a product of man and blender.

So the big buzz at GDC is about the OnLive gaming service. The basic idea is that OnLive is going to run high end PC games on high end machines and pipe the video to the consumer. The consumer runs a very thin client, either a cheap set top box or a PC or Mac -- and the draw here is that the consumer doesn't have to have a high end gaming machine, because all it has to do is send controller inputs and decode some video.

They apparently have invested a lot in a low latency video codec and a lot of video routing hardware, which is admittedly neat.

Network latency, though, is a problem. They're adding a layer of network latency that isn't compensated by the game! So single-player games that were never designed for lag get lag, and multiplayer games are compensating for the game-client-to-game-server lag, but not game-client-to-player lag.

They've got a datacenter in Santa Clara, another one active probably on the East coast, and they're building one in the Midwest. It's possible that by putting their datacenters next to existing online gaming servers, they can keep the best-case latency down. However, if I'm in, say, Austin, and I want to play on a server in Austin, I'm going to be routing through Santa Clara on both the server-to-game-client and game-client-to-human-client legs, for about 30ms* additional latency at best. This is probably okay for casual gamers, but I don't think the hardcore will accept it. I'd rather have 100ms of compensated latency than 30ms of uncompensated latency.

Their whole plan is aimed at the casual gamers who don't want to spend $3000 every couple of years on a high end gaming PC. Every machine OnLive buys at that spec gets to serve several players, because not all of them are going to be playing at once, so in that sense it could be cost effective.

However, most existing online gaming services serve several players from each running server. It's not unusual to run 20-30 players on a single server on an FPS like Team Fortress or Counterstrike. OnLive has to use a single machine per player, at least for high-end games. That has to change the economics a lot. I'm not sure how they can find a price that keeps the GPUs humming without driving away the "casual" gamers.

I'd be pissing myself if I were in charge of provisioning the datacenters. If you're serving web pages and load increases beyond what you anticipated, the pages get delivered a little slower. If you're serving games, and load increases beyond what you anticipated, little Johnny doesn't get to play. GPUs don't timeshare well.

In the GDC demo, they show Prince of Persia resuming from a pause screen from the main user menu. No idea how they're planning to make that work in general. They'd need to be able to record and restore main memory, process context and I think even GPU state to make that work right. 4GB of storage per user right there, but disk space is cheap.

Presently, a typical online game sends ~100 bytes/second client->server and pulls down maybe a couple Kbytes/sec server->client. OnLive has the same upstream requirement but is doing ~100 times that in download. Their standard-def bandwidth requirement is 1.5Mbit -- "only" typical baseline DSL speed nowadays, but to us old-timers that's a full T1. There's enough variation in people's network situations that I can't say what the implications are for everyone, but for "casual gamers" with cheap broadband, OnLive is going to try and take the full pipe. So when little sis goes online to torrent the latest Jonas Brothers release**, your video is going to go to shit. In a traditional game, when this happens your latency goes to hell, but thanks to the lag compensation, the game may still be playable.

I'm calling it right now: in two years, no one will care about OnLive.

---

* Assume that network routing distance is similar to road routing distance. Google maps gives 1721 road miles for Santa Clara to Austin. 1721 mi / 186000 mi/sec (speed of light in vacuum) * 1.5 (roughly the index of refraction for glass fiber) * 2 (round trip latency) = 28ms best case.

** Did I get that right? I'm so bad at pop culture reference.

Short Version: March 5 is the square root of Christmas; Nerdigras is the interval between sqrt(xmas) and Pi Day. Long version here.

Zero Punctuation finally caught up with my game.

Saw this on Ned Batchelder's blog: Fast Geometric Hashing for Automated Astrometry -- a solution to the problem of examining a photo of a section of starry sky, and figuring out what part of the sky it is.

Probably has applications in other fields as well, *cough* Forrest *cough*.

Every once in a while I run the numbers to compare my current computer to my first computer.

My first computer was a Radio Shack TRS-80 Model I. 16K RAM, 12K ROM. Boots up nearly instantly into a BASIC interpreter. None of your weak sauce Apple Integer BASIC, this is Microsoft Level II BASIC with floating point support. It was pretty awesome.

My new computer is a Macbook Pro, 15", 2.8GHz.

CPU: roughly 30000 times faster. The Z80 CPU is sort of the bastard great-great-great-great-great-uncle of the Core 2 Duo in the Macbook. The TRS-80 ran at 1.77MHz, but required 7-20 clock cycles to execute most of its instructions. Let's call it 0.1 instructions per clock for ~0.18 MIPS. New machine, 2.8GHz, lots of execution units, dual core, let's be conservative and say it's doing 2 IPC for 5600 MIPS.

Memory: about 250000 times more. 16KB on the TRS-80. 4GB on the MBP.

Mass storage: roughly 3,000,000 times more. The TRS-80 stored programs on a cassette tape at 500bps. That's 90KB on one side of a 60-minute tape. There was a floppy disk drive available for the machine, but I never had a reliably working one. You'd need to fill a small house floor to ceiling with cassettes to have the same storage as the internal hard disk in the MBP.

Mass storage read speed: roughly 600,000 times faster. You'd take about 5.5 minutes to load all of memory from tape on the TRS-80, about 2 minutes to load all of memory from disk on the MBP.

Display resolution: 18 times the pixels. 200 times the addressable pixels. 5000 times the bits. Part of the character set on the TRS-80 was reserved for a 2x3 pixel grid in each character cell. You could get a whopping 128x48 pixel resolution, black and white, out of it. One cool thing about it was that you didn't have to switch between text and graphics mode; each cell had either a nice crisp text character or 6 blocky pixels in it. Great for games. Technically the display resolution was higher than that, 384x192, but wasn't addressable at that resolution.

Display memory: 5000 times more in a single screen, 500,000 times more total. TRS-80 had 1KB of display memory, arranged as 16 lines of 64 characters. The native 1440x900 display resolution of the MBP needs 5MB for millions-of-colors mode, and has tons of memory to spare beyond that, mostly intended for texture maps for games and lickable GUIs.

We got our TRS-80 in the summer of 1980 for $750, used. 16K level II TRS-80s were sold for about $1100 new. Adjusted for inflation, the cost of a new TRS-80 is remarkably similar to the cost of a new MBP.