This was a confluence of three ambitions:
1. How do those old Ultima underworld style first personal maze crawlers, the ones were you can only look north, south, west or east, work?
2. The old Atari, Commodore, TI99/4a, Apple II, Vic-20, etc etc rags had the neatest programs for teaching children and novices. Acceleration, Bresenham line drawing, recursion for things like flood fill and random mazes -- so many mathematical and logical concepts sneak in when you're not looking. I wanted to take stock of the old graphics examples I could find and start to catalog them for use in a tutorial to teach graphics programming in a similar style in Perl.
3. Trying to learn Flash.
So far, I've been picking over http://atariarchives.org/, specifically their archive of ANTIC magazines: http://www.atarimagazines.com/index/?mag=antic. http://www.electronicarchives.org/ is also on my list. And so is http://www.atarimagazines.com/.
It wasn't long before I stumbled over a maze game exactly like what I had in mind as I was working on the Tektronix MUD GUI stuff (see previous post) but was struggling with. My Tek version was having line of sight problems where things would be half way behind something and they'd be drawn entirely or not at all. I was afraid I was going to have to do the ray-casting algorithm (not raytracing but somewhat related... one ray is sent out for each column of pixels to figure out what the nearest object or wall is).
Part of my persona is the librarian. I cringe at the thought of communal memory being lost. Early on, I took up as an early historian, rightly guessing that the best way to understand the systems I was trying to understand was to understand a simplified, earlier version of them. First confronted with programming Unix, for example, I read through the bound and printed manual pages for an old AT&T Unix. Since then, I've seen the portion of humanity made up of programmers apparently forget over and over. My obsession with resurrecting the 90s style of OODA was similarly inspired -- it became clear to me that a lot had been forgotten and attempts to fill in the blanks were coming up short.
The downloads are in AtariBASIC save file format. I downloaded and built the "atari800" emulator and have been loading the save files and then printing to disc the listings and then studying the all upper case, commentless, unstructured spaghetti code. After all of these years, my heart warmed seeing the old BASIC prompt. It's remarkable how much thought people used to put into code that jumped around all over the place. Reading and writing old style BASIC certainly influenced me. Having old Atari BASIC code up in the Unix vi editor feels strange.
atari800, available from http://atari800.sourceforge.net/features.html, is fuckin' brilliant. You can launch it with an argument of a bytecode saved (as the Atari 8 bit computer would save to disc or tape) AtariBASIC program or a standard '.COM" style binary (6502 machine code with memory offset and size header) program and it'll load it and run it. Built into the rewritten and customized "BIOS" is a menu and program loader.
A lot of idioms from AtariBASIC translate directly to Flash. Changing graphics mode for blockier pixels can be accomplished with the
Another thing about commercial software -- and I've written this before -- the documentation is written by professionals more interested in toadying up to the company and painting a picture of roses than actually helping the users. This does great injustice to people trying to learn the technology. _Programming Perl_ is littered with warnings of pitfalls and ways people commonly become confused. Flash documentation seldom has any such thing. The pitfalls are things like "remember to save your work!" as if the product is perfect but the user is not. So, as a side-side-side project, I've been working on my own "Flash on Linux with Free Software tools" tutorial and, true to my butthead nature, documenting the hell out of every pitfall I can find.
This has been a good exercise. Like starting a job at a new company and having to find where everything is, I've had to grapple around inside Flash finding where things are. The next task up is to figure out how to read from the joystick... erm, I mean keyboard and mouse. (Do we *really* call this progress?)
As for seeking the problem to my clipping woes for my Tek MUD GUI, I didn't find the answer in the simple maze crawler but instead found simplifications to work around it. The AtariBASIC maze crawler, rather than having a "cone of view", with peripheral vision jutting out at an angle each way, has a "column of view". Looking down a corridor, you can only see three tiles wide for n (in this case, 8) tiles deep. Since each layer of depth outwards from the viewer is drawn smaller and zoomed into the center of the screen, there's an illusion of a cone of view complete with a vanishing point and further away things being smaller. And this relates to the other limitation -- it cannot render open spaces, only hallways one tile wide. To hide the fact that only three tiles for any depth outward are considered, everything else needs to be hidden behind walls.
This was a fun exercise. I'll better be able to relate to raycasting and other algorithms understanding the simplest form possible of the maze crawler. And I now understand why I'm having the problems I'm having -- my cone of view starts with one tile, then at the next depth goes to three, then five, and so on.
http://slowass.net/~scott/tmp/maze.as has the ActionScript 2 and the AtariBASIC preserved as a comment. It builds with mtasc. The output looks something like http://slowass.net/~scott/tmp/mazeswf.png -- that is, after it finishes drawing the maze in fat pixels and switches to first person view.
Some of the other ANTIC articles have been using custom words in FORT to do Logo style turtle graphics -- fun!