Page 1 of 18

ZZT Ultra

Posted: Wed Nov 26, 2014 3:57 am
by Appetite4
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

Re: ZZT Ultra

Posted: Wed Nov 26, 2014 6:04 am
by Smilymzx
Appetite4 wrote: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).
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)

Next Gen File Formats

Posted: Mon Dec 01, 2014 11:50 pm
by Appetite4
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.

ZZT Ultra prototype ready

Posted: Sat Dec 06, 2014 10:53 pm
by Appetite4
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.

Re: ZZT Ultra

Posted: Sun Dec 07, 2014 3:56 am
by Commodore
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 :keen:

ZZT behavior, JSON-style

Posted: Wed Dec 17, 2014 12:53 am
by Appetite4
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.

Re: ZZT Ultra

Posted: Wed Dec 17, 2014 3:42 pm
by Commodore
zzt_objs wrote:Ordering info? FYI, the shelf life of ZZT is over.
:D

ZZT Ultra, improving speed and performance

Posted: Mon Dec 29, 2014 5:13 pm
by Appetite4
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.

Those @#?!&% timing issues

Posted: Sat Jan 03, 2015 6:23 pm
by Appetite4
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.

Re: ZZT Ultra

Posted: Sun Jan 04, 2015 3:56 pm
by Commodore
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.

ZZT Ultra saving

Posted: Wed Jan 14, 2015 4:43 am
by Appetite4
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).

Re: ZZT Ultra

Posted: Wed Jan 14, 2015 3:15 pm
by bitbot
TOO LONg; DIDn't REAd

Re: ZZT Ultra

Posted: Thu Jan 15, 2015 2:30 am
by Commodore
Would be cool to have a history file, all the moves, so you could rewind.

Re: ZZT Ultra

Posted: Thu Jan 15, 2015 6:50 pm
by bitbot
@commodore

theres a time and place to be politically correct

this isnt one of them

im bitbot and i approve this message

Everything is awesome?

Posted: Fri Jan 16, 2015 3:01 am
by Appetite4
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."