Implementing AGI Mouse, AGIPAL, AGI256 and AGI256-2 are all fairly trivial. I've done it in my most recent AGI interpreter project (agile-gdx), which some of you may have noticed if you follow me on github. I will apply the same updates to the C# version of AGILE when I get a chance. For now I'm focusing on agile-gdx though. I'm not too far off thinking about deploying it somewhere for people to try. I'm a bit of a perfectionist though, so not wanting to let it go before I know that it is easy to use and doesn't have any major bugs.
In summary, it is AGILE for the web. The code started out being a port of the C# version, so it should be on par with that one with regards to AGI compatibility, unless I introduced a few bugs during the conversion. I used something called libgdx that I have previously used for a few emulators that I wrote (jvic, jectrex, joric), which has the code in Java but then uses that to create versions for various platforms. In the case of agile-gdx, I am targetting HTML5 (as the main target), Android, and Desktop as an extra (due to it being Java). The Desktop version could be used on machines other than Windows, which makes it more flexible than the C# version. In theory, the HTML5 version could be packaged up as a desktop version as well to target multiple desktop platforms. I haven't really focused on the Android part of it yet, because I know that will work, from having used libgdx before (Android was my main focus for those emulator projects). For this one, HTML5 (i.e. the web) is the main focus, and it is something I hadn't targeted before with libgdx, so it was a bit of a learning curve to get things working properly. But all appears to be working quite well now. It requires a couple of HTTP response headers to be returned from the serving server in order for the web browser to agree to use certain features, but that is easy to set up on something like Cloudflare Pages or similar service. Github Pages unfortunately does not let custom headers be set in the HTTP responses, so I don't think I'll be able to host the running app alongside the code repo (as I have done for some of my HTML5 games in github). So I'm currently thinking I might try out the free tier on Cloudflare Pages.
I know that there are already two ways (that I know of) to run AGI games in the browser. One is obviously the way that archive.org does it, which is to run dosbox in the browser running the original game. And we also have sarien.net, which is a conversion of AGI games into HTML5 (so not an AGI interpreter as such). What agile-gdx would give us is an actual fully functional fan made AGI interpreter that runs directly in the browser (i.e. without a DOS emulator). I've got saved games working by using a new browser feature called OPFS (Origin Private File System). It seems to work really well. I've also got the interpreter cycle working pretty much perfectly. I had to make use of a web worker so that it doesn't block the UI thread in the browser, which is single threaded and therefore blocking it is really bad. That complicated things a bit though, because the UI thread and web worker then needed a way to share state. The main way I've done that is to use something called SharedArrayBuffers. When one side puts something in there, the other side sees it immediately, so no need to pass messages or anything like that. Pretty cool for the web. This is why I need those custom HTTP response headers though, since a browser won't just let you use these features. Already the SharedArrayBuffer was backed out due to a security issue a few years ago. It is only recently that all web browsers have reintroduced it with the security headers. I think it was March 2023 that it was officially available again in all browsers.
I'm also using OPFS to store the AGI game data files when a game is imported into agile-gdx, meaning that you don't have to import it every time you go to the website. The initial import is similar to the C# AGILE version, i.e. where a file dialog opens up and you select a folder. Everything in the folder then gets uploaded into the running app (it doesn't go anywhere near a server, since it all runs directly in the browser) and then it puts the files it recognises as AGI files into OPFS ready to be used the next time you go to the website. The gotcha with this is that OPFS is specific to the particular browser and machine that you are using, and also to the domain name and port of the website. So if you were to go to the website on another machine, or another browser, you would see the starting state again, i.e. no games to run yet. Also if you clear your browser data, that will also clear the OPFS storage. I would be annoyed if I did that after importing 100 AGI fan made games, so I might add a feature at some point to upload multiple games, perhaps from a single zip or something like that (I've already worked out how to unzip files within the browser with JS, so it should be easy to do).
I want to tidy it up a bit more, do some more testing, before I put it out there on the Internet, since once it gets out, I can't really take back that first release. I'd like to think that it becomes more popular than the C# AGILE interpreter, since the whole point was to make it really easy to use, without any installation required, and I think that certain communities on the Internet are going to find it quite cool to try out. So I'm hoping to make a good first impression. We might be able to attract a few more people into these forums as a result. It would be nice to get the domain name right first time as well, since, as I say, the OPFS bit (which is used for both saved games, and imported data files) is tied to the website domain name (in addition to the browser and local machine being used), so it wouldn't be great to rehost it with a different domain name later on.
Regarding Robin Gravel, I can still see his posts, including some from 2021.
