123
-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0|591|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
Socoder -> Off Topic -> The silence is silent

Mon, 06 Jun 2011, 01:27
JL235
if sound doesn’t work, then it should fail silently
Mon, 06 Jun 2011, 01:27
Jayenkai
I don't get what you mean... Does PMC die on it's ass? 'cos it seemed to run fine (yet silent) when on the iPhing/Android

-=-=-
''Load, Next List!''
Mon, 06 Jun 2011, 02:18
JL235
No it doesn't "die on it's ass". I was just wondering how the PMC API should act when sound is unsupported; because currently that is undecided (and should do something consistent).

i.e. if you call 'play' should the sound then be in a 'play' state (like normal), or since the sound isn't playing should it just permanently stay in the 'stop' state, or what?

The solution I am going to build is to try to fake it as accurately as possible. If sound is unsupported, then I'm going to add timers behind the scenes that will expire at the same time the sound would normally stop playing. This way moving from 'play' to 'stop', and running events when sound has finished, all still work as normal. To a users the code the sound appears to always work.

But there will also be a function added so you can check if sound is not supported, such as if you've built a rhythm action game.
Mon, 06 Jun 2011, 02:34
Jayenkai
I probably wouldn't do that.
HTML5's audio is occasionally glitchy, in that you say "Play" and the system goes "OK.. Gimme a tick.. hang on.. one sec.. ok, PLAY!!!"

If you attempt to lock events to a simulated playtime, then the actual audio might be out far enough that the simulated thing's ending up being way ahead of it, and all your timings are out by a mile.

IMO, a rhythm game should be based on actual time, not the assumption that the system's audio can actually handle everything!
Get the smooth gameplay, then piss about trying to fix the audio.
Gameplay is king.

-=-=-
''Load, Next List!''
Mon, 06 Jun 2011, 03:06
JL235
I think you've jumped ahead of yourself Jay. This isn't about what happens when the audio plays, it's about what happens when the audio is unsupported (and so does not play at all).

Under that condition it's ok to presume that a 1 minute song will take exactly 1 minute (in order to fake the events).

Under normal conditions it will play the events (like on finish) appropriately (when the audio actually finishes).
Mon, 06 Jun 2011, 04:07
Jayenkai
But then the two timers will be different. One will trigger by the software timers, and the other will trigger by the audio ones.
The occasional html audio delay will break the timings.

-=-=-
''Load, Next List!''
Mon, 06 Jun 2011, 04:58
JL235
The timings won't exist at the same time.

If sound works: it'll use audio timers.

If sound doesn't work: it'll use software timers (to look like the audio is working).