Before I begin with the proposal proper, let me offer some motivation. What elements are essential to ZC's success in the future? Many ideas have been discussed about what features are most important for a hypothetical "ZC 3.0," and while new features keeping ZC fresh are important to its success, they are not as critical as the following two pillars:

1. Ability to play all existing in the Quest Databases.

Put simply, the quest databases are the most valuable assets the project has right now. The ability to create your own quests is extremely important to ZC and its community, but I'd argue that the #1 draw for new users, by far, is the ability for them to download ZC and then play hundreds of Zelda-like games created by fans, many of them of quality rivalving the official Nintendo SNES and GB games. If ZC development stopped completely, ten years from now someone might still discover the binaries and the quest databases, and rekindle interest in the project.

Therefore the ability to play old quests is paramount no matter what direction ZC development takes. Any plans that do not maintain backwards compatibility of quests (especially for the ZC player) are non-starters.

2. Portability to modern computing devices.

This is another obvious requirement: if ZC doesn't run on modern operating systems, or is temperamental/difficult to deal with on these operating systems, nobody can play any quests and the project is doomed in the long-term. ZC needs to be built on top of libraries are that as portable and future-proof as possible. (I want to carefully distinguish here between ZC having a robust and portable *back-end*, and ZC having an old-school 8-bit user interface. The two are completely separate issues, and while some might argue that the user interface in ZC and, especially, ZQuest, could do with a modern makeover, that's not what I'm talking about in this item.)

So what's the punchline? These days, a "modern operating system" doesn't mean Windows 10 (although I do have trouble running ZC on Windows 10 without tinkering with command-line switches, which is not a great state of affairs). It means Android, iOS, or even better, the browser, including the mobile browser.


So, my proposal is the following: clean up the ZC source and increase its portability to the point that it becomes possible to run the ZC player in the browser. This project, if successful, would allow us to put a "play it now" button on the quest databases, so that users on all manner of devices could play the custom quests right there in their browser. If we want Zelda Classic to regain mainstream visibility and attract new users, this has to happen, and it will only get harder the longer the delay.

And this is not as crazy of a proposal as it might sound. Projects like quakejs demonstrate the feasibility of porting natively-C++ games of the complexity level of Zelda Classic to JavaScript on the browser. But, I'm also aware that this is far from a trivial task. The main challenges I foresee are the following, with the toughest listed first:
- Allegro must be replaced by a more portable back-end. SDL is the obvious choice here, as it already is well-supported by the Emscripten C++-to-JavaScript compiler.
- ZC must be optimized to run at a reasonable speed in the browser. It also has to fit within JavaScript's allowed memory footprint (a little bit over 1GB), which I don't think is a problem for most existing quests, but is a limit we should keep in mind before we insert any additional feature bloat into ZC.
- ZC currently uses hardware bitmaps, multiple threads, and other miscellaneous low-level features that are not supported by JavaScript. These will have to be stripped out and rewritten.
- All of the above has to be done without completely breaking ZQuest (and, I suppose, ROMview). If ZQuest also runs in the browser, that's great, but I think getting the player to work is far more important, so that it's OK is ZQuest remains a desktop-only app.


So how do we go about doing this? Forking the current code and starting a complete rewrite will not work: it is too big of a task to complete in one go. Instead, I propose working incrementally towards the goal of porting to the browser. I envision the work proceeding in three phases:

Phase 0: Get Current Development Efforts on Track (time frame: a few weeks)
To be honest, even after reading the ZC development threads here and at PureZC, I'm not quite sure what the current development vision is. Before any new work can begin, our existing resources need to be organized. In particular:
1. As ZoriaRPG mentioned in the other thread, the repository needs to be cleaned up, with a reasonable branch structure, a modern build system, instructions included for how to build the source, etc.
2. The management of the project needs to be clarified. Who has access to the main repository? What is the procedure for adding or removing "core developers"? How are new features proposed, discussed, and approved? What is the procedure for code review of patches submitted by the main developers? Outside developers? Where and how should users submit bug reports? Etc.
To be clear, I don't mind if the answer to several of these is "Gleeok decides and rules with an iron fist." This is much better than developers working independently and at cross-purposes!

Phase 1: Wean The Current Code Off of Allegro Utility Libraries (time frame: 1-2 months)
The code current relies on several Allegro utility libraries that could be removed or rewritten, without needing to add any additional libraries, and without removing the core Allegro graphics backend. These include
- the packfile system
- the fixed-point arithmetic handling
- memory management
- some of the GUI code (jwin) which can be converted to using a wrapper around core Allegro functionality
Other aspects of this phase not related to replacing Allegro features:
- creating some system for automatically testing old quest compatibility, to ensure development does not break these quests (for example, by implementing a "quest demo" playback system, which checks that the same commands entered into the same quest result in the same final game state before and after each change).
- avoiding adding any new features which ties ZC more closely to Allegro, or to its current GUI or hardware backend.

Phase 2: Replace Allegro with SDL (time frame: 6 months)
This will require
- replacing all I/O and bitmap operations with SDL equivalents. This is easier the more of the GUI code can be wrapped during Phase 1, but there's no point beating around the push: this part will be long and involved.
- rewriting the sound library to use SDL_mixer instead of the current hodge-podge of external music libraries.
- replacing jwin with Saffith's GUI library?

Phase 3: Complete The Port (time frame: 3 months?)
Once Allegro has been replaced with SDL, there will still need to be miscellaneous cleanup necessary before ZC can run successfully online. Here are some issues I anticipate, though I'm sure there are others that will crop up over time:
- switching to LLVM instead of MSVC/gcc
- modifying the handling of the filesystem to allow for online play
- optimizing the rendering or script engine, as necessary, to ensure reasonable frame rates.


If you have read this far, thanks! I'm interested to know your thoughts. I feel very strongly about the need for this kind of port in order for ZC to stay vibrant in the future. While I'm not currently an active developer, I am willing to work on at least Phase 1 (single-handedly, if necessary), but I don't want to do anything without extensive discussion with the existing developers.