ZZT Ultra

Discuss how totally awesome Bang! is here.

Moderator: Terryn

User avatar
Smilymzx
I hope she made lotsa spaghetti!
Posts: 182
Joined: Sat May 20, 2006 2:58 am
Location: LocacoLocacoL :LoL!

Re: Source Code Available!

Post by Smilymzx »

Appetite4 wrote: The download link has the ZZT Ultra source code. Now you'll be able to see how this beast actually works.

Building the project is another matter. It helps to have a version of Adobe Flash/Animate. I'm starting to wonder, though, if there is a better way to deploy this going forward. AS3 can deploy to multiple platforms, but the newer subscription model for Adobe's products is bound to frighten off a lot of amateur developers with limited means.

Perhaps someone could port the code to Unreal Engine 4? That would be very funny...
To quote myself from another post:
Smilymzx wrote:I cannot do AS3 due to Adobe Licensing stuff and the expensiveness of having to use it (there is no permanent price)

The only way for sure is porting to a language like C or Javascript, making a cloudless edition to make it easier
User avatar
Appetite4
Official Clamp School Defender
Posts: 204
Joined: Tue Nov 18, 2014 4:57 am
Contact:

ZZT Ultra coding platforms

Post by Appetite4 »

I've been doing some hard thinking about multi-platform deployment for ZZT Ultra.

One point of interest: code conversion. Look at http://as3js.org/ and you'll see one example of tools people have been creating to convert code authored in one platform to another. While this only deals with code, and not necessarily assets, it's a great start.

We should just get this out of the way now: Which languages are ideal for deploying a next-gen ZZT platform? Here are the languages and platforms I can think of now:
  • AS3 (Flash, Adobe AIR)
  • Javascript (HTML 5)
  • Java (Android)
  • C# (Windows platform targets)
  • C/C++ (Google Chrome's NaCl platform)
  • Python (with Qt, SDL, or OpenGL as renderer)
It would be awesome to have builds for every single one of these platforms. It would also be unrealistic--just two or three of these would work pretty well. Universality would be great, but it isn't possible with just one language.

One thing is definite: managed language implementation is preferable. Technically, I consider NaCl managed because the API is sandboxed, and the latest C++ standard isn't as "unmanaged" as it used to be.

Thoughts?
User avatar
Smilymzx
I hope she made lotsa spaghetti!
Posts: 182
Joined: Sat May 20, 2006 2:58 am
Location: LocacoLocacoL :LoL!

Re: ZZT Ultra

Post by Smilymzx »

AS3: is ultra expensive, so most (like me) cannot even compile the source.

Java: Compiling is hard on those without special space requirements, so think twice!

Javascript (HTML5): Okay if using a browser, but the sound problems you had may still be there (?)

C# (Windows only): is not good for multiplatform, so not a good idea.

C/C++ (Google NaCl): If it's not portable to Linux/Windows/Mac/Ect. It isn't a good idea!

Python: Is THE option if you want it to be ultra-portable in these cases!

I would pick Python! (Python is better than any other anyways!)
User avatar
Appetite4
Official Clamp School Defender
Posts: 204
Joined: Tue Nov 18, 2014 4:57 am
Contact:

Multiple Platforms: A-go!

Post by Appetite4 »

Okay, then...I've decided to change focus with ZZT Ultra. Henceforth, I'm going to make a serious effort to take the project totally open.

That is, official version binaries and sources, possible github storage, and support for several different languages (some via code conversion, and some using re-implementation of platform-specific features).

The platform builds I have in mind are:
  • AS3 (Not just browser plugin--also Adobe AIR, which makes locally-run executables)
  • HTML5 (Converted to JavaScript)
  • Python with SDL (Targets any platform that supports SDL)
I will go on the record that Google NaCl looks incredibly attractive...but it unfortunately is not a de-facto web standard. I'll consider offering this build next, if it is deemed worth it. If only this were implemented everywhere!

Java and C# are strong managed languages, but they have limited reach. Probably going to pass on these.

I'm now doing a system architecture inventory of the AS3 code, so that I can remove as many UI/local environment dependencies from the business logic as possible. This has mostly been done already, but it could stand to be better. Code files that are purely business logic are easiest to convert.
User avatar
Commodore
fgsdfs
Posts: 2471
Joined: Wed Mar 12, 2003 5:44 pm
Location: :noitacoL
Contact:

Re: ZZT Ultra

Post by Commodore »

I think SDL is the way to go. I'm not qualified to say that, but recently the maintainers of the commodore emulator VICE, have considered scrapping all ports and going purely SDL. VICE is written in C though.

C's pretty universal but python is catching up fast.
*POW* *CLANK* *PING*
User avatar
Saxxon
the Gargoyle.
Posts: 608
Joined: Tue Jul 25, 2006 10:02 am
Contact:

Re: ZZT Ultra

Post by Saxxon »

SDL is a great way to go. It's wildly compatible and there are bindings that work on pretty much every platform.

Edit: In response to SmileyMZX, we've been able to get Roton on Win/Osx/Linux, so long as we avoid DirectX :) Mono+OpenTK works wonderfully for us.
User avatar
Appetite4
Official Clamp School Defender
Posts: 204
Joined: Tue Nov 18, 2014 4:57 am
Contact:

Complete: ZZT Ultra Multiplatform Treatment

Post by Appetite4 »

Hi Y'All,

I painstakingly categorized every single function in ZZT Ultra's project. Most of the business logic can stay the same in all platforms, but some parts of classes (and some entire classes) will need to be rebuilt.

What will need rebuilding:
  • ASCII_Characters: The stock text-mode character sprites will have different resource loading mechanisms in each platform.
  • CellGrid: The VGA hardware emulation layer will have nearly identical functions in each platform, but a very different implementation for each.
  • Sounds/FxEnvelope: Audio mixing will vary a lot from one platform to the next. A lot of work is needed here.
  • parse: File system and network resource access will need to invoke different functions. Much of this component is dependent on whether the engine is run client-side or server-side.
  • input: Thankfully, almost nothing needs changing here. Mouse, keyboard, and possibly joystick or accelerometer input have different polling and event-trap functions per platform.
  • zzt: There are a few controls, like large text entry boxes, that will need to have different implementations. Both JS and PySDL2 support these controls, fortunately, so there won't be a need to write an entire from-scratch text editor.
Good thing I didn't put a metric ton of AS3 code within individual MovieClips, or else separating the code from the resources would be far worse.
User avatar
Appetite4
Official Clamp School Defender
Posts: 204
Joined: Tue Nov 18, 2014 4:57 am
Contact:

HTML5 Resources

Post by Appetite4 »

At this point, I can see how I would be able to re-implement the CellGrid class using an HTML5 Canvas. The interface allows you to pick apart the individual pixel data (including alpha channel) using JavaScript. I know how decent the performance is already, so it's just a matter of re-coding the interfacial functions.

Sound is a different matter. I know it's not "technically" part of the HTML5 spec, but Mozilla's Web Audio API looks like a good start. It is compatible with most browsers (except IE, but who cares about IE).

The problem is that my AS3 implementation for audio had real-time mixing, requiring direct calculation of sample data in 4096-byte increments (about 11 times per second). Inability to do this type of mixing in a different platform means the audio will invariably end up worse, or delayed, or even impossible. Gotta think it through.
User avatar
Appetite4
Official Clamp School Defender
Posts: 204
Joined: Tue Nov 18, 2014 4:57 am
Contact:

More tests: HTML5

Post by Appetite4 »

I've been making some proof-of-concept advancements for the "HTML 5" version of ZZT Ultra. This screenshot represents a very fast sprite rendering system using temporary canvas-on-canvas blitting.

Dealing with input and timing are straightforward. Key events, mouse events, and timing events all work with reasonable resolution, so re-implementing these in JavaScript won't be hard.

One issue: key event trapping in JavaScript is done at the document level, not the canvas level. This means function keys like F1, F3, and F5 will automatically perform browser-specific actions despite being trapped! You have to cancel the event during the handling process, which is wonky and not necessarily reliable. Such as JavaScript, though.

Loading (uploading) files works about the same way as AS3. It will be somewhat annoying that the ByteArray type does not exist in JavaScript. Different classes for the job.

Saving (downloading) files is gonna suck. I'm sorry to have to report this, but the standards gurus just can't seem to agree on a common way to seamlessly download a file with a reliable dialog box, without security issues getting in the way. Any file saved in HTML 5 will probably have to go to the browser's "downloads" folder, or give an aggravating user prompt about "Do you want to download / run / check for viruses?" message every time you save.

And sound playback? Still a ways off.
Attachments
HTML 5 character rendering test
HTML 5 character rendering test
html5_test.png (7.75 KiB) Viewed 8004 times
User avatar
Saxxon
the Gargoyle.
Posts: 608
Joined: Tue Jul 25, 2006 10:02 am
Contact:

Re: ZZT Ultra

Post by Saxxon »

The spec for WebAudio is very thorough and awesome, but implementation in current browsers is really lacking. Someone cobbled together a synth, but the latency was like 150ms+. That kind of latency doesn't really fly in games.
User avatar
Appetite4
Official Clamp School Defender
Posts: 204
Joined: Tue Nov 18, 2014 4:57 am
Contact:

WebAudio API

Post by Appetite4 »

Two things are a serious irritant right now for an HTML 5 implementation: The fact that the file system API "FileSaver" and WebAudio API "ScriptProcessor" components were created, but not standardized, and the fact that replacements for these components are listed as up-and-coming, but then they just don't get implemented.

I hate having to wait for stuff like this. But invariably, I'll have to build platform-specific compatibility caveats into some versions of ZZT Ultra until the dust settles.

In many respects, a Python/SDL build would be easiest because you can usually assume direct system call access. The problem there is the language architectural differences; program structure is like night and day between Python and most other C-based languages. But I have a solution--I'm working on a code converter from AS3 to Python, to complement the one already in existence from AS3 to JS.
User avatar
Smilymzx
I hope she made lotsa spaghetti!
Posts: 182
Joined: Sat May 20, 2006 2:58 am
Location: LocacoLocacoL :LoL!

Re: ZZT Ultra

Post by Smilymzx »

Ummm... When I upgraded my Flash Player, the HTML and the SWF cannot do anything due to a "Security Error".

Code: Select all

ERROR: SecurityError: Error #2148
How awful!
User avatar
Appetite4
Official Clamp School Defender
Posts: 204
Joined: Tue Nov 18, 2014 4:57 am
Contact:

Re: ZZT Ultra

Post by Appetite4 »

Smilymzx wrote:Ummm... When I upgraded my Flash Player, the HTML and the SWF cannot do anything due to a "Security Error".

Code: Select all

ERROR: SecurityError: Error #2148
How awful!
Chrome, right? I got this too. Seems to affect it more when you try to launch content from the file:// protocol, indicating local files.

The fix for this is in modifying your global settings, as described on this page: http://www.macromedia.com/support/docum ... ger04.html

At least for me, IE and Firefox had no trouble. Only Chrome broke with an update over the last few months.
ZZTBandit
Ordinery
Posts: 45
Joined: Wed Sep 07, 2016 6:07 pm
Location: neutral

Re: ZZT Ultra

Post by ZZTBandit »

Hey bro don't fret, ZZT Ultra is the best of its kind! The fact that it uses flash isn't a bad thing, since it runs on just about everything and actually performs better on older hardware. It's nice to have an alternative. I wasn't feeling adventurous enough to test it out on my project though, having already familiarized myself with ZAP but I totally mess around with it now and again. Also, sorry for lashing out. It's been a 4 year development hell and the last thing I wanted was more competitive friction from you, but please accept my apology.
User avatar
Appetite4
Official Clamp School Defender
Posts: 204
Joined: Tue Nov 18, 2014 4:57 am
Contact:

It's OK

Post by Appetite4 »

I absolutely know what development hell is like. Apology accepted.

The notion of competitive friction is rather misplaced. I thought it was a good idea for ALL projects to continue, all ahead full. Despite our best efforts, there is no way to know for sure which projects will prevail as "the best" because no one has 20-20 hindsight until it is all said and done. There are still things that the webchars project does very well that ZZT Ultra does not, from a purely architectural perspective.

We aren't in competition with each other in these forums. If people don't try, no one would do anything of value. I'm reminded of all the zillions of Wolfenstein 3D clones made in the early 1990s, which were all but knocked into irrelevancy by DOOM only a few years later. They might be inferior to DOOM, but they still exist. Who could have predicted what would be the "next big thing?"

I certainly can't. But I have some hot stock tips in case you're interested. He he... (kidding).
Post Reply