On my (android) phone, performance is best in landscape
-
-
-
The file is actually one wasm binary file, with just "<!--" added to the start, and the javascript bootstrap embedded as constant data
Prikaži ovu nit -
The graphics and audio are rendered with WebGL(1) shaders. The challenge for me was how to bind all the needed functions while staying "in budget" (<4KB) but still with broad compatibility
Prikaži ovu nit -
Each of the 4096 rings is a quad instance, positioned in 3D space by the vertex shader. Then in the fragment shader, a local single torus distance field is ray marched for a few steps. Depth testing is on, and pixels that don't hit a surface are discarded.
Prikaži ovu nit -
The audio ("music") is also rendered in a fragment shader, with one pixel per sample, using additive synthesis with about 500 sin waves for left and right channels. Output float value is coded into the 4x8bit RGBA and cast back to float32 on host side, then into a WebAudio buffer
Prikaži ovu nit -
The version of WebAssembly widely available today in most browsers is limited to being able to call a list of javascript functions you give it at load time, with only numbers as parameters & returns - it cannot call arbitrary Web functions (such as WebGL or WebAudio) directly
Prikaži ovu nit -
To avoid needing JS binding functions for all the Web APIs, I used the JS function Reflect.ownKeys() on API classes to enumerate all the available functions, and extract the ones I needed dynamically based on a pre-computed (12-bit) hash - then using JS fn apply() to call them
Prikaži ovu nit -
The (text) shader code is stored with simple dictionary-based compression of keywords. But the rest of the code is not compressed. To keep code density high, I used rust to write a binary code runtime based on 4-bit opcodes and args that manipulate a JS-side stack
Prikaži ovu nit -
Some annoyances and challenges: - Android chrome much faster fullscreen - Fullscreen & WebAudio only work if the user interacts. So there has to be an initial state that requires a click/press - Safari WebAudio is still behind webkit prefix and has slightly different behaviour
Prikaži ovu nit -
Balancing the audio work load was also a problem. There are two 0.2s stereo audio buffers used alternately. This means every few frames there is extra GPU rendering work to do. When the scene gets full (many rings near camera), lighter GPUs struggle to render smoothly
Prikaži ovu nit
Kraj razgovora
Novi razgovor -
Čini se da učitavanje traje već neko vrijeme.
Twitter je možda preopterećen ili ima kratkotrajnih poteškoća u radu. Pokušajte ponovno ili potražite dodatne informacije u odjeljku Status Twittera.