Page 15 of 18

Slow going

Posted: Thu Apr 13, 2017 12:32 am
by Appetite4
I have to admit--I'm having trouble motivating myself to push forward on the HTML 5 version of ZZT Ultra.

The problem is that the application works just fine in its original platform, so I need to do something to really kick my butt into gear. The dividends should speak for themselves in theory, because you'd be able to play it on any platform except IE (I never took IE support seriously).

Any suggestions from those who have also worked on a years-long project? Besides highly illegal drugs?

Re: ZZT Ultra

Posted: Sat Apr 15, 2017 4:50 am
by Commodore
You're burning out. It's no big deal, take a break, code something else or don't code at all for a while. If you treat it like a job and not a hobby then it can be easy to get discouraged. No point in forcing yourself to do something you are not enjoying, unless you can clearly see some sort of milestone and start getting giddy when some addition works.

Instead of feeling guilty about neglecting it, admit that you can walk away for a time. Poof! guilt gone and free time ahead.

Re: ZZT Ultra

Posted: Sun Apr 16, 2017 12:55 am
by Appetite4
Commodore wrote:Instead of feeling guilty about neglecting it, admit that you can walk away for a time. Poof! guilt gone and free time ahead.
I appreciate that, Commodore. Although I wouldn't exactly call this "burnout" when I never needed to do this in the first place. Sometimes, having little to prove is worse than having everything to prove: You assume a "why bother?" sentiment which hurts your motivation.

No, in case you're wondering; I haven't won the lottery. But I definitely ain't suffering either.

I guess I'll follow the advice of Maria Ross from Fullmetal Alchemist: Proceed with your goals, but without obsession of what the final outcome will be.

Re: ZZT Ultra

Posted: Wed Jun 07, 2017 8:57 am
by Ellypses
I really do appreciate your work by the way. I'm able to play ZZT again with my sanity intact, and show my fiancee a library of games for it. I'm never really a fan of DosBox atrocious emulations either and rather play on Windows XP(which I no longer have), or FreeDos(which I haven't used yet), or ZZT clones that could at least come close to the actual way the engine works. It's pretty much why I chose not to continue with a looooooot of projects I've started. Because after the death of integrated DOS on windows, no one could really play ZZT as it should be. Too slow, and clunky, and made a lot of careful designed programming more broken then it should be. It had taken a lot of spirit out of it and I didn't see the point. If I build a ZZT game from a pristine source, other users would simply play it on DosBox which breaks up it's natural timing and flow which just lowers the quality of the game overall.

Your efforts at least made it accessible as it originally did for both windows and linux.

Re: ZZT Ultra

Posted: Wed Jun 07, 2017 2:06 pm
by Saxxon
Jur wrote:I'm never really a fan of DosBox atrocious emulations either and rather play on Windows XP(which I no longer have), or FreeDos(which I haven't used yet), or ZZT clones that could at least come close to the actual way the engine works.
Dosbox throws away tight and accurate timing left and right, which completely screws with ZZT's PC speaker playback engine. It sounds awful. Using a fixed cycle count is about all you can do to mitigate the issue.

There's also the problem of ZZT's drums being cycle dependent instead of reliant on the timer. Reason being, the drum sounds needed frequencies changed more frequently than any timer could provide. Sounds great on an AT machine, not so good on more powerful machines. But if you turn down the speed, you also cripple more demanding games (Aura, for example.)

Running stock ZZT is just not a very good experience. The work being done here is a great step forward.

I don't know if I shared this before, but I've rendered the drums from ZZT using its own method. Maybe you can find them useful:
https://soundcloud.com/saxxonpike/zzt-sound-effects-0-9

Accurate Emulation?

Posted: Sun Jun 11, 2017 7:42 pm
by Appetite4
Well, if people still care, it's a good motivation to keep the project current.

That's an impossible-to-answer question, which is, what SHOULD the ZZT experience be. In the early 1990s, you couldn't get away with #CHANGE or even that many #PUT commands every frame, since CPUs were really slow. Then, in the late 1990s, CPU speeds were faster, letting you design better games which run faster. In the subsequent years, speeds were fast enough to eliminate the performance delays of ZZT altogether (unless emulated with lower clock cycles), although at the expense of the drum sounds either not being audible or sounding like a strangled rabbit.

And through it all, people design games that depend on X bug, working well only at Y speed. Aura was mentioned--I had to warn in the Supported Worlds page that the lack of a performance delay makes the "blue" ending very difficult to reach.

Ever-evolving standards. Dealing with them on my day job is bad enough. But the ZZT community? You're just killing me, people. :-)

Re: ZZT Ultra

Posted: Tue Jun 13, 2017 2:35 am
by Dr. Dos
With all the ZZTing I've been doing for Worlds of ZZT projects I've been using Dosbox set to a dynamic CPU rate rather than a fixed cycle count. Fixed cycles seems to randomly just slow to a crawl whenever I do streams (without warning and not necessarily on demanding boards), but letting Dosbox take as much CPU as it wants seems to get around that (though PC speaker sounds have lots of stray squeaks and distortions). It also has the interesting issue where it takes time to read files? Like loading a game from the world menu will involve waiting a bit as the screen first draws itself, but at low fixed cycles its nearly instant. It's weird and a mess.

Some games like Undersea Plankton Adventure specify a specific Dosbox setup, and I picked some arbitary numbers for Ruins of ZZT that ran things decently enough (though Ruins is pretty darn lax in requirements).

Re: ZZT Ultra

Posted: Thu Jun 15, 2017 7:58 pm
by Ellypses
Also, relevance. Anyone interested in this? https://itch.io/jam/remakejam

"Many of us might have lost access to our original games, either technology might have evolved to the point where they are no longer playable or original project files cannot be found. If that's the case, that's totally okay, but I encourage participants to include builds of their original games for comparison's sake."

Anyone like to ultralize their creation? Slip in some entries and make people go "WTF is a Ultra ZZT?"

ByteArray!

Posted: Wed Aug 09, 2017 3:50 am
by Appetite4
One major snag I've overcome in the HTML 5 port of ZZT Ultra: Complete port of the AS3 ByteArray class to JavaScript.

I had been under a naive assumption that it wouldn't be that hard to completely re-implement the numerous binary parsing routines in the loader and saver code. Not a good assumption--there is no equivalent to ByteArray in JS, which means my carefully-tailored code in AS3 would have required massive rewrites in a whole mess of locations.

But now that I can rely upon my "own" ByteArray, that code will barely need to change at all. Maybe this will be the motivating factor I need to complete the remainder?

Re: ZZT Ultra

Posted: Sat Aug 12, 2017 9:27 pm
by Dr. Dos
Maybe I'm misinterpreting, (and it sounds like it's a bit late anyway) but have you looked at https://developer.mozilla.org/en-US/doc ... Uint8Array ?

It's what I used for using the Museum of ZZT's file viewer when loading a file locally rather than pulling from an already uploaded to the server zip. (I then just iterated over it and converted the bytes to a giant hex string since that's the format the file viewer there is using).

Re: ZZT Ultra

Posted: Sat Aug 12, 2017 10:37 pm
by Appetite4
Oh yeah. The problem was that Uint8Array was not resizable or easily iterable; DataView and ArrayBuffer didn't serve quite as seamless a purpose as I wanted.

What my own "JS" version of the AS3 ByteArray does is wrap Uint8Array, DataView, and ArrayBuffer for its own internal use. The alternative is ripping up and modifying a large amount of byte-fiddling code to use the JS-native classes.

Re: ZZT Ultra

Posted: Thu Sep 21, 2017 9:19 am
by Ellypses
Hopped in to ask how's progression? Though I did popped in to your website but see no current news, or may overlooked ,or your butt got tello I never heard about, whatever not sure. Laptop as of now have no sort of flash what-so-ever save for my linux running Tablet PC I do most of my drawings these days. Call me reluctant to do so since adobe did said they're icing their flash project til 2020 and I'm not fund of keeping relics that aren't from GoG.com, and I've been trying to plug in flash alternatives with little success.

Plugin on the way out

Posted: Thu Sep 21, 2017 10:59 pm
by Appetite4
I'd known the Flash browser plug-in was eventually going to vanish. But it's taken a long time. I actually predicted on my website one of the conditions that would herald this moment: near-universal ad-blocking software. Flash might be okay, but the ad abusers are definitely not okay. Practically everyone in the world agrees with that now.

If nothing else, maybe this will kick my butt into gear? I could also convert the project to AIR, but that only gives you an executable to run natively.

This is my vision for keeping the project browser-friendly: have a "switch" on the website that lets one pick between HTML 5 and the plug-in. When the plug-in is no longer tenable, HTML 5 will become the only option.

HTML 5, trials and tribulations

Posted: Sun Oct 01, 2017 4:09 pm
by Appetite4
Thanks to Jur for kicking me awake again on this project.

It sure isn't easy testing everything. Basically, every single function I created before needs to be re-validated as its JavaScript variant. This picture shows a test application I've made to try out all the different loading and file parsing code.

There have been many surprises so far. JSON parser is stricter in JS than AS3. JS is more weakly typed, meaning some errors aren't caught right away. Regular expressions and sorting require different implementations. ByteArray had to be completely re-coded. There are also no single-typed vector classes in JS, which raises some questions about sparse-array performance.

On the other hand, web consoles and JIT compilers are actually far easier to work with than Adobe's own debugging environment. Times like this it feels less like a step backward and more like a trade-in between two completely unfamiliar types of cars.

HTML 5: Substantial progress!

Posted: Mon Oct 16, 2017 12:57 am
by Appetite4
Finally, managed to get a whole-engine HTML 5 integration test working! The main menu shows up, mouse and keyboard are responsive, and the timer iterates at exactly the rate it needs to.

Sound effects are not working yet, of course--that will take some doing. And problems keep showing up in the most unlikely of places--parts of the code I didn't think would cause problems after AS3 -> JS conversion are triggering console errors.

I figured that successful HTML 5 integration will appear to be rather "sudden" when it does occur. One moment, it's buggy and not close to working, and the next, it's working extremely well. With luck, the moment I've been waiting for will happen soon.