What is this madness

[Commodore]

I left it on overnight and it filled the top four rows of the graphing area

[Kjorteo]

I let it run for like half a day now at top speed and it appears to be partially through drawing something.



I'm out of my league to the point where I don't even know what a Mandelbrot set is, though, so I have no way of judging whether this is an accurate depiction of one so far.

[Commodore]

do you have a different version than the uploaded one? the little room the player is in looks different in mine.

[Kjorteo]

It's possible. I was sort of a play-tester/guy off which he was bouncing ideas during development, so I have a bunch of builds. I thought I was using the final version he put on Z2, but it's possible I just clicked the wrong one or something.

[InfoSponge]

mandelbrot set
fuckin famous fractal

[premchai21]

Hello! I see you!

If you intend to run MAND to completion, you'll really need a fast configuration or else an awful lot of patience. ZZT is not designed for doing large amounts of fixed-point complex arithmetic with 14-bit internal precision. I do not recommend the use of DOSBox or other software CPU emulators for that; use either bare hardware, or a virtual machine with hardware hypervision, such as KVM. KVM running a DOS image with ZZT 3.2 on a Debian GNU/Linux (kernel 2.6.29-1-amd64) Athlon 64 X2 4200+ box finishes an iteration of the Mandelbrot function in about four seconds, making it take on the order of days to complete the image.

The version whence Kjorteo's screenshot comes appears to be the last release candidate before 2final. The core drawing code is all exactly the same, as far as I can recall; the cosmetic alteration of the player box was the major difference. There is a known probable bug that leaves the player trapped once the machine halts, which is reasonably easily fixed (the X minion needs to trigger ONGATE to open again after it does the #clear ON) but which is minor enough in context that it didn't seem to warrant a point release.

The image is not of the full set, because that would probably not be very interesting at 44x15 resolution. It is a zoomed-in partial image, which is fairly standard for visualizations of fractals in the complex plane. It is perhaps unfortunate in the selection of the bounding box that the first ten pixels drawn are black, but with the limited precision available, the set of possible interesting zooms is fairly coarse-grained and I decided that this was good enough.

The implementation of the 16-color palette of boulder pixel duplicators was particularly amusing. :-) And yes, the garbage on the top of the screen is in fact an instruction sequence for a load-store single-accumulator machine with six numeric registers, hardware (hah!) multiplication, specialized iteration count register, and color-coded jump targets.

Several of the other machines are much nicer from an interactive or immediate-results point of view, but MAND does take the cake in sheer ludicrous amount of computation performed by shunting bit-twiddling minions around on a ZZT board.

[Kjorteo]

...Wait, hold on. Premchai21 = Drake? Oh God, my world.

Er, anyway. More to the point...I probably could figure this out by looking at the code, but I'm on the wrong computer for that right now, and your code is kind of terrifying anyway, so I'll just ask...how did you manage to create boulders during runtime in the darker colors?

[premchai21]

...Wait, hold on. Premchai21 = Drake? Oh God, my world. :agh:

Heeheeheeheehee! (The "21", FWIW, is mostly meaningless and is often present in my moniker on Web sites of this type for hysterical raisins.)

Er, anyway. More to the point...I probably could figure this out by looking at the code, but I'm on the wrong computer for that right now, and your code is kind of terrifying anyway, so I'll just ask...how did you manage to create boulders during runtime in the darker colors?

Duplicators.

There, wasn't that simple?

More specifically, there's an array of sixteen duplicators blocked by invisible walls. The paintbrush minion receives a bullet pulse from the trigger gun to the west, moves east the correct number of spaces to the palette column, unblocks the duplicator, moves to one side, and waits for two boulders to be produced; the second one will push the first one into position for being manipulated. The paintbrush then pushes the new boulder over to the east and overwrites the extra boulder with a new invisible wall.

Then the Y minion detects the boulder available for pushing to the north, and pushes it north as far as it'll go; conveniently, this places the boulder in the correct position for the X minion, which pushes it west as far as it'll go, so you get west-to-east north-to-south scan order. When the X minion detects that it can't push anymore, it moves south one row, and when it can't start another row, the picture is complete and it broadcasts a HALT message and shuts down the rest of the action.

[Kjorteo]

My God, you went from never having heard of this whole ZZT thing until I mentioned it to things like...like that, with which I can't even keep up, in the span of a couple weeks. At this rate, I give it two months before you make a version of Preposterous Machines that goes self-aware, Skynet ZZT goes online, and we're all doomed.

[Commodore]

if you do release another version it should be to comment the code and to more clearly state how long the mandelbrot set will take to work. but maybe there are comments. I don't know, I was too terrified to look.

The tetris thing is really good too.

[premchai21]

if you do release another version it should be to comment the code

There are few to no comments for a couple of reasons. One of them is that several of the boards are already 15–18 kB, and adding real comments could push them dangerously close to or over the size limit—even adding longer label names could be risky, since jumps are such a large part of this dialect of Object-Disoriented Parallel INTERCAL.

Some of the boards I've already had to jigger in ill-defined ways to prevent ZZT from corrupting memory. E.g., this is why TETR isn't properly restartable, and why there's no "Quit requested" message for it. If you hexdump a savefile from after a single run, you might find that the "Game over." text has actually overwritten some of the code, leading to a dynamic #bind failing later on because the object name has become garbage. The reasons for this are not immediately clear to me, as the references on the Web seem to say "the limit is about 20 kB and 150 objects" and not much else, and according to the KevEdit display I shouldn't be triggering that. TOUR had similar problems until I removed the ending message; possibly the same could be done for TETR.

If I were to add in-world implementation notes, which would be nice, I would do it in the style of old-school Forth, using shadow boards: probably a single ghostly (white-on-grey) portal that leads to (and from) a board of isomorphic layout but with all colors degraded to grey and no walls. Each code object would be replaced with a corresponding text object, plus possibly other objects describing parts like "graphics output area" or "game field".

(In many Forth systems, one edits code in fixed-size "blocks", each a single screenful; boards have a similar feel, though they can contain much more information. In those systems, inline comments are rare, and one often uses even-numbered blocks for code and reserves odd-numbered blocks, "shadow blocks", for unexecuted text corresponding to their partners.)

and to more clearly state how long the mandelbrot set will take to work.

That is an interesting point, as evidenced by above postings. I don't have a good feel for how fast most people run ZZT in These Modern Times. I assumed the emphasis and exclamation point would be sufficient if imprecise warning, but perhaps not. :-)

but maybe there are comments. I don't know, I was too terrified to look.

*griiiiins*

The tetris thing is really good too.

I'm glad someone's actually trying it. The controls aren't all that responsive. Some improvements could probably be made by turning the board sideways and using 2x1 horizontal blocks for game field cells rather than mapping them 1-to-1 to ZZT board cells. 2x2 could be even better, but it would look ugly and you'd start running out of space.

I was mildly surprised to see that I couldn't find any extant ZZT tetromino game on the Web. I assumed someone must have done it already, but either this isn't the case or they're hiding.

[zamros]

There's ZZTris up in the archive, made about 10 years ago at this point, probably. It was heralded as one of the Great Steps Forward in ZZT programming at the time...

[premchai21]

There's ZZTris up in the archive, made about 10 years ago at this point, probably.

Aha! So there is. It doesn't seem to turn up when searching the Web using either Google or Ixquick for « zzt tetris » or « zzt tetromino ».

A cursory examination from playing it yields a moderately interesting comparison:

• ZZTris is probably using only one minion to handle each piece. This makes motion and rotation operations significantly easier, but unless other trickery is done it restricts the set of usable piece types to {1, 2, L-3, I-3, T-4}, which to me is a fatal inelegance: the use of all seven tetrominos, and only tetrominos, is fairly important, and while other sets are viable they must still be chosen carefully. The graphic display seems slightly worse off for it also, since the piece movement doesn't benefit from the ZZT core movement display but instead must be rendered by putting walls and fakes.
  
  TETR uses four minions per piece; they collaborate via reserved broadcast messages to perform motion and rotation. The reason sideways collision testing doesn't work is because I hadn't added proper PLTST and PRTST, instead relying only on LBND and RBND objects (which have the beneficial side effect of acting as a horizontal position preview). This is a known bug. The synchronization also makes things less responsive: there is more processing to do per cycle, movement can take more cycles, and the application of controls is more required to be synchronized to the main control clock.
• ZZTris uses a duplicator to generate new pieces. This is what I originally tried also, but it proved to make things too unstable to use. ZZTris appears to break after some dozens of pieces; the effect may be mitigated by the fewer number of minions per piece. TETR appears to be stable for a full game of indefinite length (as far as I've tried it), but then suffers damage once the "Game over." message is displayed, as I mentioned above.
  
  TETR uses a state cycle of dynamic #binding, where there's one prototype object for each position in a piece, then one for "amorphous inactive" (PHROM) and one for "amorphous active" (MORPH); when piece minions deactivate, they drain to the bottom of the field and are reassembled into a form suitable for morphing into a new piece. There are two sets of minions, so it's basically double-buffered. This again adds latency, though, as new piece generation must wait for the original piece to drain.
• ZZTris uses a very similar "bullet made it all the way through" mechanism for testing lines for completion. I suspect that's the only reasonable fast way to do it. Similarly for the use of changing walls to sliders or boulders and then using controllable pushers on the upper edge of the field.
• TETR has reasonable sound effects and slightly better graphics, the latter possibly attributable to the change of surrounding era. It also doesn't crash ZZT on exit, or at least I haven't seen it do that yet (though earlier versions did).
• ZZTris has no "fast drop" or "force quit". The latter is entirely unnecessary for it since it's not placed in any larger world context. The former is present in TETR, but isn't as useful as it ought to be, since "fast" isn't actually very fast.
• The field size is different: 12x14 rather than 10x20.

A quick glance in the editor reveals somewhat more:

• ZZTris's block selection seems to use nonuniform probabilities, which is probably either arbitrary or due to the different selection of polyominos. The breakage after several pieces may actually be due to the piece type selection falling through to a null case after each of the actual piece type cases, with probability 1/32.
• ZZTris appears to use flags for communication of movement requests and labels for rotation states. TETR uses flags for rotation states and labels for communication of movement requests (huh).
  
  This is probably how ZZTris manages to have a larger board size in octets (19684 octets as opposed to 18544 octets, according to KevEdit). It also uses 50 stat records as opposed to the 90 of TETR.
• The ZZTris world file appears to include a color kit… why they didn't make slightly better use of it for background colors and the like I'm not sure, though one of the reviews claims that this was due to memory constraints. That extra kilobyte really makes a difference, I suppose—but it already crashes ZZT on exit. Hmm.
• I gather ZZTris's game start is hooked up to the board start, since the only way out of the passage just leads into the game control area and that's that.
• ZZTris grants 100N points for an N-line clear. TETR grants 10(2^(N−1)) points for an N-line clear.

[RobertP]

The boards seem to have the dumbest and the smartest thread in years going on at the same time.

Premchai21, do you take take interest in game design or do you just work your wizardry on coding awe-inspiring machines?

[premchai21]

Premchai21, do you take take interest in game design or do you just work your wizardry on coding awe-inspiring machines?

Depends on what you mean. *nod* I can take interest in a great many possible things, but which of them appears at a given time seems to be nearly random of late.

As for ZZT per se, I initially picked it up under compulsion to make Goldbergian things with it, these ones being the (first visible) result. It's a somewhat interesting if perverse medium. I lean towards the textual as far as interactive fiction goes, as you might have noticed, and that plus dynamic CP437 4+3-bit-color character-cell display makes an odd combination. If I were to make games with it, they'd probably be rather IF-influenced and story-like, perhaps with significant use of simple atmospheric character-cell graphics and background sounds.