The web version of AGILE (https://agi.sierra.games)

[lance.ewing]

Good news! It works on Safari iOS! I'll need to wait until I get home from work to test for the desktop version of Safari, but I'm sure it will be successful as well.

Edit: Confirmed working on Safari Desktop as well. Nice work!

That's great news! Thanks for checking both of those.

FYI, I'm on a MBP that's 10+ years old and running an outdated OS, which can no longer be updated. While the game now loads fine, there seem to be some minor control/keyboard issues that take some browser refreshes to get working.

Can you elaborate on what you mean by control/keyboard issues? Is it to do with the movement of ego and the direction keys? I did  make another change yesterday that should have improved the responsiveness of the arrow keys. Could that be it?

[doomlazer]

After testing again it does seem like that might be the problem. I'm having arrow key (physical and virtual) and joystick issues on Safari 16.6.1. They don't move the character, but typing works fine.

On Safari for iOS (v17.4) the joystick and virtual keyboard arrow keys still work perfectly though.

[lance.ewing]

After testing again it does seem like that might be the problem. I'm having arrow key (physical and virtual) and joystick issues on Safari 16.6.1. They don't move the character, but typing works fine.

On Safari for iOS (v17.4) the joystick and virtual keyboard arrow keys still work perfectly though.

Hmmm, that's strange. You are describing the opposite of what I expected to happen. Was it behaving like that in Safari 16 from the beginning? Or was it only since about a day ago? - It wouldn't surprise me if it was like prior to yesterday, but I was expected it to be fixed now.

@Kawa raised the issue to me originally, that the direction keys were not working reliably in Firefox. I think it was a more general problem, but certainly very noticeable in Firefox. Chrome was generally reliable, but sometimes I also noticed that a direction key was ignored there as well.

The cause for this was that the current direction key state was being tested by the interpreter, i.e. "is it currently down, and has it just been clicked", rather than having the direction/arrow key presses also go via the keypress queue. It gives an opportunity for an arrow key to be pressed quickly, where the down and up happens fast enough that the interpreter doesn't see it. Chrome seemed to be able to pick up on them but not so much Firefox. Perhaps Safari had a similar issue. - One thing that I see happen in Firefox fairly regularly are small pauses in the animation, which probably contributed to the loss of arrow key detection, but now that they're going via the keypress key, it should be working (I need to investigate the small "hanging" moments in Firefox as a separate issue).

Yesterday I made a change to address this. It now sends the arrow key presses via the same key press queue that the other key presses go via. It appeared to fix the issue in Firefox for me, but if other people are seeing issues, then maybe I haven't covered all the bases with regards to the key codes. It looks like I have though. Both the arrow keys and the numeric key pad equivalents are working for me.

Has anyone else noticed issues with the direction keys over the past day?

[doomlazer]

I don't think the keyboard issues with Safari 16 have changed in the last few days as far as I can tell. It's strange because if I open the java console to check for errors the joystick and arrow keys magically start working - I noticed similar behavior last week as well so it feels consistent. 

[lance.ewing]

I don't think the keyboard issues with Safari 16 have changed in the last few days as far as I can tell.

It's strange because if I open the java console to check for errors the joystick and arrow keys magically start working - I noticed similar behavior last week as well so it feels consistent.

Is it that the direction keys don't work at all in Safari 16, i.e. not possible to move ego at all, unless you open the javascript console?

If so, that is a bit strange.

I assume that other animation is working fine? e.g. waves breaking at the start of King's Quest 2? Crocodiles moving at the start of King's Quest 1?

The keypress events are sent from the UI thread to the web worker thread via a SharedArrayBuffer. I wonder if the problem is that the web worker isn't seeing the state of that SharedArrayBuffer changing (some sort of delay in earlier Safari versions in making it visible to the other side), or whether it is seeing it but the animation isn't updating. I suspect that if the animation wasn't updating that you would see more obvious indications of that.

[lance.ewing]

(I need to investigate the small "hanging" moments in Firefox as a separate issue).

I have a theory about what is causing this. The UI thread posts a message to the web worker telling it to perform a "Tick", and then the web worker sends another message back saying that the tick is complete. If the browser slows down momentarily in processing the messages on each side then it would result in short hanging moments. Ticks need to be processed in quite quick succession, so the current approach relies a lot on these posted messages being picked up immediately. I'm having a rethink about how to keep the animation smooth whilst still keeping the two sides in sync. I tried something last night that should have worked but struggling to get the browser to recognise the API I'm trying to use. It is theoretically possible to get the web worker called for every browser animation frame, even though web workers don't have direct access to the UI. The libgdx framework uses that within the UI thread to do its rendering. So maybe I can get the web worker to get pinged by the browser directly at the same rate as the UI thread and use the AGI interpreter's master tick counter to play catch up if required, so they're kept in sync. I need to do something like this as I'm not happy with how the animation hangs for short durations in Firefox, leading to jerky animation.

[doomlazer]

Is it that the direction keys don't work at all in Safari 16, i.e. not possible to move ego at all, unless you open the javascript console?

If so, that is a bit strange.

I assume that other animation is working fine? e.g. waves breaking at the start of King's Quest 2? Crocodiles moving at the start of King's Quest 1?

The keypress events are sent from the UI thread to the web worker thread via a SharedArrayBuffer. I wonder if the problem is that the web worker isn't seeing the state of that SharedArrayBuffer changing (some sort of delay in earlier Safari versions in making it visible to the other side), or whether it is seeing it but the animation isn't updating. I suspect that if the animation wasn't updating that you would see more obvious indications of that.

It's super inconsistent with Safari 16. Often the sound doesn't work until refreshing, other times no key presses work and I can't make it past the title screen (until opening the developer java console). Reloading will sometime make sounds and letter key presses work, but then movement doesn't register. Non-movement animations always seem fine and it always loads and imports games now. Opening the Java console seems to magically make things work, but a regular user will never do that.

Everything seems to work great in Safari 17, so I wouldn't focus too much on older versions. Even on my outdated Mac OS the other browsers seem to work just fine. Safari is kind of terrible for compatibility in general, so I wouldn't spend too much time trying to fix for Safari 16. Considering how few Safari users there will be in general and that planned obsolescence seems to be the Apple strategy, I feel like the fixes you've implemented with importing games have addressed the Safari bugs. Time would be better spent on bugs manifesting in real browsers than anomalies specific to Safari <=  v16. Still happy to test as requested, of course.

[lance.ewing]

It's super inconsistent with Safari 16. Often the sound doesn't work until refreshing, other times no key presses work and I can't make it past the title screen (until opening the developer java console). Reloading will sometime make sounds and letter key presses work, but then movement doesn't register. Non-movement animations always seem fine and it always loads and imports games now. Opening the Java console seems to magically make things work, but a regular user will never do that.

Everything seems to work great in Safari 17, so I wouldn't focus too much on older versions. Even on my outdated Mac OS the other browsers seem to work just fine. Safari is kind of terrible for compatibility in general, so I wouldn't spend too much time trying to fix for Safari 16. Considering how few Safari users there will be in general and that planned obsolescence seems to be the Apple strategy, I feel like the fixes you've implemented with importing games have addressed the Safari bugs. Time would be better spent on bugs manifesting in real browsers than anomalies specific to Safari <=  v16. Still happy to test as requested, of course.

Thanks for the description of the Safari 16 behaviour. Given how inconsistent it is, where it sometimes works and sometimes doesn't, I'm inclined to agree with you that there isn't much that can be done and that Safari 17 should be the recommended starting point. Some of the APIs I'm using are quite new ones, so perhaps the Safari 16 implementations of those APIs are not the best.

[lance.ewing]

I have a theory about what is causing this. The UI thread posts a message to the web worker telling it to perform a "Tick", and then the web worker sends another message back saying that the tick is complete. If the browser slows down momentarily in processing the messages on each side then it would result in short hanging moments. Ticks need to be processed in quite quick succession, so the current approach relies a lot on these posted messages being picked up immediately. I'm having a rethink about how to keep the animation smooth whilst still keeping the two sides in sync. I tried something last night that should have worked but struggling to get the browser to recognise the API I'm trying to use. It is theoretically possible to get the web worker called for every browser animation frame, even though web workers don't have direct access to the UI. The libgdx framework uses that within the UI thread to do its rendering. So maybe I can get the web worker to get pinged by the browser directly at the same rate as the UI thread and use the AGI interpreter's master tick counter to play catch up if required, so they're kept in sync. I need to do something like this as I'm not happy with how the animation hangs for short durations in Firefox, leading to jerky animation.

Apologies, I may have made things worse in some places in an attempt to fix the above issue. The brief pauses in animation are no longer happening in Firefox, but I've noticed some weird flashing of text windows in some scenarios (e.g. KQ4 intro) that weren't happening before. I'll investigate this later on.

[doomlazer]

Thanks for the description of the Safari 16 behaviour. Given how inconsistent it is, where it sometimes works and sometimes doesn't, I'm inclined to agree with you that there isn't much that can be done and that Safari 17 should be the recommended starting point. Some of the APIs I'm using are quite new ones, so perhaps the Safari 16 implementations of those APIs are not the best.

Apple is good at selling $75 cables and scraping 30% off the top of in-app purchases. They never really mastered the whole browser thing. You'd probably have better luck supporting text browsers like Links/Lynx.

[lskovlun]

WebKit descends from KHTML. A teaching assistant I had at university worked on KHTML.

[pmkelly]

WebKit descends from KHTML. A teaching assistant I had at university worked on KHTML.

So did I! This was my second programming language/engine project after AGI studio; I worked on KJS, the JavaScript engine, and parts of the DOM APIs.

By far the most difficult aspect of it was the extent to which web pages and scripts did not comply with the standards. If you think fixing compatibility issues among different AGI or SCI games is tricky, try supporting the entire web. And at that time web developers would just target Netscape/IE (increasingly the latter), because that was "the standard".

Like the time I spent on AGI, I was also told that the KHTML/KJS projects were a waste of time and what was the point, IE is the standard and you should just accept the status quo. I've long-since learned to ignore people who say things like that. Both were extremely educational experiences that lead me on to even better things. At the time I had no idea it would be adopted by Apple, but that wasn't relevant; I just work on things that are fun and/or potentially useful.

[lance.ewing]

Apologies, I may have made things worse in some places in an attempt to fix the above issue. The brief pauses in animation are no longer happening in Firefox, but I've noticed some weird flashing of text windows in some scenarios (e.g. KQ4 intro) that weren't happening before. I'll investigate this later on.

I have improved things a bit by using an approach that is partway between what I was originally using, and the approach I changed it to a few days ago. The flashing text window in the KQ4 intro is no longer happening in Chrome and Edge, but does still happen in Firefox, unfortunately. That made me a little suspicious, so I went back to test with Firefox using the original code. The flashing text window happens in Firefox with that code as well, so the new approach hadn't introduced that issue, at least in the case of Firefox. So I'm going to keep the new hybrid approach, since it fixes the short pauses that Firefox was experiencing, which was the main reason for the change, and as far as I can tell, the other browsers still look fine. I'll treat the Firefox flashing window issue in KQ4 as a pre-existing separate issue to deal with, although it may be quite a hard one to address.

[lance.ewing]

Thanks for the description of the Safari 16 behaviour. Given how inconsistent it is, where it sometimes works and sometimes doesn't, I'm inclined to agree with you that there isn't much that can be done and that Safari 17 should be the recommended starting point. Some of the APIs I'm using are quite new ones, so perhaps the Safari 16 implementations of those APIs are not the best.

Apple is good at selling $75 cables and scraping 30% off the top of in-app purchases. They never really mastered the whole browser thing. You'd probably have better luck supporting text browsers like Links/Lynx.

Out of curiosity, is it working any better in Safari 16 at the moment? (now that I've got rid of the postMessage mechanism for syncing the UI thread and web worker; it is using an entry in a SharedArrayBuffer now. It wouldn't surprise me actually if it is now running worse on Safari 16 given this change, but I think I needed to address the animation pauses within Firefox as a priority over Safari 16. Still, it would be interesting to know if it had any impact on Safari 16 either way, for the better or worse.

[lance.ewing]

Like the time I spent on AGI, I was also told that the KHTML/KJS projects were a waste of time and what was the point, IE is the standard and you should just accept the status quo. I've long-since learned to ignore people who say things like that. Both were extremely educational experiences that lead me on to even better things. At the time I had no idea it would be adopted by Apple, but that wasn't relevant; I just work on things that are fun and/or potentially useful.

Back when you released AGI Studio, it was roughly when I was starting full time work in IT. I'd just graduated from University. I remember that the web browsers around at that time were Netscape 2/3 and IE 3/4. I didn't look that up, so my memory might be a bit vague, but those versions seem to ring a bell. In those days, IE had the Java VM built into the web browser itself, rather than being a plugin. And I remember that Microsoft's implementation of the Java VM wasn't 100% accurate compared to Sun's. Well, Java applets haven't been a thing in web browsers for a long time now, so fortunately we don't have to worry about differences in that area anymore. And Javascript seems mostly quite consistent across the browsers these days. I have very little experience with Safari though, as is evidenced by the discussion in this thread.

@pmkelly, what are your thoughts regarding the web version of AGILE? Have you had a chance to try it out yet?