![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
That one data structure can always be decomposed into multiple data structures with equivalent semantics doesn't imply it's unquestionably incorrect not to separate them. That two things can exist separately doesn't mean it's wrong to combine them, particularly when they are intrinsically related and the alternative is maintaining redundant state which must be kept synchronized. That's the problem with dogmatic proclamations. Understanding where to draw the line is crucial to optimizing both machine efficiency (via less storage and runtime effort) and programmer efficiency (via less code and fewer bugs). The complexity of a system grows exponentially with each such layer of decomposition. Is the stopping point arbitrary? I claim it is an engineering compromise, informed by the anticipated value of additional modularity, with the prerequisite that one structure can be mapped onto another without loss of necessary information, and "necessary" here meaning things which you are already or can reasonably foresee using, not any arbitrary property which you might invent.
Certainly you would not check pixel values to determine if a menu is open. The mapping from semantic elements to rendered pixels is complex and seldom invertible. You might reasonably ask the UI toolkit if the menu is open. You can keep track of this yourself, but you must anticipate every way the menu might become closed: both by the operating system, or by other code in your application - perhaps written by someone else - that bypasses your intended function for changing this state. If you don't insist on recording this information yourself, you write less code, and with a single definitive source there is no possibility of inconsistency. This is precisely what the referenced article argues against, though it may be a case of a poor or overly simplified example.
An aside: The pixel example is, by coincidence, relevant to a point I've been thinking about lately. Game systems from the early 80s did something that seems unthinkable by modern standards of software hygiene: collision detection was often handled directly by the video hardware. Semantics and presentation, completely conflated. Yet, as a programmer, the choice is that of checking a few flag bits indicating collisions between objects and/or the background, or performing a separate pass through the objects to check for collisions yourself. It makes sense to use the information if the hardware provides it, and it makes sense for the hardware to provide it, because it's just a few extra AND gates and flags to add there, versus an expensive and complex loop in software. This choice imposes constraints on the application, yet often it was the correct one. Where it wasn't, a price was paid in complexity and (potentially) performance. To my surprise, just when I thought this kind of coupling was relegated to the past, it emerged in modern systems with a new twist: the hardware occlusion query. Meanwhile, I think about efficient 2D collision detection in sparse environments. In the past, I've used spatial hashing. In the future, I may use a quadtree. It pleased me to realize that, in the service of detecting collisions, a quadtree can also contain all the information needed to render the objects, storing pointers to transformed rectangles of pixels in the leaves, and it's conceivable that simple hardware could output video directly from the tree with no intervening framebuffer (though perhaps less simple if it tries to make the most of the available memory cycles). Indeed, a quick search indicates direct scan conversion of quadtrees has been researched in the past.
All that said, hiding application state in the DOM tree sound like a dubious proposition. However, is menu visibility truly important application state, or just an irrelevant property of the menu's presentation? Core application logic should only care when a menu item is selected, and not about the menus themselves at all, as the most starry-eyed proponents of "Model-View-Controller" architecture will insist. That patterns or philosophy can guide the way without always being reified as code and data - often in excruciating detail - is a point too often overlooked, and the cause of much unnecessary labor and suffering. This may be the common folly of a C++ design pattern cultist and a dynamic language enthusiast: one idolizing grandiose generalizations with extraneous code; the other enshrining often-irrelevant information while insulating himself in idealized reflections of the outside world, in the name of consistency, introspection, or simplicity.
- Music:Various NES soundtracks
Features:
- 80's retro McCLIM user interface.
- No documentation or online help.
- Maximally frustrating color sliders, using IHS colorspace.
- Intuitive modeless drawing UI, achieved by including only a pencil tool.
- Saves/loads files only in its own format, based on unportable s-expressions.
- Requires X11 and SBCL with threads, to keep out the riffraff.
- User-editable brush shape.
- Remap Color and Silhouette commands, for tracing previous frames.
- Realtime animated preview plays while you work.
Update: I've added the ability to export an animated GIF file, using Xach Beane's Skippy library. Here's the "turtle.anim" example file, exported as a GIF:
- Music:De La Soul, "Breakadawn"
My idea, then, is to hack the SMB1 cart to make it better suited to the casual player. I take inspiration from, of all things, Quake 3: Arena. First, add a level select screen. I'm sick of endlessly replaying World 1. Second, some stat keeping to encourage replay. It should at least record the time to completion and score accumulated during the level. It might be worthwhile to give the player only one life to use during a run through a level, to make things more interesting, and stop them from gaming the scoring system. Naturally, add save ram and a battery so this data is preserved. Finally, more levels. You could integrate the whole of SMB2j, and possibly fan-made levels from the internet.
On the technical side, move it over to an MMC1/3/6 board with a battery, and you'll have plenty of space to cram in various hacked versions of the games. Write the main menu, make some minor hacks to the games to integrate them with the scoreboard, and you're set. Shouldn't be too difficult, although it isn't something I want to spend time on right now. Perhaps something like this already exists, among the hundreds of SMB romhacks that no one has time to dig through.
- Music:Fallout 1 soundtrack
I was surprised that a quick "apt-cache search" didn't find anything. Looking around the web, there are a number of interesting engine ports, but most of them looked undesirable from the perspective of someone wanting to play the game more or less as it was originally made, not with upgraded rendering technology, new models/textures, or the other cool things that most of the engine ports indulge in. New features thus became a turn-off, and I went for the most plain-sounding engine port I could, SDLQuake.This had a few problems, which I fixed:
- Autotools bit rot
- Use SDL 1.2 (check for SDL 1.0.9 failed)
- Fix config.cfg loading (it tried to reload from a different directory than it had been saved, losing my key bindings every time)
- Fix garbled sound (set sample rate to 48 KHz by default - ALSA still sucks)
- UDP netcode seemed to be doing a blocking instead of non-blocking read.
- Start in fullscreen by default
- +mlook at startup
- Compile a glquake executable (right now it's only compiling the software-rendered version)
- Support for streaming the ripped soundtrack from .ogg or .mp3 files.
Anyway, maybe someone will find this useful - or, perhaps, someone will think I'm a moron for screwing with this instead of using one of the other Quake engine ports. Either way, I've thrown the code up on Github here.
- Music:Nine Inch Nails, "Down In It"
I'll have to find an old version of NASM and figure out how to extract this section, as there really isn't any substitute.
In particular, I made a point of ensuring that the library scan (a recursive walk of the directory) completes as quickly as possible, within reason. My benchmark was the combination of find and grep, which not only traverses the entire tree but does some useful processing on the result. It's not possible to reach that speed without writing excessively low-level Lisp code, but I got close enough that I was happy with the result. It may sound surprising for a task like directory traversal, but any cute processing your Lisp's filesystem interface does - consing/converting strings, decoding characters, building pathnames, converting C structures into nicer Lisp structures, etc. - quickly eats away at this peak performance. Those system calls run a lot faster than I first expected, once the relevant kernel caches are warmed up.
I've been playing with sshfs this evening and wanted to try using it to access my music library on the other side of the planet from a local Shuffletron instance (with appalling but sufficient latency and bandwidth, despite ostensibly being multi-megabit connections on both sides). Oddly, Shuffletron couldn't find any files - it said the library was empty. I soon recalled a potential corner I had cut in the filesystem scanning code.
While scanning the directory tree, you have to figure out whether each entry is a file, directory, or something else. Originally I had done this by calling stat and checking the st_mode field (I'd borrowed the functions from some code that had other reasons to stat the file). While converting the code from sb-posix to osicat-posix for portability to CCL (and beyond!), I cleaned it up to use the struct dirent.d_type field instead, obviating the call to stat. man 2 stat says this about the d_type field:
Other than Linux, the d_type field is available mainly only on BSD systems. This field makes it possible to avoid the expense of calling stat(2) if further actions depend on the type of the file. If the _BSD_SOURCE feature test macro is defined, then glibc defines the following macro constants for the value returned in d_type:
It's available on Linux (except for old versions)? Great, my program only works on Linux anyway, I'll use it! So went my reasoning. I had some misgivings on account of the note "If the file type could not be determined, the value DT_UNKNOWN is returned in d_type," but it seemed to work well enough, and figured I'd just move on rather than write the extra eight lines (!) of code to deal with what appeared to be an obscure case.
With sshfs, I finally found that obscure case. The dtype is always set to DT_UNKNOWN, and shuffletron can't get past the root directory of the library. Despite having written a (simple) FUSE filesystem myself, it isn't immediately clear how you can make that work from the filesystem's side, but it is clear that it was time to add a fallback to calling stat. Having done so, Shuffletron now happily scans my music library over sshfs, which would be great, except that it also takes something like 15 minutes walk the directory tree (even using find!), because every directory appears to involve several trips over the internet. Hundreds of directories times a few seconds each.. not good (this same thing annoys me when copying multiple small files via SCP, incidentally). Just goes to show that presenting something (a computer many thousands of miles away) as something it's not (a local filesystem) can only work so well. If only there were an interface (is there an interface?) to indicate the desired access pattern, so that sshfs could pull all that information quickly in a single batch and keep it in its cache.
This little fix will be present in the forthcoming Shuffletron 0.0.5 release, along with other great features that I've been dutifully testing since July or so. :)
Although it's nearly half a year old, I only decently happened upon John Harris's article Game Design Essentials: 20 RPGs. It discusses the evolution of the CRPG/JRPG genres from war gaming and paper role playing games, surveying many the most influential early series in the genre.
I'm a relative newcomer to the roguelike genre. Aside from some childhood exposure to Gateway of Apshai (a crude action game with Rogue influences), I didn't play any roguelike games until taking up nethack sometime in 2006 or 2007. Subsequently the genre has made a big impression on me, providing a solution to certain major problems in game design. Harris appears to agree, as he writes about Nethack:
Nethack is a roguelike, and so I'm required to say something about one of those games' most controversial features: permadeath. (Okay, I admit it -- I've been leading up to this.) Since Ultima and Wizardry, but unlike pen-and-paper games to this day, players are allowed, and even encouraged, to save games and return to them if things go badly, a design characteristic that makes it almost impossible for anything really bad to happen to the player's characters.
I make no secret the fact that I consider this one of the most pernicious aspects of CRPG gaming, that permanent disadvantages acquired during the course of play cannot be used by a designer because the player will simply load back to the time before the disadvantage occurred. Admittedly, the prevalence of this attitude comes from some older games that could easily be made unwinnable if the player wasn't careful.
However, it's reached the point where "adventuring" in an RPG rarely feels risky. Gaining experience is supposed to carry the risk of harm and failure. Without that risk, gaining power becomes a foregone conclusion.
It has reached the point where the mere act of spending time playing the game appears to give players the right to have their characters become more powerful. The obstacles that provide experience become simply an arbitrary wall to scale before more power is granted; this, in a nutshell, is the type of play that has brought us grind, where the journey is simple and boring and the destination is something to be raced to.
Nethack and many other roguelikes do feature experience gain, but it doesn't feel like grind. It doesn't because much of the time the player is gaining experience, he is in danger of sudden, catastrophic failure. When you're frequently a heartbeat away from death, it's difficult to become bored.
Later, he strikes at the heart of why roguelike game mechanics are so compelling:
The theory I have about the engagingness of roguelikes is that they are a form of random narrative generator. The ups and downs of the player's progress becomes that of the story of the character, who has a relatively plain backstory in order to allow the player to invest more of his own personality into him. Most of these stories end in death, but so do our own, and it makes the few stories that make it to the end even more memorable.
The randomness and difficulty of the game, additionally, help to take responsibility for the failure away from the player. The player knows it's hard so any progress he makes is a sign of valor and heroism, instead of poor decision-making or foolish risk-taking. These kinds of stories aren't made up by a script writer; they come from the player's own actions, so they feel more "real."
Also, on JRPGs and Final Fantasy's decent into absurdity:
All RPGs traffic in abstractions. To some degree, an RPG can only be as successful as the extent to which he causes the player to ignore how arbitrary it all is. One of the signs of the aging of the JRPG genre is how its games have, recently, become less careful about how blatantly made-up their various systems are.
I'm a huge fan of the original Final Fantasy and became less fond of each successive game in the series, for roughly the same reasons that lead me to claim that Wing Commander 1 is far better than its sequels. Both franchises could be described as "stagnant and wallowing in its own cinematic pretensions," as Harris says of Final Fantasy. The intrusion of increasingly overwrought stories steal ownership of the character(s) from the player and destroys replayability.
If that sounds like your thing, give the article a read. It's quite long. I enjoyed it, and can't wait to read the rest of the series.
- Music:NWA, "Fuck tha Police"
I've long searched for poignant phrase to capture how I feel about a certain style of programming. I've finally spotted one courtesy of Dadhacker: "an attempt to be “grown up”. From this post:
Someone had read the Software Patterns book, because about every third source file implemented a factory; I’m pretty sure there were factories for making factories. Now there are perfectly good reasons to write factories, fine and wonderful reasons to have abstract instantiation, but what was going on in the bulk of this company’s code was fear, realized with indirection and thousands of lines of creative procrastination, and an attempt to be “grown up” with stuff copied from a popular book on design without doing any actual design.
I intend for this to be the last release with an ambiguous license. Right now I am constrained by the terms of the M6502 code, which has some "no commercial use" clause in it, preventing me from applying my preferred MIT-style license. I began writing a replacement 6502 core with no strings attached, but that effort has taken a six month hiatus. Rewriting the CPU core will also get me one step closer to cycle-accuracy - close enough that if I were really serious about it, I'd have to rewrite the video... again. Bleh.
Here are a few changes I do remember:
- Keyboard input now works correctly when there's no joystick connected
- Stripe recording (see http://ahefner.livejournal.com/13165.htm
l) - "Screenshot movie mode" (toggled by Control-F12)
- FUSE filesystem support, disabled by default (see http://ahefner.livejournal.com/14789.htm
l)
Also, I've started including the git repository in its tarball, tripling its size. I think this is terribly inconsiderate, but I deleted the old git repository on the web server, so I feel like I have to back it up somewhere. I still don't understand these mixed messages from the git enthusiast crowd, where on the one hand they claim that pushing to a central repository isn't really done, but then go off and appear to use github for exactly that purpose. Whatever. They are strange people.
Previously I mentioned my simple music player in CL, Shuffletron. Shuffletron uses save-lisp-and-die on SBCL or save-application on CCL to create a standalone executable, and is launched by a wrapper script that invokes it with rlwrap when available. It depends on several foreign libraries (more than I expected, in fact), and there were an alarming number of problems with the binaries I'd originally posted, all related to these library dependencies. I think I've solved them, though not necessarily in an optimal way.
The first problem, observed and fixed before the publically released binaries, was an issue where cffi-grovel (on behalf of Osicat) created a shared library with some auto-generated C wrappers for various functions, which the saved executable now expected to reopen at startup. I didn't realize this until my first user reported it dying at startup with an error about not finding /home/hefner/clbuild/source/osicat/posix/w
The next problem was simple - on machines without the libc6 development package installed, the program failed at startup, unable to load librt. This was a simple matter of Osicat not using the best choice of name by which to load the library, a problem which has since been fixed. To be doubly certain, I modified the build script to close this library before saving the executable, because I wasn't using any functions from it anyway.
The most aggravating problems I encountered were with the libmpg123 library. Some users reported "undefined alien function" errors whenever they tried to play a song. Others reported a scary error about stack alignment as soon as the problem started. To some extent I haven't solved these (in the sense that Mixalot users and people building from source may still get bitten by them) so much as hacked around them for the sake of the binary release. There were two basic problems:
- On 32-bit Linux, with newer versions of libmpg123 than my Debian-running laptop happens to have, the compile-time choice of large file support breaks binary compatibility with the libmpg123 library, wreaking havoc with the FFI bindings. Specifically, if large file support is enabled, a number of symbols change names, e.g., mpg123_open becomes mpg123_open_64. This is irritating and not how I'd have done it (for instance, I don't think the version number of the shared library changes to indicate the break in compatibility), but I could've easily worked around it in mpg123-ffi by detecting which version is present at the time the library is initialized. I very nearly did so, were it not for the following problem:
- On 32-bit Linux, due to the desire to have properly aligned data when using SSE instructions, recent versions of GCC provide support for aligning stack frames along larger boundaries, such as 16 bytes. The mpg123 developers seem to take this support as sufficient justification to ignore the platform ABI, introducing dubious stack alignment checks at every entry point to the library. This is not something I know how to work around from the CFFI binding in a reasonable fashion, so for the time being I've given up on adapting to such hostile versions of the library. Fortunately, I've absorbed enough trivia eavesdropping on the SBCL hackers on IRC to know that Darwin uses 16 byte alignment for precisely the same reason, so SBCL must support it, and after a few minutes searching I hacked the align-stack-pointer macro in SBCL's x86 backend to enable the 16 byte alignment on Linux as well, which appears to work around the problem (at the cost of my build environment getting even stranger). I also rebuilt the libmpg123 library with --disable-largefile and, just to be thorough, --disable-aligncheck, and set my CFLAGS to -mstackrealign, two measures which I think should've sufficed to solve the issue even without a hacked SBCL.
The 32-bit Linux/x86 binary now includes a rebuilt version of libmpg123, renamed libmixalot-mpg123, with these changes. The 64-bit binary doesn't have any of these problems, and should Just Work, but you have to provide your own libmpg123 as before. My mistake, of course, was using libmpg123, but I wasn't aware of libmad when I made that choice, and I'm not enthusiastic about rewriting otherwise perfectly working code on account of these issues (although I probably will, sooner or later). My current binaries, in conjunction with Shuffletron 0.0.3 (featuring various minor improvements), should be free of these problems, but still haven't been as widely tested as I'd like. The lesson to me, obvious in retrospect, is to test these things on a more diverse set of configurations than my own machines (particularly when they all run the same release of Debian), even when it seems so simple that nothing could go wrong.
- Music:Gorillaz, "Kids with Guns"
Bordeaux-FFT is a small library for computing the FFT/IFFT on complex data, originally written by Robert Strandh (and/or Sylvain Marchand and Martin Raspaud), with contributions by Paul Khuong and myself. Last summer I did some audio processing experiments, originally using the FFT code from Sapaclisp. Robert helpfully volunteered his FFT implementation, which I cleaned up slightly and have been cheerfully employing in various audio hacks ever since. Several versions have changed hands through email, lisppaste, and my web server, so I've finally come around to collecting the changes, writing a brief manual, and tarring up a release. It's surprisingly fast, particularly with Paul Khuong's recent work on SBCL, although I don't know how it stacks up against some of the highly tuned assembly language implementations out there. I use it along with my fledgling task queuing code to grind out batches of FFTs across four CPU cores.
Shuffletron is a simple music player in CL, with a few interesting features. I've been running this program full time for several weeks now as my preferred music player. It snuck on to the lisp subreddit before I really announced it, and I'm sure folks on IRC are already sick of hearing about it, so I won't say much. I began with plans for a much more ambitious player, with a fancy graphical interface, and wrote the first version of this one Saturday realizing I needed something simple to put the audio code through its paces while I wrote the full player, intending to include this one as an example program with Mixalot. It worked better than expected, so I ended up fleshing out the feature set instead and decided that it was really all I needed. The code is lean and mean.
I've had a number of problems trying to produce redistributable binaries of this which I believe I've finally solved (although new binaries are forthcoming). I hope to write about these later.
Mixalot is the audio back-end of Shuffletron, factored into its own system(s) because it might be useful for other purposes. It includes a mixer which pulls audio from any number of streamer objects and outputs them to ALSA. It also includes FFI definitions for libmpg123 with some helpers for decoding MP3 files and reading ID3 tags, and a streamer class for decoding and playing MP3 files in real time. The libmpg123 portions are usable independently of the audio mixing/output code.
Perhaps eMusic feels that access to the wider catalog of music will offset the increased cost. If they think their existing subscribers will understand, they are gravely mistaken. Given the option, I'd rather Sony Music go out of business, their back catalog be destroyed in a fire, and their CEO choke to death on his breakfast. This article puts it nicely:
Most eMusic fans I've heard from are real music nuts, and are there to sample a wide range of music from relatively unknown cutting-edge acts, not to download music they could find anywhere. Imagine the clerks in High Fidelity suddenly being told that their favorite mail-order distributor is raising prices, but in exchange will now let them order ABBA and Chili Peppers records just like the chain stores in the mall.
In my brief investigations so far, I haven't found another music service that is competitive with eMusic, even (perhaps) at their new price point. I don't consider that an argument for staying with eMusic rather than defecting to another service, though. Given that I consider $0.40/song roughly twice what I'd call a reasonable price, I instead take it as an argument for not buying music online at all. It isn't like there aren't alternatives.
- Music:Au Revoir Simone, "The Lucky One"
I hate it. All I wanted to do was write a simple goddamn music player.
hefner@lightworks:~$ ls -l /tmp/nesfs total 0 -rw-rw-rw- 1 root root 8192 Dec 31 1969 chr-rom -rw-rw-rw- 1 root root 256 Dec 31 1969 oam -rw-rw-rw- 1 root root 32768 Dec 31 1969 prg-rom -rw-rw-rw- 1 root root 2048 Dec 31 1969 ram -r--r--r-- 1 root root 22 Dec 31 1969 rom-filename -r--r--r-- 1 root root 15 Dec 31 1969 rom-hash -rw-rw-rw- 1 root root 8192 Dec 31 1969 sram -rw-rw-rw- 1 root root 16384 Dec 31 1969 vram
I suppose I could fix the other fields in the stat structure. This is the first time I've done an ls -l here to notice. The FUSE examples I started from didn't bother. :)
This will appear in the next version of my NES emulator, although I can't say when that will be. Until I feel like spending an unpleasant hour or several learning to do merging with Git, probably.
"A cashflow approach is much more effective for figuring out where we’re headed. Money flows out to the folks on Wall Street who bankrupted their firms, to schoolteachers who’ve failed to teach their students, to government workers who feel that simply showing up to work is a heroic achievement, to executives and union workers in America’s oldest and least competitive industries. If times are tough and money is tight, that means almost nothing is left over for productive investment. What would have been a short recession will turn into a long depression and decades of higher taxes and slow growth to pay for all of the cash ladled out. Special interest groups will continue to gain in power."
- Music:MC Hawkings, "The Hawkman Cometh"
Apparently people have downgraded systems from testing to stable using APT, but this sounded tricky. Just changing the sources list and doing dist-upgrade doesn't work, and apparently people who have done this have to pin a bunch of packages and somehow fool it into downgrading. Given that most of the info Google turns up on this is seven years old, I didn't want to risk it. Normally I'd just do another install into a spare partition, but having had such a smooth ride with Debian for so long (I ran the same install for something like five years, until finally moving on to 64-bit), this is the first Linux machine in years I didn't bother making such a partition on.
Instead, I installed Debian stable into a subdirectory (/lenny) using debootstrap, chrooted in to install packages, and prepped the /etc directory. Now I was ready to switch systems. I got the statically linked version of busybox and, while still in X11 with music, Firefox, and IRC going, did the following:
lightworks:/# mkdir sqeeze
lightworks:/# mv bin emul/ etc lib lib32 lib64 sbin usr var squeeze/
lightworks:/# cd lenny/
lightworks:/lenny# mv bin emul/ etc lib lib32 lib64 sbin usr var /
lightworks:/lenny#
Now I'm running Debian stable. Everything is working just fire, except I had to restart firefox, and install some xfont packages for emacs. This is one of those rare instance where I'm genuinely pleased with my operating system. There's some loose ends to tie up, like configuring X11 (I'm still running the one from sqeeze; I'll fix it next time I quit X), and some miscellaneous packages to track down, but at this point I think I'll declare this stunt a success.
- Music:Lucasfilm Games, Ballblazer
* Including instructor (at t=0)
I'm fiddling with some C code, experimenting with different approaches to various subtasks, some of which depend on previous tasks. Results are valid only for the duration of the current frame. Performance matters, so I tend to comment pieces I'm not currently working on unless they're needed. For the time being, the data is often only displayed as debugging output, but sometimes the debug display is turned off, making the computation wasteful. Up to this point I'd been juggling the dependencies manually, calling each computation in order from a central point, but finally I've gotten restless to automate things. Here's some cute C preprocessor fun I bashed out a few minutes ago:
struct task {
char *name;
int last_time;
int locked;
void (*taskfn) (void);
};
#define deftask(name) \
void task_do_##name (void); \
struct task name = {#name, -1, 0, task_do_##name}; \
noinline void task_do_##name (void)
static inline void require_task (struct task *task, int time)
{
assert(task != NULL);
if (task->last_time < time) {
if (task->locked) {
fprintf(stderr, "Fatal: Circular dependency on task \"%s\".\n", task->name);
exit(1);
}
task->locked = 1;
task->taskfn();
task->last_time = time;
task->locked = 0;
}
}
I interface this with my code and the global frame_number as follows:
#define using(name) require_task(&name, frame_number)Next I define various tasks. Some depend on others:
deftask(track_motion)
{
.. some code here ..
}
deftask(feature_matrix)
{
.. more code here ..
}
deftask(grid_alignment)
{
using(track_motion);
.. yet more code..
}
Code elsewhere also relies on the 'using' macro to ensure computations are up to date. The components communicate through global state. If they didn't, and the style were more functional, I supposed I'd be blogging about how I'd implemented memoization instead. Eventually, I might rig this up to farm the computation out to other threads (though this doesn't seem like such a huge win unless I go back to eagerly computing things in advance of needing them). I'd need a parallel 'using' operator.
- Music:Frank Zappa, "San Ber'dino"
Plan A: Inject massive amounts of money with the aim of creating a new bubble, letting us coast by with another five or six years of illusory prosperity before it all blows up again in an even bigger and more spectacular fashion, leaving it to the next guy to sort out the mess, just like Alan Greenspan did to Bernanke.
Plan B: Destroy the currency! Massive inflation! Double, even triple the price of every imported good. What better way to get more people working than to force them to get second jobs (or first jobs, if they're wealthy or retired). Let the proles claw their way out of the pit while politicians fight to take credit for "solving the crisis," and Bernanke rests on the seventh day after reaffirming that his powers of economic destruction are not completely impotent.
Barring some miracle of science, like the invention of cheap and bountiful fusion power, I don't forsee a economic recovery for the United States. The collusion of corporate interests and a reckless and parasitic government is finally going to kill the host. At best, I can imagine stagnation in the near term. After that, a long and unpleasant decline, punctuated by occasional collapses in the house of cards constructed by government and financial interests, as the delusiion of perpetual exponential growth steadily erodes and eats alive both the financial system and (with its impossibly large debts) the US government. All the while, dwindling supplies of petroleum and nuclear fuel will push the chances of recovery and growth further and further out of reach, until civilization as we know it cracks under the pressure and dissolves. For extra fun, toss in the wild card of destructive climate change, if you believe in that sort of thing.
This scenario is horrifying, so convince me otherwise. Central bankers and politicians are playing god, and every move they make seems destined to trade the future for their own short term gain. It isn't necessarily maliciousness, just stupidity, desperation, and shortsightedness. Our leaders are going out screaming and flailing -- in quicksand.
It's a bit rough (and that's one of the better portions), but you can see the path of Mario hopping from point to point. I tried this with several games: Super Mario Bros. 1, Super Mario Bros. 3, Duck Tales, and Life Force. In the latter case the game scrolls at a fixed rate, so you get a sort of shabby automap.
- Music:Matti Raekallio, Prokofiev Piano Sonata No. 1
