Monday, August 12, 2013
Programming by voice
This is more manipulation of emacs by voice, but still: here. Writing Python by voice with emacs...
Sunday, August 11, 2013
Gameboy emulation
For Pokemon play, one uses an emulator on the PC or other computer (or, you know, you buy an actual Gameboy, but I'm assuming you're more interesting than that). Mostly that's VBA or VBA-M, although there are others. On Win64, VBA-M is not working for me with Pokemon Emerald, so I'm using a 32-bit VBA, but the source tree for VBA-M is on SourceForge here.
Clearly, part of this is the emulator itself and part is the UI and associated tools, so we've got to tease those threads apart. But I'm most interested in how the ROM itself works (i.e. its file structure and how all that stuff is defined). It appears to be programmed on this virtual machine in a bytecode; how does that work, and how can we pull it apart to build a new ROM or modified one? I'm pretty sure the emulator code itself is going to tell us that, but the documentation is horrible, all read-the-code-Luke with a few cryptic comments for things the authors found tricky or unexpected, I'm assuming bug fixes mostly.
Anyway, the reason Pokemon is suddenly featuring on this heretofore more general blog is that my son has a truly fascinating idea for a programming project involving emulated Pokemon. More here later if it proves feasible to do what he wants to do. But in the meantime we gotta understand and clean up this codebase, so it's code understanding to the forefront!
Clearly, part of this is the emulator itself and part is the UI and associated tools, so we've got to tease those threads apart. But I'm most interested in how the ROM itself works (i.e. its file structure and how all that stuff is defined). It appears to be programmed on this virtual machine in a bytecode; how does that work, and how can we pull it apart to build a new ROM or modified one? I'm pretty sure the emulator code itself is going to tell us that, but the documentation is horrible, all read-the-code-Luke with a few cryptic comments for things the authors found tricky or unexpected, I'm assuming bug fixes mostly.
Anyway, the reason Pokemon is suddenly featuring on this heretofore more general blog is that my son has a truly fascinating idea for a programming project involving emulated Pokemon. More here later if it proves feasible to do what he wants to do. But in the meantime we gotta understand and clean up this codebase, so it's code understanding to the forefront!
Labels:
C++,
code understanding,
data structures,
Pokemon
Monday, August 5, 2013
The Machine Zone
Bad user-experience patterns: the Machine Zone. This is the late-night high-channel surf, the one-more-pic-on-Facebook that you zone into for hours instead of sleeping. Great for impressions, and if your metric is stickiness, you might think you're giving your users what they want.
Are you?
Filed under UI design with a little trepidation, because "user experience" is really more something for the purpose of an app, not its implementation.
Are you?
Filed under UI design with a little trepidation, because "user experience" is really more something for the purpose of an app, not its implementation.
Express regexes with verbal expressions
Neat JS library for expression of simple regex use cases in non-incomprehensible form. This is an interesting start, but I don't see any way to extend it to more complicated use cases (identified match outputs, replacements, alternates with any nested structure, and so on).
Although for a lot of things, honestly, regexes should be replaced by explicit grammars with named components and a match specification.
Anyway, this is a nice start and deserves contemplation.
Although for a lot of things, honestly, regexes should be replaced by explicit grammars with named components and a match specification.
Anyway, this is a nice start and deserves contemplation.
Yegge on Perl
Steve Yegge always makes you think, even when he's doing something so preposterous as challenging the One True Language.
not that he's wrong
What?!?
Yeah, I have to admit he's right. Perl is a convenient place to start with a lot of problems because as glue for CPAN it really gets you close to a quick solution for nearly anything on Earth. But ultimately I think we're going to find that any one programming language is simply not going to be sufficient for every need. That, after all, is the entire point of this very blog. So even though I have a kneejerk negative reaction to any criticism of Perl, my language of choice these past ten years or so, he's still right. Perl is an antique.
I just happen to like antiques.
And honestly, seeing the Perl expression of any idea as merely the cave-wall projection of the actual program, I have to say that starting out in Perl isn't such a bad way to start approaching a problem. It's just that I find myself drifting off the rails to language design fairly quickly in the course of any given larger project.
Subscribe to:
Posts (Atom)