1k Rose - How a 3D Rose was made in under 1K of javascript(romancortes.com)
romancortes.com
1k Rose - How a 3D Rose was made in under 1K of javascript
http://www.romancortes.com/blog/1k-rose/
39 comments
This is a nonsensical comparison. Considering that the language chosen requires fairly verbose code (everything from a minimum 14 bytes for a function declaration to longwinded API names, eg "fillStyle" that takes a string with another 7 bytes of decoration[1]), this is exactly what you'd expect. The challenges presented by the particular language and execution environment are a large part of the entire point of these exercises, they aren't a failing.
So, good work, you've declared all such competitions with languages less terse than assembly "scary" and no doubt a harbinger of some slippery slope. I hope there aren't any competitions with ISAs smaller than x86, or your world really might fall apart.
[1] 'rgb(,,)'. converting to hex might be a good size optimization there, actually, but it would still need a '#' and be a formatted string.
So, good work, you've declared all such competitions with languages less terse than assembly "scary" and no doubt a harbinger of some slippery slope. I hope there aren't any competitions with ISAs smaller than x86, or your world really might fall apart.
[1] 'rgb(,,)'. converting to hex might be a good size optimization there, actually, but it would still need a '#' and be a formatted string.
I don't find the comparison nonsensical (and I do ruby/coffeescript all day :-) - we have at least to take into consideration that the abstraction here came with an amazing cost nonetheless.
There is always meat in looking at the tradeoffs necessary for language/platform design, but the problem is that this particular argument is completely specious.
For instance, 256b.net demos aren't 256 bytes of assembly, they're 256 byte executables. If you download a demo, you can see that the ASM files, even with comments removed, are typically 1 or 2 kilobytes.
So now we have less functionality and worse performance in the same or half as much space, and that's still ignoring the fact that the mapping of source code bytes to actual instructions don't in any way resemble each other. If you included some measure of information density, you should probably be allowed at least another kilobyte of Javascript.
Then we get to functionality and performance. We all (hopefully) know the tradeoffs inherent in dynamic and JIT-compiled languages running in a browser that's trying its best to be an entire OS with all the intervening cruft between code and hardware that that implies. On the other hand, the 256b demos require DOSBox because they use extremely specific hacks, so should js1k demos be allowed to use one specific version of a browser, with (for instance) a known math and canvas object key order so it never has to refer to anything by name? Should it be allowed to use WebGL? The actual competition requires them to work in all "current browsers", including IE, but if you could get the WebGL syntax overhead to work in 1k, you could kick the crap out of the 256 byte demos...but what would that even mean?
In other words, it's an important consideration but this is a terrible comparison :)
For instance, 256b.net demos aren't 256 bytes of assembly, they're 256 byte executables. If you download a demo, you can see that the ASM files, even with comments removed, are typically 1 or 2 kilobytes.
So now we have less functionality and worse performance in the same or half as much space, and that's still ignoring the fact that the mapping of source code bytes to actual instructions don't in any way resemble each other. If you included some measure of information density, you should probably be allowed at least another kilobyte of Javascript.
Then we get to functionality and performance. We all (hopefully) know the tradeoffs inherent in dynamic and JIT-compiled languages running in a browser that's trying its best to be an entire OS with all the intervening cruft between code and hardware that that implies. On the other hand, the 256b demos require DOSBox because they use extremely specific hacks, so should js1k demos be allowed to use one specific version of a browser, with (for instance) a known math and canvas object key order so it never has to refer to anything by name? Should it be allowed to use WebGL? The actual competition requires them to work in all "current browsers", including IE, but if you could get the WebGL syntax overhead to work in 1k, you could kick the crap out of the 256 byte demos...but what would that even mean?
In other words, it's an important consideration but this is a terrible comparison :)
I'm not sure to understand your point (maybe I understood you in reverse, not sure!):
- "dosbox" 256b demos don't use extremely specific hacks: they use what was 10 to 15 years ago the standard platform (ie: DOS, Bios, VGA...); that will be the fate of today's javascript cool WebGL/Canvas stuff, including my own (see [1])
- the question about weither to use extensions or not (ie: WebGL, OpenGL, soundcards hardware...) is there for both assembly and javascript demos (see [2])
- basically IMO, unless you use WebGL, the performance of what you'll get is an order of magnitude or two slower than the equivalent in ASM so far on my tests at least
- please note that I'm not an ASM "freak": I tend to use ASM only for the small loops that require it (for instance, I released [3] which 95% Pascal and 5% asm roughly)
So I stand on my point: unless we rely on hardware and WebGL, we have lost several orders of magnitude of performance, by replacing a standard by another.
But please note I still enjoy these things coming out and I seriously hope WebGL et al. will get widespread usage!
[1] http://thbar.github.com/playground/
[2] http://www.geeks3d.com/20101126/demoscene-38644-mandelbulb-i... 1k intro of an OpenGL Mandelbrot set in 3D coded in assembly
[3] http://www.pouet.net/prod.php?which=17268 1995 demo
- "dosbox" 256b demos don't use extremely specific hacks: they use what was 10 to 15 years ago the standard platform (ie: DOS, Bios, VGA...); that will be the fate of today's javascript cool WebGL/Canvas stuff, including my own (see [1])
- the question about weither to use extensions or not (ie: WebGL, OpenGL, soundcards hardware...) is there for both assembly and javascript demos (see [2])
- basically IMO, unless you use WebGL, the performance of what you'll get is an order of magnitude or two slower than the equivalent in ASM so far on my tests at least
- please note that I'm not an ASM "freak": I tend to use ASM only for the small loops that require it (for instance, I released [3] which 95% Pascal and 5% asm roughly)
So I stand on my point: unless we rely on hardware and WebGL, we have lost several orders of magnitude of performance, by replacing a standard by another.
But please note I still enjoy these things coming out and I seriously hope WebGL et al. will get widespread usage!
[1] http://thbar.github.com/playground/
[2] http://www.geeks3d.com/20101126/demoscene-38644-mandelbulb-i... 1k intro of an OpenGL Mandelbrot set in 3D coded in assembly
[3] http://www.pouet.net/prod.php?which=17268 1995 demo
I don't know where you get "less functionality and worse performance in the same or half as much space"- the point of the link was to show that 256 byte demos actually demonstrate more functionality. What makes you think you have more functionality in 1k of JS?
As you said, "if you could get the WebGL syntax overhead to work in 1k, you could kick the crap out of the 256 byte demos." I believe that's exactly the point. Even if there is all this theoretical power in our JS environments, we aren't using our environment nearly as efficiently as the 256 byte demos used theirs.
It's also worth noting that those 256b demos ran on the standard platforms of their day, which yes, required MS-DOS, but then could run on any intel compatible processor, with any standard motherboard, with any standard bios, with any standard video card. And I would be surprised if they actually called into MS-DOS at all, and didn't just talk to the hardware directly.
As you said, "if you could get the WebGL syntax overhead to work in 1k, you could kick the crap out of the 256 byte demos." I believe that's exactly the point. Even if there is all this theoretical power in our JS environments, we aren't using our environment nearly as efficiently as the 256 byte demos used theirs.
It's also worth noting that those 256b demos ran on the standard platforms of their day, which yes, required MS-DOS, but then could run on any intel compatible processor, with any standard motherboard, with any standard bios, with any standard video card. And I would be surprised if they actually called into MS-DOS at all, and didn't just talk to the hardware directly.
None of these demo binaries will actually run on my OS, so maybe the extra 768 bytes are a fair tradeoff for abstracting away the platform.
These binaries will run on your OS if you install the corresponding runtime (DosBox or similar actually).
Interestingly this runtime happens to be way smaller (2MB) than Firefox, Chrome or even Safari.
Interestingly this runtime happens to be way smaller (2MB) than Firefox, Chrome or even Safari.
now we just need to write google search, google maps, facebook, twitter etc for dosbox, some type of linking mechanism, have it installed on all computer by default and we are sorted!
Most demo competitions do not assume you'll require internet connectivity at all, so that won't be required ;)
I understand your irony and do agree that using standards of today is expected.
This doesn't remove any validity to the OP point that what we use today (apart from WebGL or other hardware accelerated code) is several orders of magnitude behind what was already there 10 to 15 years ago.
I do hope though that we'll see more and more widespread/standard techniques to grab back a bit of speed there without only counting on Moore's law :)
I understand your irony and do agree that using standards of today is expected.
This doesn't remove any validity to the OP point that what we use today (apart from WebGL or other hardware accelerated code) is several orders of magnitude behind what was already there 10 to 15 years ago.
I do hope though that we'll see more and more widespread/standard techniques to grab back a bit of speed there without only counting on Moore's law :)
There's DosBox for the iPhone now?
If you're not living in Apple's wallen garden, it seems so:
http://litchie.com/blog/?page_id=123
http://litchie.com/blog/?page_id=123
I'm sure the assembly code is shorter than the JavaScript code, right? Cause it makes no sense comparing the compiled/minified versions...
Pouet [1] also has some has a great archive of demos.
[1] http://www.pouet.net/
[1] http://www.pouet.net/
Meta comment: This is a perfect hacker news submission. I started reading hacker news because of articles like this.
Engineering is about constraints. Any damned fool can build a 10km suspension bridge given enough unobtanium and micraculum. That's cheating.
You can get quite interesting and very creative solutions when you apply artificial constraints.
This stuff happens in the real-world all the time, especially in consumer electronics. I've had to do video-rate unpacking of samples that were aligned on really nasty boundaries. Far cheaper (in this instance) to do it in software . . . so we got clever.
You can get quite interesting and very creative solutions when you apply artificial constraints.
This stuff happens in the real-world all the time, especially in consumer electronics. I've had to do video-rate unpacking of samples that were aligned on really nasty boundaries. Far cheaper (in this instance) to do it in software . . . so we got clever.
Meta comment: For you maybe. I found it rather boring and skimmed it after the first para. It's about javascript to begin with ;) And looks a bit poo.
I prefer startup news and programming advances. That's not really programming news, it's just a rather dull writeup about how someone made a picture of a rose, something I have no desire to do.
And we've been able to do it for decades. Apart from some reason now HTML5 has a canvas a lot of people seem to have the need to reinvent the wheel.
My point, we're all different, there's no such thing as perfect. These kind of articles are fun once in a while but HN would be fairly useless if that kind of article was all that dominated it.
I prefer startup news and programming advances. That's not really programming news, it's just a rather dull writeup about how someone made a picture of a rose, something I have no desire to do.
And we've been able to do it for decades. Apart from some reason now HTML5 has a canvas a lot of people seem to have the need to reinvent the wheel.
My point, we're all different, there's no such thing as perfect. These kind of articles are fun once in a while but HN would be fairly useless if that kind of article was all that dominated it.
Sounds like you're unclear on the concept of "hacker" and "hack". Remember, if people never reinvented the wheel, we'd still be rolling our carts around on discs made of three pieces of wood.
I remember this site because of another 1k js competition, result of which was a Christmas Tree -- http://www.romancortes.com/blog/how-i-did-the-1kb-christmas-...
That's pretty nice. I wonder if you could squeeze my <canvas> font rendering engine under 1K? The base64-encoded PNG font is 635 bytes, but you could probably use the 4×6 font by Janne Kujala to cut that down to ≈512 bytes.
http://canonical.org/~kragen/sw/dofonts.html
Edit: yes; a 1023-byte version, specialized for the 4×6 font, is now linked to from that page. The 1023 bytes includes the entire HTML file, including both the font and the code to render it.
http://canonical.org/~kragen/sw/dofonts.html
Edit: yes; a 1023-byte version, specialized for the 4×6 font, is now linked to from that page. The 1023 bytes includes the entire HTML file, including both the font and the code to render it.
1k is impressive as a coding feat, but I'm not sure of the practical application of this - i.e., I'm less impressed with 1k of code when my CPU meter gets into the red zone - and stays there.
My tinfoil-hat conspiracy theory is that the Canvas element was spec'ed into HTML5 by CPU fan manufacturers.
My tinfoil-hat conspiracy theory is that the Canvas element was spec'ed into HTML5 by CPU fan manufacturers.
>but I'm not sure of the practical application of this - i.e., I'm less impressed with 1k of code when my CPU meter gets into the red zone - and stays there.
There was a time when algorithms for decoding an audio file put your CPU in the red, yet we found many applications for them :)
There was a time when algorithms for decoding an audio file put your CPU in the red, yet we found many applications for them :)
The point of using monte carlo is to fit it under 1K of Javascript in exchange for CPU time.
It's very educational to see things simplified to their most basic essence, and code golf is one game we can play that forces us to do that.
Same rant as Steve Jobs claimed why Flash should die years ago.
I got lot of downvots on HN previously by saying HTML5 was the exact same shit as Flash, what's better is that there is no way to block canvas animation ads yet.
I got lot of downvots on HN previously by saying HTML5 was the exact same shit as Flash, what's better is that there is no way to block canvas animation ads yet.
The only reason this demo uses a lot of CPU is because it uses a lot of tricks to stay under 1K. Any JS guy could get the same result with far less CPU usage. Also, HTML5 has nothing to do with CPU usage. JavaScript performance (which is quite a bit better than Flash, even with SVG and/or Canvas manipulations) is the thing that actually uses CPU.
It's no help that JS is faster than AS for now, AS used to be much faster than contemporary JS, but how about display ads with dozens of Flash embedded? Fast is only relative.
Think about dozens of canvas animation ads embedded with Javascript. It will be as shitty as Flash. I'll switch to the first browser that allows me to selectively disable all HTML5 crap.
Think about dozens of canvas animation ads embedded with Javascript. It will be as shitty as Flash. I'll switch to the first browser that allows me to selectively disable all HTML5 crap.
This a great piece of code but the author does one thing that has gets my goat.
A lot of these cutting edge HTML5/WebGL demos are put on a separate page from the thing explaining it. One of the reasons we have this technology is so we can put this stuff right there on the the page, seamlessly available to the user.
Sometimes it makes sense for performance or aesthetic reasons to have it separate, but certainly in many cases including this one it doesn't.
Keep a separate demo page sure, so people can link directly to your demo. But have it right there in your blog post as well, personally I think it adds to the wow factor!
A lot of these cutting edge HTML5/WebGL demos are put on a separate page from the thing explaining it. One of the reasons we have this technology is so we can put this stuff right there on the the page, seamlessly available to the user.
Sometimes it makes sense for performance or aesthetic reasons to have it separate, but certainly in many cases including this one it doesn't.
Keep a separate demo page sure, so people can link directly to your demo. But have it right there in your blog post as well, personally I think it adds to the wow factor!
I'd guess that whatever blogging software that was used here (WordPress?) doesn't make it easy to insert arbitrary JavaScript. Too easy to create a security loophole, especially on a third-party hosted blog site.
The demo is very CPU intensive to the point that the fan on my MBP comes on shortly after starting it. If I'd stumbled onto it with my wife's BlackBerry it probably would have caught on fire. I think he chose correctly in leaving the script off of the blog page.
my core i5 CPU performance on Sony VAIO doesn't go up much (around 26%). But I don't have problems with demo being seperated as long as it is available and easily accessible
Presumbably because it is running in a single thread and s0 only using 25% of your 4 cores.
Beautiful. Lots of interesting techniques detailed too that could be useful. I'm a big complainer, but even I'm having trouble complaining about it not being practical. Nice.
Now I know why I should have taken math in school :)
This is very impressive. This is sooo far removed from my daily job as "business application" developer, which makes it the more interesting. Thanks for posting.
I'm giving a dozen of 3d flower to my sweetheart on Vday.
awesome piece of hacking! great job
And guess what. The 256 bytes demos are nicer and more complete than the js1k! They've sound, better 3d effects, etc.. plus they actually run those nicer demos on much, much older hardware without lagging (js demos use quite a bit of cpu even on modern hardware)
Four times as much space, not nearly as good. Show how much went into "language abstraction". Scary!
Reference: http://www.256bytes.net/