The real version of this, which is actually 1021 bytes, is here: http://www.p01.org/MONOSPACE/monospace.htm. It uses the very clever trick of compressing the JavaScript code as the pixels of a PNG image (which uses Deflate internally), then including the page itself in an <img> tag and decompressing the JS code from the resulting pixels.
Unfortunately, the developer made a bit of a mistake when uploading this file: it appears to have been uploaded in ASCII mode rather than binary mode, meaning that all the 0x0d (CR) bytes in the file have gone missing (an artifact of the standard "CRLF -> LF" translation performed in text mode uploads). Therefore, it doesn't work: all you get to see is a screenful of binary junk. (Author, if you're seeing this - it's hopefully an easy fix!)
But! Once you've jumped through those hoops, you can appreciate the real ingenuity that manages to pack this demo into a cool 1021 bytes (the compatible version that most of you would have seen is much larger, at 2338 bytes).
> but fails on newer Chrome because of click-to-play audio.
In these cases, you can also refresh and rapid click, it gets registered as a user gesture and the audio is allowed to start. Maybe try two-three times.
Ah, I wondered why I was getting junk when I clicked that link, thank you for uploading (still falls over for me when I accidentally opened it using FF, but no harm done)
Hi, my bad. I forgot to set the Transfert Type to binary on my new laptop :p
Hope you enjoy MONOSPACE anyhow. I am pretty happy with how it turned out. I believe I managed to nudge a little the state of art of what type of camera work is possible in 1kb demos.
Because the rest of the commentors in this thread seem to not be reading the article, there's a performance issue in Firefox due to the following unresolved bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1190398
The link to the demo comes before the warning to firefox, don't shame commenters who chose to see the content at discussion first before reading below the fold.
While it says that "[...] you need to use a Chromium or Webkit browser to enjoy MONOSPACE live." (emphasis mine), it does not say "DO NOT USE FIREFOX UNDER ANY CIRCUMSTANCES, it will mess up your device for minutes" anywhere.
We saw so many (warranted or unwarranted) "Best viewed with Chrome"-statements on the web already that we became desensitized to it years ago.
No, please don't add derision to HN threads. When someone else is wrong, it's enough to supply correct information. That enhances the thread without damaging the commons.
I imagine that accidental unfair scheduling is to blame here: that the audio processor is keeping things busy in such a way that Firefox isn’t getting its “hey, this tab is closed” message through to kill the event loop. This is definitely a bug in Firefox, and it appears to be consistent across platforms (I’m on Windows, you’re on macOS, someone else is mentioning Android). The patch to fix this is likely to be quite small.
I do notice, that PulseAudio shows me that the audio stream from Firefox is labelled "AudioCallbackDriver", which is unusual: most Firefox audio streams are labelled "AudioStream". I think this is a little-tested feature in Firefox at this point. Somehow it also manages to activate the speech (espeak) dispatcher too.
With FF mobile on Android I still had ongoing sound after closing
FF completely (at least as far as I know) and I had to reboot my phone.
It's quite concerning that websites are able to do this. While
it is the browsers fault to support all that javascript crap I
think this is also a bug in Android.
> It's quite concerning that websites are able to do this.
They've been able to do this for a long time and for valid reasons (think of a PWA audio player, like a podcast app).
Unfortunately this used to get abused very often. I remember seeing bugs in ads that would: stop your Spotify playback (due to how audio apis work on phones), and continue playing in background (again, this is a feature, but often abused). iOS is much better in that regard, with stricter autoplay policies, etc...
What's super concerning is that audio worked even when the page was closed. Once I kill the tab, the entire process should be killed too.
So yeah, it's possible that it's just an FF bug purely because being able to play audio in BG is a valid feature BUT there should be no audio when the tab has been killed. My guess is that from the OS perspective, the tab is still running.
My another guess is that it has something to do with some clever techniques regarding reducing the app size.
Pretty easy to not properly clean up resources when you share processes between tabs. Firefox does that, chrome doesn't, so it properly cleans up in chrome since it quits the process.
If you wonder why it plays for 1-2 minutes after the code stopped sending to the sound card, you always write sound in batches to the sound card so he likely wrote the whole 1-2 minutes in one big batch.
It completely locked up Firefox on Ubuntu 20.04, rendering a frame and making a single beep sound about once per second. Had to close the browser and force kill some processes to get the TTS to stop.
I had a beeping issue on Firefox 81 running on Windows 10. The weird thing was, the beeping noise continued even after I closed Firefox. There were some OS updates pending installation, so I just chose to reboot/install instead of troubleshoot further.
This won the Assembly 2020 1kb demo competition. There are some truly mind-blowing entries, including the 2nd place entry which features multiple types of spaceships and a stargate, with audio.
For people not able (or willing) to run the demo themselves, it can also be seen on YouTube in a 3 minute clip [0]. It keeps amazing me how much people can accomplish with less than a KB of code.
Not being willfully obtuse, but there's a lot more than a KB of code on that YouTube page. To me it feels like the difference between watching a movie on 35mm vs DVD.
I expected the comment to go on about how much code in the support libraries is needed to support this. It's not a 512 byte boot sector intro, far from it.
My "big idea" was to use the speech synthesis API (I still liked how I used it)... but I thought it was funny, because it felt like cheating to say "1K" when it relied on so many megabytes of APIs!
Nah, of course not! It's fair game (otherwise you'd first have to invent the universe). It was just the speech synth API was pretty new when I did that, so it felt sneaky ;)
Also - p01, you are a hero to us all. MONOSPACE is beautiful, congrats on the Assembly win!
The main part of the source code is the last `for(...)` loop that updates the sound buffer, and draws the text.
There was not much inspiration :p I needed something simple enough to be fairly compact and sound melodic.
So I used a chord of 4 notes, played them at different speed and octaves. The lead using a sinus oscillator to get nice pure tones, a deeper sound 4x slower with a pulse oscillator to get more edgy sound, the deepest sound 16x slower with a sawtooth to get a gritty bass. Layered with the perspective scaling of the dots to get something bleeps in synch with the visuals.
And when I tried to run it in Chrome, my laptop (MacBook Air 2015 early) completely froze up after a few seconds. Probably you should not open this in older devices at all.
I'm not the author but I've done this before [1], so here's what I can quickly make up (EDIT: updated using informations gathered from p01's comment below):
// c is a canvas created outside
d = [ // 2 times audio frequencies used, I think
2280,
1280,
1520,
c.width = 1920,
// d[4] is not used, not sure why this stmt was stuffed into d
// required to hide the PNG bootstrap; the bare minimum would be `0'`, probably this compresses better though?
document.body.style.font = "0px MONOSPACE"
],
g = new AudioContext,
o = g.createScriptProcessor(4096,
// clears the margin and initializes vars
// (t: time in seconds, n: last t when speak occurred)
document.body.style.margin = t = n = 0,
1),
o.connect(g.destination),
o.onaudioprocess = o => { // periodically called to fill the audio buffer, used in place of setInterval
o = o.outputBuffer.getChannelData(
e = Math.sin(
t / 16 % 1, // this is the only arg to sin, others are for shoving exprs into a single stmt
m = Math.sin(Math.min(1, y = t / 128) * Math.PI) ** .5 + .1,
c.height = 1080, // setting canvas.width/height clears the canvas
b.shadowOffsetY = 32420,
// results in `radial-gradient(#222,black` or so, reinterpreting decimal number as hex, the last `)` is not required
c.style.background = "radial-gradient(#" + [222, 222, 222, 222, 155, 155, 102, 102][t / 16 & 7] + ",black",
b.font = "920 32px MONOSPACE",
// each function determines the dot size for 16 seconds, also sometimes used as a display text
f = [
(x, y, t) => x / y * 2 - t,
(x, y, t) => (x ** 2 + y ** 2) ** .5 - t,
(x, y, t) => x / 4 ^ y / 4 - t,
(x, y, t) => y % x - t
][t / 16 & 3],
// determines a string to print and speaks it every 16 second
// the inner [...][t/16|0] can return undefined, which gets coerced to an empty string by `""+[...]`
u = "" + [[, f, f, " CAN YOU HEAR ME", f, f, , "MONOSPACE", "THE END"][t / 16 | 0]],
t > n && speechSynthesis.speak(new SpeechSynthesisUtterance(u, n += 16)))
);
for (i = 0; 4096 > 4 * i; i++) // for each dot; `4096>4*i` probably compresses better than `1024>i`
// calculate the dot size and mix with the radius in the previous frame for easing
// f and g are objects (function and AudioContext), so can be abused as a generic store
g[i] = r = (f(x = 16 - i % 32, a = 16 - (i / 32 | 0), t) / 2 & 1) + (g[i] || 0) / 2,
x += o[0] / 4 + 4 * (1 - m ** .3) * Math.sin(i + t + 8),
a += o[64] / 4 + 4 * (1 - m ** .3) * Math.sin(i + t),
h = x * Math.sin(y * 2 + 8) + a * Math.sin(y * 2),
p = 4096 / (m * 32 + 4 * h * Math.sin(e) + t % 16),
b.beginPath(f[i] = r / p),
b.arc(h * Math.sin(e + 8) * p + 1280,
x * Math.sin(y * 2) * p - a * Math.sin(y * 2 + 8) * p - 31920,
p > 0 && p / (2 + 32 - r * 16),
0,
8), // anything larger than `2*Math.PI` will draw a full circle
b.shadowBlur = o[0] ** 2 * 32 + 32 - m * 32 + 4 + h * h / 2,
// `[a,b,c]` coerces into a string `a,b,c`
b.shadowColor = "hsl(" + [f(x, y, t) & 2 ? t - a * 8 : 180, (t & 64) * m + "%", (t & 64) * m + "%"],
b.fill();
b.shadowBlur = o[0] ** 2 * 32,
b.shadowColor = "#fee";
for (i = 0; 4096 > i; i++) // generate each sample, also prints the glitched text
o[i] = o[i] / 2 + (
(
Math.sin(t * d[t / [4, 4, 4, 4, 1/4, 1/4, 16, 4][t / 16 & 7] & 3] * Math.PI) * 8 +
(t * d[t / 8 & 3] / 2 & 6) + t * d[t / 16 & 3] / 4 % 6
) / 64 + f[i / 4 | 0] // f[0..1023] is the visual data, reused as a noise
) * m,
// prints at most 64 characters of u;
// 0th and 64th samples (o[0] & o[64]) of the prev/current buffer act as x/y jitter,
// first 64 samples also displaces the char offset for the glitched text effect
64 > i & t % 16 * 6 > i &&
b.fillText([u[i + (o[i] * 2 & 1)]], // again, [undefined] coerces into an empty string
i % 9 * 32 + o[0] * 16 + 180,
(i / 9 | 0) * 64 + o[64] * 16 - t - 31920),
t += 1 / g.sampleRate // so t increments by 1 per second
}
While the obfuscation itself is fairly standard, I think the real magic here is the carefully selected motion and jitters---which I can't easily figure out from a glance.
> Do you work directly in the minified code, or do you create the demo in normal code first then look for ways to minimize it?
Also, in my experience you end up structuring everything so that it can be easily minifiable (by hand or using something like terser-online [2]). This doesn't necessarily mean that the code is unreadable (variables can be renamed, statements can be converted to comma expressions and so on), but the resulting code would be very unorthodox. See the source code of my JS1024 entry for example.
Thanks for the expansion and comments! On your project, I noticed the comments were about 5 times longer than the source code :) - so that makes sense how to work with it.
I do not use any minifier. I minify the code by hand, and typically prototype ideas and performance tests in normal non-minified code. Once the main idea and approach are settled, I minify the code by hand and keep an eye on the heatmap of the DEFLATE stream to match the 1024 bytes limit.
MONOSPACE took ~4months on an off to create, tallying ~60h of work. You know 2020 + trying to balance work & family, and remain sane these days.
As I said on my site, the Audio and Visuals feed each other to make the background noise based on each dot, and the camera shake based on the Audio. That way I keep the Audio & Visuals are perfectly in synch, for free ;)
For the X & Y camera shake, I use the values 0 and 64 from the Audio buffer. The 64 is because this is the maximum number of characters rendered by the Text writer which happens in the loop updating the Audio buffer. Using something lower than the 64th value would make the last characters of the Text shake in a different way than the rest.
He is very talented and was nice enough to implement a couple of features to help with this kind of productions when I was working on BLCK4777 - https://www.p01.org/BLCK4777
I made 100s of creative projects and failed experiences before getting there. Don't get scared by that number. All it means, is that it is possible to do in 60h. Some would take 600, others 20.
I threw that number away to put it in context with the 4 months since the first prototype. I could only work from time to time. Some times not touching the code at all for weeks.
Here are other visual JS Demos created by p01 and others using just 140 characters of code (or less!): https://www.dwitter.net/top/year
Dwitter is a collection of amazing short JavaScript codes that can be explored, remixed and voted "awesome". It works like a living portfolio of short code/graphic creations where one can learn by exploring other people's code.
To everyone running it in Firefox:
"Unfortunately, Mozilla still hasn't fixed the performance bug 1190398 around ShadowBlur, filled for BLCK4777 5 years ago.
Therefore you need to use a Chromium or Webkit browser to enjoy MONOSPACE live."
I value p01's contribution to the world of optimized code using JavaScript. He is doing this for many years now, and he still keeps pushing the boundaries with creative optimization techniques.
This is so cool!
It's amusing to me that I saw this about 5 minutes after I received a pop up notice from Adobe advising me to uninstall Flash as it'll be EoL'd in a few months.
I appreciate they're entirely different beasts, but the Monospace demo here definitely IS creative.
oh wow, I thought the video was an artistic edit of the program. it was frustrating me because just wanted to see the program, not a filtered, edited trailer. then I realized that's the program. this is really mindblowing, the creator is definitely some kind of genius
People love to bash developers who put up "Chrome recommended" banners, dismissing them as lazy, but when making games and such there are real issues that are impossible to circumvent. This bug is a prime example of that.
The point is that if shadowBlur performed poorly in Chrome, people would either find a way to circumvent it, or wouldn't use it. Chrome gets a free pass for its failings, while Firefox attracts "Chrome Preferred" banners, and this is based on market share rather than software quality.
For many aspects of web development you're absolutely right, but don't forget that this is a demo. It's a showcase of talent rather than an attempt to write something accessible in every browser.
People have shown demos at parties that require a specific graphics card and a specific build of a driver in the past; something that requires a specific class of browser engine is probably OK.
I'm dealing with a similar issue in Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=925025) and there's simply no way to do what I want without using a blur filter. So yes, if it didn't work in Chrome my game wouldn't exist but not sure how that is of any comfort to anyone.
That sucks! From my knowledge of browser-based games, though, I think a lot of people are using webgl, where the solution would be to write a blur shader. If your game was written in a world where Firefox had 90% market share, you'd be more likely to go straight for webgl.
I sympathize with developers dealing with browser bugs, but a majority of "Chrome recommended" banners are not. For many cases they are used as a cheap excuse not to care about or even deter non-Chrome browsers at all, even when they do work mostly or completely fine. Demos, in comparison, tend to have much narrower requirements due to various constraints (many D3D demos only worked with specific graphic cards at least in the initial release, for example).
I agree but the last time the pitchforks went out on HN regarding this was for a game, so not very different from demos.
The issue I'm personally dealing with is for a game revolving around a feature that's only working properly in Chrome (see sibling comment for link to bugzilla). I've tried solutions for mitigating it but since I'm just one guy I've basically given up for now and have resorted to a warning for Firefox users.
In all honesty I don't see how it's different from only releasing a game on Xbox and not PlayStation.
I guess that was shapez.io [1]? The situation around WebRender is pretty unfortunate, as AFAIK it is blocked by the compatibility issue in macOS. I have played it in Windows Firefox just fine though.
Anyway, I think it's more about the wording: it's very fine that the developer hasn't tested much in other browsers (not every developer has resources to do so, sure), but saying a certain browser is required or recommended implies that the issue is something to do with that browser (which might or might not be the case). Shapez.io also doesn't support macOS in its standalone build, but the statement on that was more amicable and honest; I wish the developer did the same for non-Chrome browsers as well.
> In all honesty I don't see how it's different from only releasing a game on Xbox and not PlayStation.
Consoles generally have much different requirements (hardware, vendor integration etc.) than PC games. For me it's more like Steam vs. Epic Store which I found pretty frustrating as a gamer.
That's a nonsense statement. There is no technical achievement, it's no breakthrough in any relevant technical sense. Sorry to get technical, but you called it.
I'm not dismissing the demo, mind. It's a great feat of engineering and its main achievement, that is creative, surely thrives from a technical esthetic.
Using system libraries has to be put into perspective, for sure. The common wisdom (in sizecoding at least) is that creativity thrives from constraints. Necessarily then, one has to be aware of the constraints.
One might say having to write in .js is extreme masochism, so the criticizm about .dlls is just one side of the equation. Browser bugs and all that. no, thanks.
1021 bytes of JS, and 6 million lines of browser code.
FTFY
These modern demos, using OpenGL and now the whole web browser that are mimicking the rules and sentiment of old 8-bit machines demos, or even later DOS demos, are not the same thing.
Oh, this demo has text being spoken ... how was it done ... checks source code ... SpeechSynthesisUtterance . Yeah right, 1021 bytes. :)
I'm getting the same issues as all of the other Firefox users. Guess I'll never watch it, because I have a hard policy of never, ever installing Chrome malware on my personal computer.
Maybe the title should be changed to "Chrome demo"?
The video was lost on me whereas the demo made me think how cool it was.
I expected the video to explain what it was but alas no. The video is just the demo running. The demo was brilliant, but, the video of the demo, although practically the same had me wondering quite negative thoughts. I wasn't thinking 'how do they do that', I was thinking 'this is a bit pretentious'. It is amazing the difference context makes.
> I wasn't thinking 'how do they do that', I was thinking 'this is a bit pretentious'.
Everyone experiences things differently. Some people see a sports car and think, "Wow, I wonder how it works?" Others, "Wow, I hate that colour." Doesn't really matter.
Totally agree. I can't watch the demo run because I'm on Firefox, and I have no desire to watch a video for the reasons you described. And the world keeps spinning, I guess.
Unfortunately, the developer made a bit of a mistake when uploading this file: it appears to have been uploaded in ASCII mode rather than binary mode, meaning that all the 0x0d (CR) bytes in the file have gone missing (an artifact of the standard "CRLF -> LF" translation performed in text mode uploads). Therefore, it doesn't work: all you get to see is a screenful of binary junk. (Author, if you're seeing this - it's hopefully an easy fix!)
I've uploaded the correct version (obtained from http://www.p01.org/MONOSPACE/monospace.zip) here: https://robertxiao.ca/misc/monospace.htm. This works out-of-the-box on Firefox (modulo being really slow, thanks to https://bugzilla.mozilla.org/show_bug.cgi?id=1190398), but fails on newer Chrome because of click-to-play audio. You'll have to "allow" my site under chrome://settings/content/sound, then refresh.
But! Once you've jumped through those hoops, you can appreciate the real ingenuity that manages to pack this demo into a cool 1021 bytes (the compatible version that most of you would have seen is much larger, at 2338 bytes).