Page 16 of 18

Re: ZZT Ultra

Posted: Thu Oct 19, 2017 5:33 pm
by Dr. Dos
Keep us updated!

All of a sudden

Posted: Sun Oct 22, 2017 5:27 pm
by Appetite4
Starting to get a lot happier about the HTML 5 progress being made. Most ZZT and Super ZZT games now load correctly, title screen and gameplay seem to work marginally well, scrolling and dissolve transitions work well (albeit rather slow), GUIs and scroll interfaces seem to work well (once again, a bit on the slow side).

What doesn't work so well: GUI and world editors (not tested yet), sound (not working at all yet), and some worlds do not load (no idea why at this time).

Most peculiar of all is the player movement--the controls seem strangely "floaty" as if arrow keys are being double-registered half the time. I had griped about inconsistent character and scan codes across browsers in the past; this is likely that problem coming home to roost now.

Something I've noticed with Chrome, too: Chrome hates it when you try to pre-load local image files in the browser. When I make the HTML 5 downloadable copy available, I'll include instructions to modify the Chrome shortcut to have "--allow-file-access-from-files" on the command line. Yes, I know, it's more secure to prevent local file access, but we kind of need those image files for sprites!

Full playthrough progress

Posted: Sat Oct 28, 2017 3:25 pm
by Appetite4
Looks like the HTML 5 version of ZZT Ultra can fully play many adventures now, including some games that are technically impressive. CATCAT.ZZT plays perfectly.

Everything is still very silent, though...I'm not looking forward to having to re-design my entire sound system.

Performance metrics have given me some interesting data. At least on my computer on Firefox, I can update around 500 tiles at once without dropping frames. But when you need to update many more than this (e.g. scrolling screens, scroll interface open/close, palette color changes), the update rate drops to only about 4 FPS. I had always been concerned that HTML 5 would be worse on the performance front; I'll need to use some creativity to support the higher-load games.

Re: ZZT Ultra

Posted: Mon Oct 30, 2017 5:05 pm
by Saxxon
Great progress!

Re: ZZT Ultra

Posted: Mon Oct 30, 2017 9:35 pm
by Commodore
What audio format are you using? Just throwing it out there without any knowledge of its viability, but maybe a single file with all the possible sounds in it and timestamp indexed. Since the sounds (excluding the drums) are all uniform waveforms, the samples could be quite small and set to repeat depending on length of the required note, making the file small too, but I don't know if the response time would be quick enough to not have gaps.

Maybe you could even have attack and decay that way:

Code: Select all

   ______
  /      \
 /        \
/          \


|    | play once
   |    | repeat n times
      |    | play last time

Getting much closer now

Posted: Fri Nov 10, 2017 4:03 am
by Appetite4
Since most ZZT and SZT files play in the HTML 5 version of Ultra, I decided to work on WAD files. DEMO.WAD now plays completely, including the sample boss. This means nearly all of the advanced ZZT-OOP commands function properly, not to mention most of the WAD loading code.

Palette changes are painfully slow, though--you have to assume the worst-case scenario when you change palette color registers. This is because you must update the whole screen should the color be registered everywhere. Previously-mentioned performance problems take a real beating here.

Character set updates also need work. Shouldn't be too hard.

Does Smash ZZT play yet? Heh heh heh...no. I made an ugly discovery that will require some juggling of data formats: nearly all JSON parsers assume you are reading and writing UTF-8 format. But as any ZZTer knows, the DOS text we are all used to employs CP-437, which adopts a one-character, one-byte model. Not so good with codes >= 128 when UTF-8 is expected. But JSON parsers can't be arsed to mark up these codes with the \unnnn syntax--oh no! They just choose arbitrarily whether to mark up the code or not mark up the code based on how they feel that day.

The JSON parsing issue is one of the many frustrations I've faced so far. This leads me to my next logical course of action: proposing an international treatise banning Unicode (not really).

Re: ZZT Ultra

Posted: Fri Nov 10, 2017 8:34 pm
by Dr. Dos
I had to do the same with the Museum's file viewer for displaying special characters in object code.

https://museumofzzt.com/static/js/file_viewer.js has a CP437_TO_UNICODE dictionary that links the two character sets up. I also remember an issue with one of the musical notes also being the carriage return character and having to also replace those with <br> since I'm displaying HTML, so there's that one exception in the dictionary.

Hiccups in the space-time continuum

Posted: Fri Nov 17, 2017 1:08 am
by Appetite4
This has been a wild ride...my progress has been derailed for a bit while I swapped out my hard drive. The previous one was starting to give out, so I had to port stuff over to the new one.

Unfortunately, creating a system image wasn't possible because the old drive was saying screw you. So that meant a complete re-install of Windows.

...ON A SYSTEM WITHOUT A PLUG-AND-PLAY NETWORK ADAPTER. So, no downloading updates until I manually copied over the driver files.

By this time I was feeling good and frustrated. But then the havoc truly started.

Copying over the ZZT Ultra project files seemed to be a straightforward operation, but a few days worth of updates had been lost. How, I don't know, since I can vouch for the exact dates I made the copies from the old hard disk, but there is fortunately very little to re-do.

I then got the shock of my life. Previously-mentioned slow scrolling and palette speeds suddenly went lightning-fast! I hadn't even tried to fix the problem, and it fixed itself.

Until I updated Firefox. Then the performance problems came back. NO!!

Being completely honest, this really isn't that much to get upset about. It's a first-world problem. But frustration, it appears, never goes away, no matter how convenient the rest of your life might be.

Smash ZZT works in HTML 5 version!

Posted: Mon Dec 04, 2017 2:54 am
by Appetite4
Great progress--I've been able to get Smash ZZT to play comfortably within the HTML 5 version of ZZT Ultra! The character set mods and palette color changes all had to function, plus a whole mess of other features as well, for the game to run.

It is still slow, but I'm going to focus on performance improvements next. The only two major hurdles remaining are the editor (nearly 7,000 lines to debug!) and the sound system (not a trivial re-architecture operation).

I'm currently exploring the use of window.requestAnimationFrame as a way to throttle the update rate if overall performance would otherwise suffer. The engine is not doing this now; this has the consequence of making each frame run just a bit slower than it would in AS3.

Performance solved!

Posted: Sat Dec 09, 2017 4:10 pm
by Appetite4
Yes!! I got the performance problem licked. Now the update rate is nearly as fast as AS3, including during scroll and dissolve transitions. Palette fades are still slow, and that's due to an unavoidable quirk I found with putImageData.

Basically, in JavaScript, rendering a canvas to a context is fast (drawImage, etc.) but rendering an ImageData to a context is very slow (putImageData, etc). I think putImageData is inefficient and likely not hardware-accelerated.

Smash ZZT plays pretty well, now!

Getting close, now

Posted: Sat Dec 16, 2017 6:28 pm
by Appetite4
Hi All,

I've been diving through the editor code for the HTML 5 version of ZZT Ultra. Wow, is there a lot to fix. This conversion project has involved tens of thousands of lines of code, and the editor component alone contains nearly 7,000 lines.

Various browsers also like to annoy me by mandating hot keys even if the default is prevented in the event handler. For example, Firefox doesn't let you override Ctrl+T. Frustrating, but still workable.

With solid performance, nearly all functionality complete, and virtually no difference in look and feel from the Flash version, the HTML 5 version can expect to have a public beta on my website sometime next week.

Sound is still elusive...I'm saving that juggernaut until last, for good reasons.

Happy Holidays! HTML 5 version of ZZT Ultra is in beta!

Posted: Thu Dec 21, 2017 4:43 pm
by Appetite4
Hi All,

I'm pleased to announce the 1.3 beta release of the HTML 5 version of ZZT Ultra. It's silent (no sound yet), but it looks and plays almost identically to the Flash version. Enjoy!

HTML 5 beta: http://www.chriskallen.com/zzt/ZZTUltra_html5.html
HTML 5 beta with City of ZZT: http://www.chriskallen.com/zzt/ZZTUltra ... t/City.zzt
HTML 5 beta with Monster Zoo: http://www.chriskallen.com/zzt/ZZTUltra ... ONSTER.SZT
HTML 5 beta with Smash ZZT: http://www.chriskallen.com/zzt/ZZTUltra ... ASHZZT.WAD

Some notes on this beta release...
  • Timing should be nearly the same as the Flash version. Firefox on occasion plays slower, but this isn't due to performance. Sometimes the browser just slows down because it can.
  • Chrome plays very fast, and delivers the best experience. This shouldn't be a surprise.
  • Did not test on IE. Doubt I ever will.
  • No support for ZIP files yet; this wasn't a critical feature anyway. If I'm going to support ZIP, I'll need a third-party DEFLATE decoder. It seems crazy that no native JS support exists for ZLIB!
  • Some keyboard shortcuts don't work as expected; browsers will usually reserve their own rules for what can't be overridden. The page source of the ZZTUltra_html.html file has notes about what I've found works or doesn't work (see the kdFunc function)
  • Source code assumes the latest ECMA script compatible with modern browsers. This means classes are actually defined using class. The classic "everything is a function" JS trope can kindly go die in a dumpster fire. >:-)
  • Editor text boxes use actual TEXTAREA tags with special style sheets; this isn't the most ideal solution as it is implemented now. I'll probably need to improve this feature later.
  • File saving in the editors varies significantly across browsers. It's basically treated as a downloaded file, with varying ability for the user to pick the filename. I really wish I had more options here, but this solution will have to do for now.
  • Important: This being a beta, editor-created content has lower fidelity than the Flash version! Don't overwrite your favorite WIP content with this thing.
Chris out.

Re: ZZT Ultra

Posted: Sat Dec 23, 2017 5:37 am
by Dr. Dos
This is very very awesome.

Re: ZZT Ultra

Posted: Sat Dec 23, 2017 8:59 pm
by Commodore
Yes! It's a ZZT Chris-mas! Runs nice and smooth on OSX both Safari and Firefox. 8gb RAM, 2.7ghz intel i5

A couple things I just noticed now:

Game over text doesn't color cycle.

Because I'm on my parents' Mac at home so can't test how real deal handles it, but holding two arrows at the same time gives inconsistent results. I.e. start running left and hold up, occasionally you'll go up or left. IIRC, ZZT favors one direction over the other, maybe it's the one you hold first, or maybe it's conditional where it checks directional keys in order then escapes once it finds one.

Both these things happen in the flash version too.

Can you hear me? Special Chris-mas encore!

Posted: Sat Dec 30, 2017 3:08 pm
by Appetite4
Sound is now implemented in the HTML 5 version!

HTML 5 beta: http://www.chriskallen.com/zzt/ZZTUltra_html5.html

All the higher-tier songs play pretty much the same as the Flash version. Note that to get these latest changes, you might have to clear your browser cache.

Fortunately, most of my low-level, 4096-byte mix buffer implementation didn't require changes. The problem was finding an outlet to which to route the mix buffer.

I decided on ScriptProcessorNode to act as the target for the mix buffer. This starts playing and never stops, with a continuous feed of sample data written to it (silence is written if no notes are playing).

The Mozilla docs say this component is dead-sound-component-walking, and it should be replaced by Web Audio Workers. Unless something has changed recently, this advice is quite disingenuous. ScriptProcessorNode works in browsers, and Web Audio Workers doesn't. On this point, we'll just have to play the waiting game.

ScriptProcessorNode has its share of frustrations. While sound uniformity with the Flash version is a huge plus, with no position accuracy issues at all, the browser itself governs what kind of output you need to write to. Channel count can vary, and even worse, sampling rate can vary. I'm looking at you, Firefox. I had to resample the WAV files to 40,000 Hz after load and re-calibrate the envelope time intervals because of your equine excrement!