Wednesday, December 23, 2009

Maze Wars SVG version 1.0b2 Released

Maze Wars SVG version 1.0b2 has been released. The closest thing to a functional change is the addition a partial work-around for a Firefox 3.5.x SVG rendering bug that made the eyeball on the game’s first web page render incorrectly. No code changes, other than the deletion of some old, commented-out material. No changes in game play.

Also, the beginnings of a web site for the game can now be found at http://mazewarssvg.sourceforge.net/.

And, last but certainly not least, I’ve had the pleasure of corresponding with Greg Thompson (thanks Bruce), one of the authors of the original Maze War game, and seem to have received his blessing. Nothing said was usable as an endorsement quote (darn it), but the tenor of the correspondence was entirely positive.

Thursday, December 17, 2009

Maze Wars SVG version 1.0b1 Released

Early this morning, Maze Wars SVG version 1.0b1 was released. This retro multi-player first-person shooter had a couple of the inevitable bugs that always seem to be discovered only after a product is announced to the world. But they were exceedingly minor bugs. And they're gone now.

Enjoy.

Wednesday, December 16, 2009

Maze Wars SVG Finally Released

I’ve re-created the classic, multi-player, first-person shooter game “Maze Wars” using modern web technologies (server-side: Java; client-side: XHTML, Javascript, Ajax, and Scalable Vector Graphics). Today, that re-creation has reached beta status, and I believe is ready for general use. It's available on SourceForge, where you can find not only the GPL source, but a pre-built WAR file just waiting to be deployed to your favorite Java web application server. (I’ve only tested it with Tomcat, however.)

Work on this project began sometime around July, 2008, and after going through several periods of dormancy, is finally clean enough and feature complete enough to merit public promotion. It is based on my recollections (and a few graphics files I held onto) of playing a version written for the original Macintosh, sometime around 1987. When the consulting phone wasn’t ringing, it brought productivity to a halt among our office Mac users for several weeks. Legend has it that it had exactly the same effect on a little corporation called Apple Computer.

I’m not talking about the commercial version that eventually appeared (MacroMind “Maze Wars+”). No, this implementation was something else, and earlier. If memory serves, it had the video RAM address of the original 128K Mac hard-coded into it. I remember patching the binary several times in subsequent years to keep it working (video RAM kept moving as Macs gained memory), but eventually Macs changed enough that keeping the game working was beyond mere binary hacking, and the game effectively died. I have no idea who wrote it (let me know if you do), but thanks to whoever was responsible. A lot of people had a lot of fun with it.

(Of course, profound thanks must also go to the creators of the original Maze War game in 1973: Steve Colley, Howard Palmer and Greg Thompson.)

All these years later, I found myself missing the Maze Wars game, and decided that with Scalable Vector Graphics (SVG) resurgent among modern browsers (Safari, Firefox, and now Chrome) I might be able to recreate it for the web. And it looks very much like I’ve succeeded.

You can get some idea of what the original Macintosh game looked like, and how it built its graphics, from the following files (originally in MacPaint format) that were a part of that game.

There were the eyeballs, of course. All the players were represented by eyeballs. As you can see, they were pre-rendered in parts that could be blitted together to form an eyeball at any of the supported sizes (9) and angles (4). If it’s not obvious, the “ball” portion of each eyeball was the same for every view at any given size. It was only the middle portion that changed, which is why there are renderings of the iris and sclera facing head-on, to the left, and to the right, next to each eyeball, and that’s also why the tail, which appears on the eyeballs by default, is carefully drawn such that it stays within that middle portion of the ball – blitting an iris/sclera section onto the eyeball would completely hide the tail. By blitting (or not) a new middle segment onto each ball, any eyeball view could be created very simply. (The four images occupying the right side of the file weren’t visible in the game. They seem to be the doodlings that led the artist to the final renderings on the left side.)

My eyeballs are a bit simpler, omitting the veins in the sclera, for instance, but they’ve gained things the originals didn’t have, like gradient shadings, and individually colored irises. Seen from behind, they retain the pointed tail, because it just wouldn’t have been the same without it, but, because it took me something like three hours to work out the spline curve definitions for drawing the tail, I decided to forgo including any portion of it in the side views.

The game’s screen looked like the top half of this graphic. The first-person maze view was on the left, on the right was the maze map showing the location of yourself and the teleport stations (the circles), and, if memory serves, in the empty space below the first-person maze view was a list of players and, presumably, their scores. The first-person maze view was, like the eyeballs, built by blitting together the pre-rendered elements in the bottom two squares. Wherever a corridor branched-off the one you were looking into, a vertical slice from the right hand square was blitted over the corresponding portion of the left hand square, and—presto!—the uninterrupted walls meeting at a distant vanishing point were now interrupted wherever necessary. No drawing, as such, was required, just a lot of clever blitting together of off-screen bitmaps.

I’ve used a very similar approach in my implementation—not with bitmaps, of course, but with a collection of pre-positioned SVG wall polygons and corridor rectangles which can effortlessly be made visible or invisible by altering their “style.display” properties—because it’s wonderfully simple and effective, and remarkably authentic. It also uncomplicates the implementation in a lot of subtle but important ways, and it even, I realized, creates a rendering bug in one case. I didn’t notice that bug until I’d implemented it myself, but I’m sure it must have been present (though a bit less obvious) in the original version. In practice, I think almost no one will notice it, so I’ll leave it for you to find – or not.

There are, of course, a number of differences between my first-person rendering and the original. For one thing, there’s gradient shading so that everything fades to black by the time it reaches the vanishing point. There’s a hint of color to the floor. Stretches of wall are not featureless; they are interrupted by vertical black lines where corridors would otherwise branch off. (That may enhance the sense of perspective, but I’d’ve preferred not to have those lines. Things just kind of inevitably turned-out that way, and I couldn’t find a good work-around, or an overwhelming reason for being displeased, so the lines remain.) Teleport discs are visible in the first-person view, and they’re a very obvious blue – matched by their representation in the maze map. And, by the way, the sky is black. I’m almost certain that real killer eyeballs only come out at night, so that was a detail that needed fixing.

Other differences: On-screen instructions as you enter the game! A new, random maze for every round of the game. (However, I’ve retained the original 33 X 46 dimensions of the maze. After some experimenting, the original size seemed just right - neither too big, nor too small, for good play.) Problems with clipping long player names due to bugs in the SVG implementations of Safari, Chrome and Firefox. Bonuses for killing campers. And, last (I think), but not least: Bots, so there’ll never be fewer than ten players in the game, even if you can’t get anyone else to play.

The results look something like this, but, being rendered using SVG, they are resolution independent. So, stretch out the game window to fill your screen and everything scales-up immaculately – giant killer eyeballs!

If you’re comfortable deploying Java web applications, and believe in using modern web browsers, give Maze Wars SVG a try, and please have fun.

Monday, December 14, 2009

Geminids, Margaret, You Were Missed

The weather forecast didn't look promising, but, sunset arrived and our skies were still clear, so I threw my meteor photography gear in the truck and headed for the Bamberger Ranch. After a very nice dinner with David and Joanna in front of the fireplace, we headed out to see the meteors. They headed for the area around the observatory, because it was close; I headed out to the windmill near the red pens – my standard location for some time – since I can incorporate the windmill into my photos to good effect. The Milky Way stretched overhead clear and bright as my truck trundled to a halt near the windmill. There followed the usual tedious unloading and setting-up, and the difficult focus adjustment trial-and-error (focusing on infinity doesn't do the trick). Then the skies closed, and the best meteor shower of the year vanished. I waited out in the dark cow pasture as the wind hurtled past, making the night much colder than it claimed to be, and shaking even the truck as it went. Hours later, I gave up, just as the peak should have been happening. The sky had cleared briefly once or twice, but the clouds rushed back just as quickly as they left. All in all, I think saw only 11 meteors over the course of those cold hours. Most of that time, I was lucky to see a star.

Above, my one meteor photo of the night, caught, purely by coincidence, as one of the focus-checking shots. (View it full-size, and look in the lower-left quadrant.)

I'd been looking forward to this shower all year. Margaret Bamberger and I had even made plans to watch it. But it didn't work out. (Oh, holy crap, how it didn't work out....) Now the long wait for next year's showers begins. And as for this year, I'll be glad to be done with it. Good riddance. I'd dance on its goddamn grave, if it were to have one … and if I could dance.

Sunday, December 13, 2009

Geminids Tonight

The peak of the Geminid meteor shower will be tonight, December 13/14. According to NASA’s Fluxtimator, it promises to be a very good show, peaking at a rate of 66.7 meteors per hour in countryside viewing conditions at 12:16 AM CST. Even as early as 9 PM, which is as early as the Fluxtimator will predict, there should be 46.8 meteors per hour. The only problem around here is the weather, which doesn't look very promising.

Tuesday, December 8, 2009

Parallel Number Crunching – Java and C Source Code

As requested, I've made the source code and sample data for my coplanarity scanning example programs available. These are the programs used to produce the timings shown in my previous post, “Parallel Number Crunching – Java vs. C & Grand Central Dispatch.” Feel free to experiment with them as you wish.

Note that both are hard-coded to break out of their processing loops after the first 5,999,600 planes have been checked for coplanarity with the 30,000 sample points provided in the "data/lc-data-30000.bin" file. That seemed to be a reasonable amount of computation for demonstrating the relative performance of the two implementations. If you want to try to complete the full scan of all possible planes, you'll need to remove that hard-coded break – and then you'll need to wait for a very, very long time.

The more complete Java implementation I've been using for my actual number crunching work has features like saving its processing state periodically, so the program can be quit and later resume running from roughly where it left-off. I've pulled those features out of this example code in order to keep the two implementations similar, small and straightforward.

Here’s wishing you a good night, and good coding.

Sunday, December 6, 2009

Parallel Number Crunching – Java vs. C & Grand Central Dispatch

I've been doing some parallel number crunching lately using Java 1.6 (1.6.0_17) on a MacPro (4,1) with a 2.93 GHz quad-core Nehalem processor. This weekend I decided to brush the dust off my C programming skills and re-implement the core of my Java code in C using Apple's Grand Central Dispatch (GCD) technology to see if I could get a dramatic speed boost. The results were both better and worse than expected.

The number crunching in question was the examination of data from a pseudo-random number generator (PRNG). Specifically, the PRNG output was interpreted as 30,000 triplets of 32-bit signed integers. The triplets were treated as points in 3-space, and the number crunching consisted of the search for every point coplanar with every possible plane those points could define. It's been done before, of course, and found weaknesses in PRNGs like multiplicative congruential generators. For my own edification, I wanted to look for the same weaknesses in some other PRNGs. I have yet to complete a single run, however, so those who've done it in the past either used better techniques than my brute-force approach, had more than my 23 GHz to work with, or were very patient. Maybe some even used worse techniques that were faster. I don't know. In any case, I've been giving the brute-force approach a shot.

My implementation identifies coplanarity as discussed in Wolfram MathWorld: by computing the determinant of a 4X4 matrix. If the determinant is zero, the point is coplanar. The determinant computation includes a lot of multiplies that can be precomputed, because the three points that define the plane don't change for each 30,000 point test, and my code (Java and C) dutifully precomputes the lot. [Some future version of the C code may be able to bring the CPU's vector processing unit, or the GPU's resources, to bear on this problem, but I've never tried vector processing, so that's a challenge I'll leave for another time.]

With that out of the way, here are the results for checking all 30,000 points for coplanarity with each of the first 5,999,600 planes. As you'd expect, lower test times are better.

LanguageEnvironmentTime
Java 1.6 (64-bit)Mac OS X command line811 secs.
Java 1.6 (64-bit)IntelliJ IDEA 7.0.5 console814 secs.
C & GCD (64-bit)Mac OS X command line658 secs.
C & GCD (64-bit)Xcode 3.2.1 debugger console657 secs.
C & GCD (64-bit)Xcode 3.2.1 debugger console with GuardMalloc 18 enabled1,814 secs.

More details: The C compiler was the one supplied with the current Xcode tools, GNU gdb 6.3.50-20050815 (Apple version gdb-1346) configured as "x86_64-apple-darwin". The Java runtime version was 1.6.0_17-b04-248-10M3025 and the virtual machine was "Java HotSpot(TM) 64-Bit Server VM" – in other words it was the current version of Java supplied by Apple for Mac OS X 10.6.2.

The results: Running on a quiescent machine, both the Java and C/GCD applications were able to push the CPU utilization to roughly 795% and keep it there at all times (the "Hyper-Threading" feature of the Nehalem cores enabled each of the four cores to act like two, so 800% was the theoretical maximum in this case). In general, Java was 23% slower than C/GCD. Personally, I'd expected Java to either closely approximate or even slightly exceed C/GCD's performance (because the Java just-in-time compiler can optimize and natively compile the code in a manner optimal to the specific hardware it finds itself running on at any given time, whereas the C compiler might make have to make more generalized assumptions), or for C/GCD to beat Java by many times. Neither outcome manifested, though the first was closest to the truth.

I think that the actual results can be interpreted in a couple of ways: (1) "C with GCD is meaningfully faster than Java for this sort of number crunching", or (2) "Java is a reasonable choice for this sort of number crunching." I lean toward the second interpretation, due to two issues. First, the Java code was, in my opinion, much cleaner, clearer and more re-usable than the C code. Second, Java is doing a lot more work for you at the same time it is crunching numbers – helpful work that can affect the reliability of your code, and/or the integrity of its results, like ensuring memory integrity and runtime type-correctness – and that's work that C mostly doesn't do at all, or does very badly, as seen in the case of running the C version of the program with GuardMalloc enabled at the cost of it taking 2.24 times longer to run than the Java program.

Those issues aside, it must be said that, for this comparatively simple program, Apple's Grand Central Dispatch and its extensions to the C language worked very well, and were easy to use. I still find the new syntax difficult, but past experience with closures, and the examples in Apple's documentation, were enough to let me produce the code I needed, in spite of that. Whether the GCD language extensions, or the GCD API, provide as complete a set of services for concurrent programming as the Java language and its "java.util.concurrent" package, I don't know. The general impression I took away from the GCD documentation was that it provides fewer features to aid the development of concurrent software than does Java, but a day's work with GCD isn't sufficient to let me judge.

To conclude: Compared to C, Java's not half bad for number crunching as I'm currently doing it (in fact, it's somewhere between merely 23% bad, and 224% good); and Apple's Grand Central Dispatch is an interesting and useful extension to the C language.

Monday, November 30, 2009

Weekend Links

From a book I happen to be reading at the moment:

Our bodies are of course what get left out of a theory that treats architecture as a language, a system of signs. Such a theory can’t explain the physical experience of two places as different as Grand Central Station and my little shack, because the quality of those experiences involves a tangle of mental and physical, cultural and biological elements that the theory can’t account for, blinded as it is by old Western habits of regarding body and mind as separate realms. Taking the side of the mind in the ancient dualism of mind and body, this theory can only explain that part of architecture that can be translated into words and pictures, published in magazines and debated at conferences. An architecture that ignores the body is certainly possible; the proof is all around us. But I doubt it will ever win our hearts.

A Place of My Own: The Architecture of Daydreams by Michael Pollan, pg. 214.


And Now, The Links

Sunday, November 22, 2009

Weekend Links

From a book I happen to be reading at the moment:

[...T]his was real work too, something more than mere labor—time put in for pay. [....] At the end we would have something to show for it, would have added something to the stock of reality—to what Hannah Arendt once called the “huge arsenal of the given.” In The Human Condition Arendt writes of the privileged position of homo faber, man the maker of things, whom the Greeks believed stood not only above the laborer, but above even the man of action and the man of thought, or words. The laborer produces nothing lasting he can call his own, and both the man of action and the man of thought are ultimately dependent on other people, without whose regard and remembrance their deeds and creations do not matter or endure.

A Place of My Own: The Architecture of Daydreams by Michael Pollan, pg. 165.


And Now, The Links

Monday, November 16, 2009

Weekend Links

Sunday, November 15, 2009

Bamberger Ranch Preserve Gets an Observatory

I finally get to show my photo of the XXXXXXXXXXX that David Bamberger embargoed until he could make his official announcement on-line: The Bamberger Ranch Preserve now has an observatory, as you can see below.

That was a 30-second, ISO 400 exposure shot by moonlight using a 10mm lens at f/4.5. Because the auto-focus system on my camera didn't have enough light to operate, the focus was accomplished with a bit of luck and a binary search.

The observatory will be a great addition to the Preserve's education programs, and is located within an easy walk of the the Center (see my panorama of the main room of the Center), where groups of school kids come to spend as many as three days participating in educational activities. For myself, despite the moonlit sky, I was able to see Jupiter’s clouds first-hand, for the first-time in my life.

Sunday, November 8, 2009

Weekend Links

Enchanted Rock State Natural Area, Panorama no. 8

This panorama was shot at sunset on December 29, 2008, at Texas’ justly famous Enchanted Rock, a billion-year-old granite dome exposed by eons of erosion. This was shot on one of the boulder strewn slopes, as the sun was rapidly disappearing beneath the horizon. The lighting changed so much during the shoot that I was sure this panorama was a write-off, but this weekend I decided to assemble it anyway, thinking that one or more subsections might be usable and interesting. Surprisingly (to me at least), modern panorama generating software was able to compensate for the continuously changing lighting, and produced, with a little effort, a pristine 360° image. And, because the pano was shot high dynamic range, the ever deepening shadows caused no loss of information.

This was the only panorama I managed to shoot that day. My earlier attempts to shoot a panorama whose centerpiece would have been a boulder about as big as a small house, failed when I had, with great care and not a few misgivings, setup my equipment on the absolute edge of the furthest point of the ledge on which it sat, and found that the boulder still didn’t fit entirely in frame, even with my 10mm lens (which was acting like a 16mm lens on the camera I was using).

I’d planned to spend two days shooting at Enchanted Rock, staying overnight at the Bamberger Ranch in between, but I was so disgusted at that first day’s failure (and the amount of time I wasted in getting there by following an absurd “short cut” to the Rock that Google Maps had selected for me, and the staggering number of people that were there, and the difficulty/danger of climbing to obscure boulders while carrying 40lbs of camera equipment), that after dinner with the Bambergers (and Leroy Petri) I decided to throw in the towel and just go home. At the time, Margaret said she’d like to join me at the Rock for a day of photography, and we’d planned to do that this past summer. Sadly, she died before that could happen.

What’s the line from the Death Cab for Cutie song (What Sarah Said), “every plan is a tiny prayer to Father Time”?

Tuesday, November 3, 2009

I’ll See Your “Monday Moment of Zen” and Raise You...

Old friend Jay Lake offers a “Monday Moment of Zen” photo this week, and, for a change, I think I can get in on the action.... Consider this your “Tuesday Moment of Zen.” © 2007, 2009 by Chris W. Johnson.

Monday, November 2, 2009

Weekend Links

Sunday, November 1, 2009

Drought Plus 10 Inches, Minus Barbecue

I was out at the Bamberger Ranch Preserve this evening for their annual volunteer appreciation gathering. Arriving with the sun low in the sky, but with a little time before sunset, I quickly found the legendary J. David Bamberger and asked for permission to head up into High Lonesome to re-photograph the tanks I showed in my Drought with a Side of Pig posting, early in September. He agreed, and I dashed out of the party just as the food was beginning to show up.

I borrowed a friend's truck (having bummed a ride to ranch), drove out along the ranch's main road, took a right at the misleadingly named Hes' Country Store (it's half museum, half bunkhouse, and not one bit a store), there leaving pavement behind, then bumped and juddered my way up a pair of well-worn, rock strewn, tire tracks into High Lonesome, and eventually parked in my usual spot, halfway up a valley wall. Shouldering my 40 pounds of photographic equipment, I started hiking toward my favorite valley as fast as the terrain would permit. My interest was in in seeing how the tanks had changed after at least 10 inches of rain had fallen in the last month or so.

Regular readers will recognize the photo above of the drought-stricken tank cooking in September's hot afternoon sun. The photo below was taken by twilight this evening. Leaving aside the gentler lighting, though still far from full, the tank is transformed. The bare, burned ground with a shrinking pool of sickly orange water at its center is now a decent-looking body of water, and every bit of grass and other ground cover has surged back to life.

That tank has looked a lot better in the past, for example in April of 2007, as seen below, but the rains have made a huge difference, nonetheless.

Unfortunately, in order to a make-up for the drought's damage, we need even more rain than the latest photo suggests. As you may recall, the tank in a neighboring valley had dried-up completely when I visited it this September:

This evening, seen below from a different angle, that tank is still dry. More than ten inches of rain simply vanished into the bone-dry soil. In exchange, there's a lot more vegetation, but still not a drop of available water.

So, wish us more rain, world. Central Texas is far from recovered from its drought.

* * *

Those pictures turned-out to be more expensive than I expected, by the way. The camera and tripod took a tumble from my shoulder to the ground as I struggled to simultaneously untangle a leg of the tripod from both the branch of a bush on the trail, and one of the little bungee cords on the back of my camera gear backpack. The camera wouldn't power-on after that fall, and only a methodical disassembly and reassembly of all the bits and pieces led to the discovery, to my relief, that the problem was confined to the camera's battery grip. Removing that and going back to single-battery operation brought the camera back from the dead.

Adding hunger to injury, by the time I made it back to the volunteer appreciation party, all of the barbecue, side dishes, and even the cake had been eaten. I had to settle for a plate of beans, and the last fragment of cake – so sad a remnant it was that nobody else had been willing to touch it.

Alas, trying to take a beautiful photo can be an expensive undertaking in a lot of ways, and, while you can bet on the expense, the beauty has a way of being elusive.

* * *

As it happens, my best photo this evening was of the XXXXXXXXXXX, shot hours later by moonlight, but David has embargoed that image until he's ready to announce the XXXXXXXXXXX at some unspecified, future date on his blog.

Sunday, October 25, 2009

Weekend Links

Sunday, October 18, 2009

Weekend Links

From a book I happen to be reading at the moment:

The prevailing theory as to why, as a species, we left off hunting and gathering is that we had ruined that perfectly good lifestyle by overdoing it, killing off the megafauna on which we depended. Otherwise, it's hard to explain why humans would ever have traded such a healthy and comparatively pleasant way of life for the backbreaking, monotonous work of agriculture. Agriculture brought humans a great many blessings, but it also brought infectious disease (from living in close quarters with one another and our animals) and malnutrition (from eating too much of the same thing when crops were good, and not enough of anything when they weren't). Anthropologists estimate that typical hunter-gatherers worked at feeding themselves no more than seventeen hours a week, and were far more robust and long-lived than agriculturalists, who have only in the last century or two regained the physical stature and longevity of their Paleolithic ancestors.

The Omnivore's Dilemma by Michael Pollan, pg. 279.


And Now, The Links

Sunday, October 11, 2009

Weekend Links

From a book I happen to be reading at the moment:

[...S]ince the human desire for sweetness surpases even our desire for intoxication, the cleverest thing to do with a bushel of corn is to refine it into thirty-three pounds of high-fructose corn syrup.
That at least is what we're doing with about 530 million bushels of the annual corn harvest—turning it into 17.5 billion pounds of high-fructose corn syrup. Considering that the human animal did not taste this particular food until 1980, for HFCS to have become the leading source of sweetness in our diet stands as a notable acheivement on the part of the corn-refining industry [...]

The Omnivore's Dilemma by Michael Pollan, pg. 103.


And Now, The Links

Sunday, October 4, 2009

Weekend Links

From a book I happen to be reading at the moment:

[....] McNuggets also contain several completely synthetic ingredients, quasi-edible substances that ultimately come not from a corn or soybean field but from a petroleum refinery or chemical plant. [.... Including] “anti-foaming agents” like dimethylpolysiloxene, added to the cooking oil to keep the starches from binding to air molecules, so as to produce foam during the fry. The problem is evidently grave enough to warrant adding a toxic chemical to the food. According to the Handbook of Food Additives, dimethylpolysiloxene is a suspected carcinogen and an established mutagen, tumorigen, and reproductive effector; it's also flammable. But perhaps the most alarming ingredient in a Chicken McNugget is tertiary butylhydroquinone, or TBHQ, an antioxidant derived from petroleum that is either sprayed directly on the nugget or the inside of the box it comes in to “help preserve freshness.” According to A Consumer's Dictionary of Food Additives, TBHQ is a form of butane (i.e. lighter fluid) the FDA allows processors to use sparingly in our food: It can comprise no more than 0.02 percent of the oil in a nugget. Which is probably just as well, considering that ingesting a single gram of TBHQ can cause “nausea, vomitting, ringing in the ears, delirium, a sense of suffocation, and collapse.” Ingesting five grams of TBHQ can kill.

The Omnivore's Dilemma by Michael Pollan, pp. 113-114.


And Now, The Links