JOric

[ibisum]

Some interesting comments about this issue in this thread:

https://github.com/phaserjs/phaser/issues/4790

paulsymphonys' answer here:

https://github.com/phaserjs/phaser/issu ... -578565356

Code: Select all

var audioContext = new ((window).AudioContext || (window).webkitAudioContext)();

.. seems interesting, inasmuch as it infers that there is a 'normal AudioContext' as well as the webkit Audio Context ...

EDIT: Some more interesting details here:

https://stackoverflow.com/questions/575 ... -in-safari

iOS will only allow audioContext to be resumed if it is running within the call-stack of a UI Event Handler. Running it within a Promise moves the call to another call-stack.

Also, audioContext.resume() returns a promise, which must be awaited.

Try this:

Code: Select all

onPlayHandler() {
   alert("State before: " + this.audioContext.state);
   await this.audioContext.resume();
   alert("State after: " + this.audioContext.state);
}

[dreamseal]

I had thought this was intended, since there are two variants of the sound, but perhaps what I am hearing is an audio thread being killed and its buffers being reset uncleanly...

Yeah, it is not intentional. You are correct that it is due to the audio thread being suspended. I should try to clean that up.

[Edit: I thought the audioContext.resume code was commented out, but never mind, I should learn what /*-{ }-*/ mean in Java GWT/Javascript world...]

No worries. I didn't see the original message, but I think I know what you might have written. Yeah, GWT uses a comment syntax to embed native Javascript, which I'm making use of in a number of places, mostly for features that GWT doesn't support out of the box, but also when it is more convenient to do so. The GWT transpiler recognises that syntax and includes those bits of Javascript as-is.

Thanks for the links to the info about the audiocontext on iOS. That has got me thinking now. I have a theory about what might be happening. If you look at the code I pasted earlier, there are two calls to resume. One is the original call on start up of the emulator. The then() is expected to be called when the audio context resume completes. For most of the platforms, if the browser doesn't yet have permission to play sound, then this promise gets queued and is resolved at such time that there is another resume call that is within a user interaction. This works for everything except for iOS, I think, but I'm not sure that the spec/documentation is clear about this behaviour, so perhaps iOS has implemented it differently. Maybe iOS rejects that first call immediately, which could be what that error message in your console is, which means that there isn't a queued promise waiting to be resolved, which means that when the next resume happens within a user interaction, it essentially does nothing.

I have a strong feeling this is on the right track. Regardless if it is or not, I have something that I can try now, which is to add a .then() to the second resume that will do the set up of the audioworkletprocessor module if it hasn't been done already.

I'll let you know when I have a new version to try.

[dreamseal]

Code: Select all

[Log] Fetching program 'BASIC' (20EA5392873D13987AEEF44048C67555.cache.js, line 120730)
[Log] Resuming PSGAudioWorker... (20EA5392873D13987AEEF44048C67555.cache.js, line 120148)
[Error] Unhandled Promise Rejection: NotSupportedError: Permissions::query does not support this API

@ibisum, can you give it another go now and let me know what it logs to the console?

I have tidied up the audio code a bit so that it won't even attempt to call resume on the AudioContext unless it knows it is within a user interaction. There is a way that this can be tested within the code. I have also added more logs for certain scenarios, such as when the AudioContext fails to be created, or when the promise for the resume call is rejected.

Fingers crossed that the sound now works for you on iOS, but if not, then hopefully the log message will be clearer about which bit is failing.

[ibisum]

Here's the log messages:

Code: Select all

[Log] AudioContext not running at startup. (6F249091147D874FA1B53B92982C5650.cache.js, line 120760)
[Log] Fetching program 'BASIC' (6F249091147D874FA1B53B92982C5650.cache.js, line 120730)
[Log] Resuming PSGAudioWorker... (6F249091147D874FA1B53B92982C5650.cache.js, line 120148)
[Log] Not inside a user interaction, so skip AudioContext resume. 
(6F249091147D874FA1B53B92982C5650.cache.js, line 120800)

And here's the error message, which for some reason is not included in the above log messages, but is instead in the "Error" tab of Safari's web inspector:

Code: Select all

Unhandled Promise Rejection: NotSupportedError: Permissions::query does not support this API

[dreamseal]

Code: Select all

[Log] AudioContext not running at startup. (6F249091147D874FA1B53B92982C5650.cache.js, line 120760)
[Log] Fetching program 'BASIC' (6F249091147D874FA1B53B92982C5650.cache.js, line 120730)
[Log] Resuming PSGAudioWorker... (6F249091147D874FA1B53B92982C5650.cache.js, line 120148)
[Log] Not inside a user interaction, so skip AudioContext resume. 
(6F249091147D874FA1B53B92982C5650.cache.js, line 120800)

@ibisum, to clarify, are those the log messages that you see when you go directly to: https://oric.games/#/basic ?

And is the speaker icon displayed in the muted state, i.e. with the x next to it?

And if that is true, then what is logged to the console if you click on the speaker icon to unmute it?

[ibisum]

Yes, I'm going to #/basic, then these log messages appear.

The speaker icon appears with X, and so I press it.

The error appears when I click the icon.

[dreamseal]

So when you click the speaker icon, it doesn't log the following two log messages?

Code: Select all

Resuming PSGAudioWorker...
Inside a user interaction, so try to resume AudioContext.

If that is the case, then this would be interesting. It would suggest that it didn't even get as far as calling resume() on the AudioContext, since it should have logged the two messages above before trying to enable the sound. Maybe the error isn't to do with the audio then but is falling over somewhere between clicking the speaker unmute icon and where it logs the above log messages. I can't see what it could be though.

[dreamseal]

It's working nicely, but I think when you go to the smaller sizes you should try to make sure the scaling factor results in all pixels be of the same size so the rendered image is either 240x224 or 480x448 or 720x672, etc... but not an intermediate size because then the pixels change in width or height, and that impacts very much everything using a form of dithering to achieve gray scale or additional colors

@Dbug, if you give this another go now, it should be working like how you described.

[Dbug]

It's working nicely, but I think when you go to the smaller sizes you should try to make sure the scaling factor results in all pixels be of the same size so the rendered image is either 240x224 or 480x448 or 720x672, etc... but not an intermediate size because then the pixels change in width or height, and that impacts very much everything using a form of dithering to achieve gray scale or additional colors

@Dbug, if you give this another go now, it should be working like how you described.

Perfect! Works so much better at small size.

Regarding the UI, I was wondering if in the main selection page where you have all the games, if it would be possible to make the dots at the bottom clickable.

Right now it's possible to use page up and down to navigate between pages, or click the < and > arrows at the bottom, making the dots marking the pages clickable would kind of speed up the navigation

And what would be awesome would be to have like an incremental search field to search for games and have the page dynamically refresh to show what matches the pattern!