z2

The (very limited and very buggy) first release of ZZT Ultra will not be ready for a few weeks. But here is something I've been able to do experimentally with the sound playback system.

The #PLAY statements seem to work well with existing ZZT and Super ZZT worlds. I decided to enhance the syntax to let the statements play multiple simultaneous voices, among other things, a la the Tandy 3-tone.

Here's a test track I made by combining four voices. Granted, the screenshot only shows two, but these are the two voices that really count (the bass and percussion being rather unremarkable).

http://www.chriskallen.com/mp3/zzt_sound_test.html

I was gonna suggest a more SoundBlaster-esqe approach as well (MOD/S3M/IT/XM Files for Modules, WAV/OGG for CD-Quality Music and Sampled Sound) Similar to MegaZeux, Tandy works as well if no sounds are in the game!

Also, I'd suggest to make PC speaker modes, MegaZeux or ZZT styled (Some sounds are used better in MZX's system due to the better interrupt cycles, better effects)

I've experimented with a lot of file formats (even tried to make a small business out of it at one time, which flopped). Giving some thoughts to what a next-generation format would look like for ZZT.

Probably the best way to go forward is to maintain interop. ZZT, admittedly, is pretty terrible at this. ZZT is not compatible with Super ZZT or any other editor made by Epic since. So what should we use instead?

I vote for WAD. That's one of the most-patched file formats of all time, and it's extremely simple to use. Upper memory limits aren't a problem, and modularity is built into the format itself.

As for things like world properties, board properties, and status element records, I suggest using something like JSON, which lets us move beyond the fixed-size limitations into more modern dictionary-style access. It would let us create data structures that are easy to extend.

Code can stay as it is--it was text before, and it should remain text.

Board data RLE compression? Keep compressing it. Doesn't have to be strictly RLE, but whatever.

No matter how you slice it, WAD can store pretty much anything.

Even though the site is far from being up and running, I can still post a development copy of ZZT Ultra. Play it here:

http://www.chriskallen.com/zzt/ZZTUltra.html

Click the window, then type 'Z' to load a ZZT file, or 'S' to load a Super ZZT file. Most of the debug menu options don't work right now, so please don't rip me a new one this early.

Next on the agenda is to get saving to work; right now there isn't any. I also realize many of the prefab enemy behaviors are WAY off.

The sound has latency that I would like to remove if possible. I used the Flash dynamic sound generation callback system, which lets you do quite a lot with audio, but at the price of being a processor hog.

Anyway, this is a sign of things to come.

Very cool! Slow as shit on my netbook, but again, everything is, maybe that's the audio problem... Takes about 5 seconds for the random fill to change the screen. Got to get myself to a proper computer to really check it out.

No need for the ripping of new ones

_________________
*POW* *CLANK* *PING*

ZZT Ultra favors behavior that is defined by content whenever possible, as opposed to hard-coding. Most of the business logic of the game engine is designed to fit into one of these two files: zzt_guis.txt and zzt_obs.txt. The demo Flash file makes use of the two prototype files located at the following links.

GUI definitions: http://www.chriskallen.com/zzt/guis/zzt_guis.txt

Type definitions: http://www.chriskallen.com/zzt/guis/zzt_objs.txt

It's standard JSON format, which makes it easy to edit and test. ZZT Ultra performs compilation in order to optimize the code, so it shouldn't run slowly once a world file is run. Of course, there are several areas that need to be tweaked. The types, in particular, are definitely incomplete.

:D

_________________
*POW* *CLANK* *PING*

Over the holidays, I discovered that ZZT Ultra was running into serious performance-related issues with some of the ZZT-OOP code processing and drawing.

I've been making a lot of improvements. Conveyors were iterating REALLY slowly because label navigation performed a text search every time (for pre-fab objects, it's okay to store the exact integer offset into compiled bytecode instead). Also implemented a variety of "C-style" switch statements, which should improve things when checking against 20+ types when making a decision (bullet collision, blink wall stopping, etc).

But the biggest performance lag was being caused by custom drawing routines. It's not so bad for transporters or spinning guns, but line drawing and web drawing are horrendous. ZZT worlds don't lag much because full-screen update occurs rarely. Super ZZT worlds, on the other hand, update constantly with scrolling. I may need to economize the full-screen update when the player scrolls the screen, such that the viewport is not 100% redrawn. Simple scrolling only requires a few "movement-style" blits and only a small sliver of actual update in the void created by the movement.

Well, I'm pretty sure that Super ZZT economized on scrolling. It's amazing what REP MOVSW can do.

Trying to fix the numerous timing issues with ZZT Ultra.

Until very recently, I hadn't peeked at the Roton source on github. Looking at the ZZT-OOP's command-processing outer loop, I'm still struggling to understand all the decisions made in the original ZZT program.

The "magic number" I was looking for appears to be 32. This "magic number" represents the maximum number of #COMMAND instances that can be read during one iteration of an OBJECT or SCROLL before the turn ends. I needed this number because there must be an arbitrary "break" on certain looping-like actions that aren't stopped by /i or movement.

There is another reason this number is important: text display. The "inventory-based" text display wasn't working in ZZT Ultra because I had stopped the code processing cold when a non-text line was encountered (read: #IF). This might be safe, but, sadly, it is also wrong. Text processing needs to continue even after the last text line is encountered, up to and including various non-text lines.

The SCROLL type was breaking in many games as a result of stopping the processing cold. For an example, the scroll "It's not over yet!" in the cave just before you win Town of ZZT was not playing the Twilight Zone music.

Timing. The bane of all conversions and emulations.

I never thought of that magic number being important to inventory, but it makes sense, and I suppose would would limit the number of items capable of being polled. Glad you found Roton, from what I gather it's pretty accurate, being based on the disassembly.

_________________
*POW* *CLANK* *PING*

I believe there should be more than one type of "save" going forward. The well-accepted way to do saving in modern gaming is automatically tracked progress (autosaves). This could be a boon to all those times when somebody is never sure when a certain part of a ZZT adventure will capriciously insta-kill the player. The user could still trigger an autosave on demand if needed.

The idea behind autosaves done in this fashion is that you'd get a scroll when you tried to restore, with snapshots of the save points that you could select from (room, time, possibly screenshot, etc).

The other type of save would be the classic ZZT "file" save, which is just a stored copy of the world file with a different extension. Thus you could get a semi-permanent record of your savegame on your own local disk drive despite the fact that the game is browser-based.

Note that Flash also lets you track incremental progress using shared objects, whose accounting is nearly invisible to the user. While this could also work in terms of autosaves in a semi-permanent fashion (for example, when you close the browser and start it up again), that could add up to a lot of space (equivalent of one world file size, PER save instance, PER adventure played).

TOO LONg; DIDn't REAd

_________________

Would be cool to have a history file, all the moves, so you could rewind.

_________________
*POW* *CLANK* *PING*

@commodore

theres a time and place to be politically correct

this isnt one of them

im bitbot and i approve this message

_________________

bitbot, that Lego Movie screenshot gives me an idea! A special ZZT adventure where the world is coming apart and you have to stop it.

The title would be "Fall of ZZT: The Curse of Production Quality."