AGS engine Web port

[eri0o]

@Dungeonation , in your acsetup.cfg, what do you have set for game_scale_fs ? I suggest using proportional for both the game_scale_fs and game_scale_win in the webport.

Code: ags

[graphics]
game_scale_fs=proportional
game_scale_win=proportional

@Manu can you try setting your game_scale_win to proportional ? It being small should be related to this I think.

About the stretching in the width, I am not sure what it could be, but this will take a while to figure it out. :/

Ah, the fullscreen button from itch can probably be disabled, and instead it's best to use the one in the engine.

[Manu]

@Manu can you try setting your game_scale_win to proportional ? It being small should be related to this I think.

About the stretching in the width, I am not sure what it could be, but this will take a while to figure it out. :/

Ah, the fullscreen button from itch can probably be disabled, and instead, it's best to use the one in the engine.

Fix2 works too. Which one is better to use?
proportional works, now the game has the same width as the window. Unfortunately, the upscaling quality is very bad, but this is probably inevitable? It's strange because the iPhone has a very high resolution, I suppose there are enough pixels to upscale it better.

I prefer to keep the fullscreen itch button, because it works on desktop, while the toggle full screen ags button doesn't seem to have any effect (at least on Chrome).

[eri0o]

Fix2 works too. Which one is better to use?

The second fix is I think closer to how it will be the solution in the end, so probably better to use that one.

Unfortunately, the upscaling quality is very bad, but this is probably inevitable? It's strange because the iPhone has a very high resolution, I suppose there are enough pixels to upscale it better

There are, but the Safari on iPhone lies about it resolution and you need to use the resolution it says and deviceRatio to calculate the actual resolution.  Other devices usually lie a little less about their resolution, this is why it's usually not as perceptible in them.

But we aren't setting the resolution by hand, this is hidden by SDL and SDL uses Emscripten on top of it. I have been upstreaming fixes I find in these but there's a bug in it's highdpi handling (that is aware of deviceRatio) that causes the canvas size to grow indefinitely on going in and out of fullscreen, until it eventually crashes things. So highdpi handling from SDL is not used because of this.

There are some other things that makes this particular non-trivial, so haven't advanced much here. But right now the css size of the canvas is used to guess the resolution to use inside of it directly.

I prefer to keep the fullscreen itch button, because it works on desktop, while the toggle full screen ags button doesn't seem to have any effect (at least on Chrome).

Wait, which Chrome? I am using Google Chrome (111.0.5563.65 64 bits) on Windows 10 and it works in your game. Can you tell me specifically what browser and OS you are getting this behavior?

[Manu]

Wait, which Chrome? I am using Google Chrome (111.0.5563.65 64 bits) on Windows 10 and it works in your game. Can you tell me specifically what browser and OS you are getting this behavior?

Ok, sorry, it's not true that it's not working on Chrome. I thought it was not working because:
- you click the gear
- the popup appears, and you click "toggle" -> nothing happens
- then you click inside the canvas (for example I click on New Game in my game) -> switches to full screen

Just tested on Chrome for Windows and Mac.

Instead on Safari for Mac 16.3:
- you click the gear
- the popup appears, and you click "toggle" -> nothing happens
- then you click inside the canvas -> it switches to full screen for a second, then goes back to normal (the itch icon works, instead)

[eri0o]

The behavior on Chrome is expected, you need to interact to get it to go in fullscreen, it's a bit complicated, but the click interaction doesn't propagate inside the wasm and the fullscreen can only be initialized by user action, so you get this two step thing. There's no way to workaround this as we want to go through this to get SDL internals to sync with the state of the browser - if you go Fullscreen, then click to go to Fullscreen either with the gears button or with some in-game button, the state of SDL will be "wrong" and from there on you kinda get the sizes of things not working correctly. There is a way to workaround this, which would require to render the gears icon and the modal menu inside AGS Engine, if we do this, then the element we are clicking is the canvas and the canvas is the thing going Fullscreen, so this is the only way to have Fullscreen working without this two step. This may be a thing in ags4 at some point, but not right now. If you want to try this, you can edit the index.html to remove the gears button and add a Fullscreen button in-game, using a regular AGS GUI and button.

Fullscreen is a bit problematic that the size of Fullscreen is NOT your monitor resolution or whatever you expected but it's a mystery size that depends on the actual element that is going into Fullscreen (we draw things in a canvas) and if this size is bigger than the maximum that it would be possible, it fails to enter in Fullscreen (but doesn't necessarily reports a failure, it usually simply doesn't work).

So, just to explain a bit more, when using the itch icon what it does is like if your monitor enlarged and the window that the game is ran resizes to the size of this window - but if you query AGS in game it will still report that the game is windowed. The element that is fullscreen in this case is the html document.

Instead on Safari for Mac 16.3:
- you click the gear
- the popup appears, and you click "toggle" -> nothing happens
- then you click inside the canvas -> it switches to full screen for a second, then goes back to normal (the itch icon works, instead)

I am curious if the in-game Fullscreen button would work in Safari, but it's possible the maximum size for Fullscreen is not calculated correctly there. I can check this later.

[Manu]

If you want to try this, you can edit the index.html to remove the gears button and add a Fullscreen button in-game, using a regular AGS GUI and button.

I can do that, but what is the function to call when the user clicks on the GUI button?

[eri0o]

You just use System.Windowed, true is windowed and false is full-screen.

I forgot to ask, what happens when you use alt+enter?

[eri0o]

Hey, the iOS Safari fix for the touch input has been merged and should be in the next AGS Editor release.

[Manu]

I forgot to ask, what happens when you use alt+enter?

Same, it switches to full screen for a while, then returns to the browser window. The itch.io button instead worked on Safari, but it's not easy to go back because option-enter doesn't work, and Esc doesn't work, plus the itch.io icon is not visible anymore on the game screen.
I had to use Cmd+tab to switch to another window, then go back to the itch page. It's a bit of a mess.

[eri0o]

Thank you for the tests. About iOS, I discovered the fullscreen API is not supported in iPhone, only iPad

https://caniuse.com/?search=fullscreen

There is a Safari specific fullscreen API, but it is also iPad only - and apparently Emscripten doesn't implement it. It appears this api may work better - but need to test this. For your iPad version specifically though, there's a toggle in the experimental toggles of your Safari browser that needs to be turned on.

The Safari specific API looks like is intended to be used only with Videos, but it is this: https://developer.apple.com/documentation/webkitjs/htmlvideoelement/1633500-webkitenterfullscreen

About Emscripten I think I found a way to force it to generate a wasm code that MAYBE can be loaded in the iOS version you have, but I couldn't yet make it work, I can try later so we can test this.

Back to macOS Safari, I don't know yet what is going on. I think I can later try to use the Safari specific API and see if it makes it magically work. Edit: reading the Emscripten source code it looks like it can use the Safari specific API, I may need to set a specific variable at build time to make sure this actually is built in.

Found a really nice API for getting the real pixel size of things

https://developer.mozilla.org/en-US/docs/Web/API/ResizeObserverEntry/devicePixelContentBoxSize

Unfortunately it's not supported on Safari

[Manu]

Just for curiosity, checking the stats of my page on itch, I can see the first mobile OS is Android 13, followed by iOS 16.3.1, then Android 12, then iOS version 16.2. Apparently, most of them are smartphones, not tablets. So my old iPad is not really a priority, but I think making fullscreen work on iPhones is important, considering that screens are small and switching to full screen can make a difference.
Let me know if you need more tests. Thanks for your work!

[eri0o]

Just a minor update, I haven't advanced much in iPhone, it simply doesn't support fullscreen so some workaround is needed. There is one case iPhone supports Fullscreen, which is in a PWA app (installable web app), but the iframe in itch prevents PWA, and apparently there is no known way to circumvent this for itch - this is apparently true for other "web game stores" but I haven't profoundly checked this in non-itch case.

The way to go with iPhone it seems is to load the iframe directly and use some strategy to make sure this uses the most of the browser area - I actually think it should be doing this already but I haven't checked this yet.

About the iPad version you have, I really would need to use an old version of Emscripten because even with the build flags on the newer I thought could generate compatible wasm it didn't work when I tested, it looks like they didn't affect the actual wasm part of the code only the JS, so I think I misunderstood what they mean. So unfortunately what we can do is workout a better error message for the time being on the unsupported browsers.

Overall I don't think I will be able to advance quickly regarding how iPhone is handling fullscreen (Safari doesn't implement the API, except for video only) and resolution.

So what I want to do now is take a step back, create a non-ags minimal SDL demo app, and use it to recreate the minimal reproducible test cases so I can report the issues upstream (SDL and Emscripten) and then later reevaluate what to do.

In the meantime if you want to reshape the html part to move/remove the gears icon (it's covering Uhura), the non-minified html shell is here:

https://github.com/adventuregamestudio/ags/blob/master/Emscripten/launcher_index.html

[Dungeonation]

Games don't typically go into fullscreen on iOS in the browser anyway, so I'm fine with that not being figured out yet. If we remove the cog wheel icon, can we call a data erase from within the game like we can a fullscreen toggle?

[eri0o]

There's no API for this currently, so no - we could have one, but at the moment there isn't. Because this is Web specific I would like to take a little time before implementing something - maybe additional web specific stuff will appear.

There's a hacky way you can do this through deleting files using the regular AGS Script file API and after do a write in a small text file, it will save that one file but when it does it will sync the write on the database and it will sync the deleted files as deleted, so they would disappear.

Note the FS library we use in the web port also doesn't have an API to delete all files, so the button uses JS to delete each file in the directory recursively in MEMFS and then syncs the resulting empty dir with IDBFS, causing IndexedDB to clear up. If you open a file in AGS and then don't close it, and then uses the cog wheel button to delete all files the specific file you had not closed I believe should trigger a permission denied exception because it's being used by AGS - I believe I made it generate an error popup later but I don't remember if it says what happened.

(sorry for being overly verbose, but I can use these messages as annotations for myself to remember things later)

[Dungeonation]

Upon testing all the touch emulation settings, I still can't get GUI buttons to take one tap to press, it still takes two. Could it be something I'm not doing correctly?

[Crimson Wizard]

Upon testing all the touch emulation settings, I still can't get GUI buttons to take one tap to press, it still takes two. Could it be something I'm not doing correctly?

To double check, is this your game or someone elses, are these buttons handled normally in script, using regular OnClick event or some other workaround?

[Dungeonation]

Upon testing all the touch emulation settings, I still can't get GUI buttons to take one tap to press, it still takes two. Could it be something I'm not doing correctly?

To double check, is this your game or someone elses, are these buttons handled normally in script, using regular OnClick event or some other workaround?

It's my game, and I use onClick

[Crimson Wizard]

Yes, apparently this is because of how GUI interaction is coded in AGS, it updates the new cursor position too late, after the "click" event already happened. This is normally not an issue with the mouse (at least not for engine itself, for script maybe), as it's tracked all the time, but this breaks with the touch as with touch it's tracked only when you drag around.

I suspect this probably can even lead to more distinct bugs, like if you first click on button 1, and then on button 2, will button 1 click again? (not sure if that's the case though)

[Dungeonation]

Just tested, that bug doesn't occur for me.

[Crimson Wizard]

Just tested, that bug doesn't occur for me.

Hmm, I actually have it; it also happens if you
1) touch the button
2) touch the empty spot on gui
the button will still be pressed on the second time.