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 ._xscale and ._yscale MovieClip attributes. However, Flash is inconsistent about whether it consults the scale for things like hitTest which made for hard to track down bugs. hitTest() uses the scale if you're using on the main window and not otherwise. A lot code written in AtariBASIC spends a lot of time doing PLOT X,Y and DRAWTO X,Y which is easily accomplished in Flash using .moveTo(x, y) and .lineTo(x, y). LOCATE is used in AtariBASIC to see what color had been previously plotted at an x, y location and Flash's .hitText is similar but requires an extra argument to be useful. Without the third true argument, it only tells you if there's a MovieClip object whose bounds includes that location, not if there was actually ever anything plotted there. This sort of premature optimization permeates Flash. Drawing lines in Flash, Flash insists on mitering the ends, dithering the line, capping the ends, etc, and this doesn't play nicely with scale. If you draw tiny lines hoping they get scaled up, they will, but then you'll wind up with no blocky pixels but instead high resolution lines with all sorts of fancy stuff done on them. Besides not faithfully recreating blocky 8 bit style graphics, this plays havok with .hitText(). Even though you clearly did or did not plot through a location, you cannot safely test this fact as the test might hit a dither or a miter or some other line decoration. And these decorations cannot be entirely turned off. All of Flash suffers from this sort of premature graphical flourish at the expensive of CPU. Yes -- both that and premature optimization at the same time. This is exactly the kind of schizophrenia commercial software always seems to suffer from. Drawing each line as a single segment with square line ends solved most of those problems except dithering. Even scaling up exactly a power of two, somehow in Flash's floating point rounding, it still managers to draw lines half way between pixels.
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/user/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/user/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!
-scott
old Ultima underworld style first personal maze crawlers, the ones were you can only look north, south, west or east
That's Dungeon Master. Ultima Underworld has free-look and irregular shaped rooms with slopes.
Re:wrong game
scrottie on 2009-08-31T16:45:59
Before "Ultima Underworld", Ultima III and IV (and perhaps others) referred to their dungeons as "the underworld" and used the algorithm I described or something indistinguishable from it. This is to what I refer.
