pouët.net

My idea with the MIME didn't really work, and for good reasons I believe :). I checked Ransom's code, very neat runs perfectly fine on FF 3.7.a1pre although I had to disable "script is unresponsive" thingy.

@iq :
i didnt know San Angeles Observation use shaders for rendering his geometric shapes. (why not use basic polygons ? take less place when defining them with 3d formula ?). also why is there not source for this prod?

Well, it's javascript, so I suppose a right click -> view source would be possible :)

WebGL sucks, bring me the RealGL !

(still seeking for the universally agreed VM/bytecode spec. Java was/is nice but way too HL, IMHO. Garbage Collection my a§5) ;^)

Tigrou, San Angeles Observation doen'st use any shaders at all. Its port to WebGL does, as you can't render without shaders in WebGL (there is no fixed function pipeline, finally).

As for the source, what stijn said...?

so next one, how do we sync with audio in webgl? flash with liveconnect maybe? i don't suppose embed/object tags have getPlaybackPositionInMilliseconds()...

@skrebbel, yep probably using flash or silverlight is the only way to get a proper control over the sound (and even being able to generate the sound on the fly), but not being able to package the whole thing in a tiny single html file is not going to facilitate WebGL adoption for intros....

i don't think packaging matters much in this context. who cares about the size on the web - you can't even see what size things are. so at least i don't.

to me what matters much more is that you can click a link and watch a demo. no 250 megabytes streaming, no plugin installation, just the demo and that's it. i think that's going to be pretty cool.

and allow for awesome demotools.

@skrebbel HTML5's audio object (which is supported by those browsers that support webGL) has a .currentTime attribute, but its resolution is in seconds, which I imagine isn't precise enough... might be worth sending a mail to the HTML5 mailing list about, I suppose there's a use case for more precise timing other than demos

stjin: the weak type of the returned value might be a floating-point type hence supplying the necessary precision :). of course it won't be grand but it's still not integer.

stijn and decipher made me run a little test, and in minefield, it seems to have pretty bad precision. here's the first second of an ogg in an audio tag, displayed with setInterval running at 1 millisecond (and the browser clearly not managing that speed, but ok):



means in minefield, it's roughly 0.05s precision, aka 20hz, which is waay too little. too bad. i also wonder about the big gap in the beginning.

i guess the browser vendors would be the people to write, instead of the HTML5 folks, though. who knows someone at mozilla?

for those who care, i uploaded the script to http://skrebbel.neuvostoliitto.nl/sync/. i'd be interested to hear how other browsers perform (i don't have those installed now). btw better wait a bit after opening the page so that the tune can buffer a bit.

tune is the excellent keith303 - she felt like, btw

FWIW, I've had the same resolution issues with the Flash-based SoundManager 2. As far as I can see right now, the best answer is to forget about syncing and use (new Date).getTime() instead...

gasman, to me, that means no demo in browser. first, you *want* to sync on audio (buffering, cpu full stuttering, whatever) and second i honestly kind of doubt the date getTime is much more precise.. is it?

skrebbel: exact same output on Firefox 3.7a1pre (2009-12-22 build). This is not fun :/. Maybe one can write to Mozilla developer's maillist?

getTime does seem to have millisecond precision - at least, when I used it on Antisocial it fixed the 'frame rate stuck at 10fps' issue.

Maybe the real answer is to use both of them, then - use date.getTime as the primary time source, but keep comparing against audio.currentTime and resync against that when it falls outside a certain tolerance. Ugh.

skrebbel: http://pastebin.com/m6942085c

looks really weird, although maybe my minefield is doing more samples than yours?

skrebbel, it's ok if you combine it with getTime and then linear-interpolate the diff you get to the next sampling point.

same issue with fmod.. time is not granular enough, so I did this and then a sanity check every 0.1 seconds to fix the synch.

hmm. sounds hacky, but i see how it could work, yes :-)
let's hack that up at some point.

i still dislike it though - i reckon it might be good enough for simple scene switches at the next part of the music, but i have the idea that if you really want to heavily sync to the drum section of the soundtrack, and there is one sound-stutter or so, the sanity check may get back close to it, but not spot-on.

but hey, if they can do it with Date, they should be able to do it with the sound! right? :-)

same reason is why you shouldnt use fmod btw :-D

this is mainly an issue in the first second or so, then you can almost ignore it unless you have issues with sampling rate of the sound or something.. assuming that the time reporting from the sound file is correct of course :)

... and next step would be to add a [shader][/shader] tag to pouet thus allowing to insert mini intro/demo in all bbs post, oneliner and... (why not) in avatars (as a small 16x16 intro)

skrebbel: will you be making the javascript port of the GNU Rocket client-stub, then? :)

if you port the network protocol to HTTP, sure!

In ShaderToy I'm using HTTPRequest to download the preset descriptions in xml, and the shaders in txt. So sending http with text, xml or simply binary data is very easy in JavaScript, apparently :)