The draft-standard Gamepad API allows JavaScript in the browser to obtain input from connected gamepad/joystick devices. This is of course useful for games, so I have worked on adding support for it to Cubes.

This (about) is the only Gamepad API demo that I found that worked with arbitrary gamepads (or rather, the junk one I had around) rather than ignoring or crashing on anything that wasn't a known-to-it devices such as a PS3 or Xbox controller. (It's part of a game framework called Construct 2, but I haven't investigated that further.) It was critical to my early setup in making sure that I had a compatible gamepad and browser configuration.

(There's a reason for libraries having information about specific devices — the Gamepad API just gives you a list of inputs and doesn't tell you what the buttons should be called in the user interface — and these days you're almost expected to have pictures of the buttons, too. But there's no reason not to have a fallback, too. Incidentally, the USB HID protocol which most gamepads use is capable of including some information about the layout/function of buttons, but this information is often incorrect and the Gamepad API does not expose it.)

In order to integrate gamepad support into Chrome, I used Toji's Game Shim library, a very nice lightweight library which only adapts browser-provided interfaces to the current draft standards so that you can use the Gamepad API, as well as requestAnimationFrame, fullscreen, and pointer lock, without making your code full of conditionals or browser-specific prefixes.

On compilation

Wednesday, October 26th, 2011 20:46

Consider an interpreter as a function (Program, Input) → Output. Then:

A compiler is an optimized curried interpreter.

(Further reading: The Three Projections of Doctor Futamura)

Source: What is it? set 403 (a weekly "Identify these objects" puzzle).

The Witness

Sunday, August 14th, 2011 07:54

So, this is potentially interesting. The developer of the game Braid has started a new project, The Witness. It’s apparently going to be 3D, set on an island, and involve solving puzzles scattered around the island (while being able to move freely around it). Their blog is talking a lot about their graphics engine design as opposed to the gameplay — naturally, as graphics tech is more usefully shareable and isn't inherently spoilerish.

What particularly caught my eye as “I agree with this” was their post Experiments in Texturing. Good textures are hard; it's often easier to make a good, clean model than it is to make a texture that is not jarringly unrealistic. The Witness is putting a lot of emphasis on lighting: “We’re on a low budget here, being an indie game; so not only was it an open question how to solve the Ugly Texturing problem, but we also needed to solve it with relatively little manpower. I knew that, ultimately, we could just fall back on untextured geometry with lighting, if we had good precomputed lighting.” They go on to describe using textures as accents, to add texture rather than defining significant features of the object.

As a Minecraft player (structures are built of pre-textured blocks) and former Avara map designer (graphics engine does not support textures), I entirely approve of this approach.

I have updated the Minecraft topic at my web site, bringing it up to date with changes, adding many new links, and information about my new world. Also, I didn't previously announce this:

I am running a Minecraft server. I've been running one for a while, but it had a rocky start trying to run on a shared Linode. It now has a dedicated machine (though one which is rather old and running on a home cable connection) and is running 24/7.

The address is:

This server runs a copy of my single-player world, updated each day, so changes you make are not persistent (except for your inventory). This is a place to tour, or use for building experiments, not to live in. However, I have attempted to make it suitable for multiplayer use, with direction and instruction signs and multiplayer-capable rail stations (though most of the rail tunnels are single-track).

Feel free to suggest improvements to the facilities, or additional builds.

(Home sweet home.) (Cactus and flower farming.) (Mob tower and access routes.) (Rail hub station.)

(Note for those who have tried the server before: I recently fixed a problem causing new players to spawn nowhere in particular rather than at the spawn station.)

The problem of arranging a set of unbreakable text blocks in columns in an arbitrary order such that the columns are of approximately equal height is equivalent to the NP-complete “multiprocessor scheduling” problem, and the “LPT algorithm” described in the linked article performed excellently for my instance of the problem (4 columns, 6 blocks), which is actually my packing list for traveling to California tomorrow.

(I have a program which generates my packing list for me, based on type, duration, season, and transportation. It encodes all the accumulated knowledge about what to pack and where to pack it; after a trip I review my changes written on the printed list and incorporate them into the program.)

I’ve added an Android topic to my site, including listings of apps I use.

Distinctly incomplete, but better published than not.

I have a simple guideline for real life interactions with others that carries over quite well on-line, "Deal with issues; ignore details."

It's amazing how well this works in person, especially when trying to get something done. My number one question to another is probably, "Is that an issue or a detail?" We can almost always decide together which it is. Then, if it's an issue, we deal with it, and if it's a detail, we move on to the next issue.

This has also saved me countless hours and aggravation on-line. If I post something and someone disagrees, I quickly decide whether or not it's really an issue and only engage the other if it is. I realize that this is just a judgment call, but I'd estimate about 90% of on-line disagreements are just details. In these cases, I think it's best to simply move on.

edw519 at Hacker News

I thought this was, even if not necessarily a rule to immediately apply oneself, at least a concept worth thinking about. (Read the further discussion as well.)

Having repeatedly heard the “they tried to evolve an oscillator in a FPGA, but got a radio instead” story, I was glad to encounter (via Making Light) a link to the original paper, “The Evolved Radio and its Implications for Modelling the Evolution of Novel Sensors”.