The visual trickery is fun. I hadn't noticed that only the centre lines on the road glow until reading that, nor had I noticed that the street lights don't actually have a thin line linking the pole and the light.
Wow. I can make sense of a little bit of the original source, but I wonder more how RegPack [0] works to compress it into that final submission!
As a side note: I'm in college now and looking to propose an independent study on compression. Any suggested readings or algorithms I should look into?
For lossless compression, start out by reading up on run length encoding, which is about as simple as it gets. Then there's DEFLATE, which is what's behind gzip. You'll also want to read up on Huffman coding and arithmetic coding. One of the newer ideas in lossless compression is "context mixing", which is definitely worth reading up on. The Burrows–Wheeler transform is pretty fascinating, albeit slow, so you might want to read about that as well.
Lossy compression (which RegPack is actually an example of), typically involves lossless compression plus a preprocessing step to discard information so that the lossless compressor can do a better job.
The techniques for discarding information vary based on application. For images and audio, the most successful techniques tend to involve working in frequency space, so you'll want to read up on the FFT and related transforms.
For code compression, you have different constraints when discarding information because you have to produce a program with identical output to the original. Simple techniques involve removing comments and renaming variables to have shorter names. More advanced techniques involve more complex transformations of the AST, including language-specific tricks like wrapping javascript in a "with(Math){}" block.
Some of the other demo's quickly makes my Macbook Pro's fan make noise. This cute 3d demo can go on forever without any noise. And it even has reflection and (fake) shadows.
I really enjoyed playing around with the winner (http://js1k.com/2014-dragons/demo/1903), but I'm somehow surprised Highway At Night didn't win. Is there something about the winner's implementation that's particularly amazing?
Image the '0' walking left, because it as to follow the =, everything it touches on that path, turns to zero and disappears. What are you left with? Just '0'.
This demo gives some ideas about how the human brain manages to remember events. With just a few lines of code, containing very little information, it generates something we perceive as a very detailed record of a highway trip at night. Even if we don't know exactly what tricks the human brain uses to compress information about places and events, this demo let's us imagine how some of it might be done.
The human brain is a master at recognising and codifying geometric 3d shapes. The developer who created this is a master at coding geometric shapes and transitions in javascript as well.
How can the human brain remember hours of highway trips in basically 3 pounds of fat without using some tricks to convert the information in to geometric 3d shapes? The developer who created this demo also know how to do it the other way round, he can write javascript that generate simple geometric shapes and animated transitions in javascript that generates a pretty good rendition of a highway trip at night.
I doubt that (all) humans think in javascript :P Im sure the brain has its tricks, but they dont need to have something in common with the ones used here.
I wonder what Kolmogorov Complexity this program has. Obviously <= 1023.
How does Kolmogorov Complexity deal with the fact that you're specifying that number within a certain execution context (in this case JavaScript)? Otherwise you could simply reduce the program to a single bit and have an interpreter that includes the original program as a primitive. This program without the libraries that it accesses would be a lot larger than it is.
Also, shouldn't the number be expressed in bits rather than bytes?
There's a lot of good science on this exact issue, dating back to the 50s/60s (good entry point: the Nobel Prize-awarded work of Hubel & Wiesel). The brain does indeed perform many, many passes of feature extraction and reduction. Essentially, this process starts at synapse one -- retinal inputs, for instance, are immediately split into multiple channels coding different features of the incredibly rich feature space impinging on your photoreceptors. The higher up you go, the more diverse the features and the higher their level of complexity.
There's no need for guesswork! Just dive into the literature.
I think you may have the memory issue the wrong way round.
Human memory is built precisely around remembering geographic locations, human faces and images[1]. The 'have I seen this before feeling' you get is your brain trying to match the demo location to memories ( my conjecture anyway )
this was really beautiful. I almost blurted out it was art but then I was forced to remember we can't call computer generated things art by some hidden rule.
A great deal of people don't see what can be distilled down to pure logic and math as being a valid form of art. They believe there is something beyond the physical world which art can reach out and touch. They are incorrect and most would back down immediately if they were talking about it in person.
A big part of it is framing. If you frame something as a tech demo, that's how it's going to be recieved. 'The Art World' does seem reasonably open to stuff like this, but you really have to go out of your way to make sure people know "hey this is art, please interpret it as an Artwork, here's a chunk of text explaining the conceptual backdrop for this piece, here's how it fits into my wider practice, thank you". But with that perhaps you would risk alienating a big chunk of the HN crowd.
I've seen art exhibits that essentially were three LCD screens which displayed a video/computer simulation of paint dripping and mixing. I believe the entry to the art world is just gated enough that who gets to display their "artwork" is much more a question of connections and politics than raw talent.
Huh? Of course it is art. Look at all the random graphics and movement coming together to form a 3D street animation.
1.) people can take away a lot from the code and animation which makes it a great example of a new art form. The street scene in oarticular conjures up emotions.
2.) just because a group of the Internet does not understand or appreciate art in all its forms, doesn't mean anything at all except they are ignorant when it comes to identifying artwork.
Now, I remember that in a recent discussion there was some arguing on Firefox new JS engine whose results were benchmarked at a higher position than Chroome's.
So please try this on Firefox and then on Chroome and see the difference. Firefox is not yet there, sadly.
As a Firefox-user (on Linux!) who don't feel like installing Google's closed-source spyware-browser, would you be shocked to hear me chip in and say: I don't care.
I don't need my browser to drive full-screen 3D games & demos on my current-laptop hardware. That's not what I (or anyone else) is currently using their browser for. Maybe 5 years from now things will have changed. Maybe then truly everything will be in the browser. That's fine, but by then I will have bothered buying a newer, more powerful laptop, and the browser-engines will be even more improved and everything will probably be fine.
But right now? Performance gap between browsers being put to use they're not being used for? Watch me care less.
Honestly I'd much rather have people stop writing Chrome-only websites and going back to web-standards than having a faster JS-engine in my open-source browser, because that's not where things hurt these days.
Edit: the hatred for web standards in this thread is staggering. How about a reply saying why you don't think a fragmented web is a problem instead of silently downvoting a legitimate concern?
Plus DRM and possibly other things Google is not telling us. It is a propriety browser distributed as a binary, effectively closed-source, so there is no way for us to know.
Chromium! = Chrome and more people who realize that (and vocalize it) the better.
So what, anyone who wants to use Chrome-targeted websites/demos/games can just install Chromium and experience the same as a Chrome user. No problem at all.
There's enough competition in the web browser market to prevent a lock-in in IE6 scale. There's IE itself, still a massive force in enterprise, there's Firefox, there's Apple with its own Webkit fork in OSX/iOS...
edit: also, these days browsers work together in standardization communities and implement stuff from other browsers. This was basically non-existent at IE6 time, in addition to IE6 being basically frozen and closed for years.
Think of this like a stress-test for the JS engine though. It's probably still useful to work out edge cases and odd performance issues. It's much better in 35.0a2 and that's good for everyone.
I'm glad some people care about browser performance, care about creating art and apps that push performance, because without them we won't get to that future where there's a viable, open, free, standards based platform that people can use to challenge the dominance of truly closed source native app platforms.
So yes I am shocked to hear that you don't care. And I'm a bit shocked to see you rant at a person that simply suggested Firefox's JS engine may not be as performant as Chrome's.
Which leaves the issue of your privacy: do you know what Google records of your data when using chrome, where it gets uploaded and stored, and how often?
I don't, and there's no way to know (due to closed source nature) so I don't trust it. That's not FUD. Those are facts.
There's probably more, especially with sync enabled, like Google permanently storing your web site history, which cannot be verified from the client alone, because the server sync engine is 100% closed and hosted by Google.
Sync is pretty obvious since you clearly have no control over the backend. However, that is a non-issue for someone paranoid enough about where their data goes. Clearly you don't enable it.
I think a healthy dose of paranoia in today's world is fine. I worry a lot about what apps are sending what data where, and whether I have control over that. You, however, seem to just be making blatant claims and touting them as fact. You are part of the problem because you are spouting what amounts to misinformation, and not considering that we have tools available to us with which to verify what an application actually does and whether it is malicious or not.
Yes, there are some cases where Chrome is faster than Firefox. There are also cases where Chrome is much, much slower than Firefox. In particular, Chrome runs asm.js games slower, and couldn't handle my WebGL Minecraft client.
I also remember that IE used to have far better canvas performance than Chrome or Firefox since IE9 was the first browser to hardware-accelerate 2D rendering.
From other comments in this thread, it sounds like things are improving in newer Firefox versions. There will always be worst-cases, but generally, I wouldn't say Chrome is really faster than Firefox.
It's also disappointing to see that nobody in this big thread arguing about JS performance has pointed out that this demo is not JavaScript-bound at all. Profiling shows 80%-90% of the time is spent in texture upload and/or CoreGraphics. JS barely even shows up in the profile.
Yikes - this took me right back to writing M68000 bootsector demo/loaders on my AtariST in the 80's. Happy times. I sometimes wish there was still more of that creative free-for-all spirit in todays UI's. To think of the computing power we have now compared to then - it's slightly saddening to see how conservative and often ugly the interfaces we use are.
Learning about bitwise operators (and everything they entail - so binary in general, endianness, etc) was without a doubt the most beneficial thing I've ever done for my programming abilities.
It was a complete eye opener to how computers work on a far more fundamental level than any other aspect of programming had previously revealed to me.
For anyone without a traditional CS educational background, if you don't know much about bitwise operations or binary, I highly recommend sitting down and spending a few hours exploring them - it will make you think about certain aspects of programming in a very different manner, which - at least for me - resulted in writing much better code.
Aside: While the double tilde is handy, I use the single tilde operator far more often in javascript. If you precede an indexOf statement with a tilde, it essentially turns `indexOf` into `contains`.
if(~someStringOrArray.indexOf(searchTerm))
It works because indexOf returns the index the term is found at, or -1 if it isn't found. This means 0 is actually a successful result, but Boolean(0) = false. But bitwise NOT will clear all of that up:
~(-1) = 0 (evaluates as false)
~(0) = -1 (evaluates as true)
Edit: I'm not suggesting everyone go off and use ~indexOf all the time - I was simply sharing a related javascript bitwise "trick".
You definitely should learn bitwise operators, but if other people have to work with your code I'm not generally in favor of applying them in clever ways where there's a slightly more verbose but much more readable solution (e.x. "~x.indexOf(y)" vs "x.indexOf(y) !== 0"... just type the extra 3 characters)
As a rule of thumb, when ever one thinks that "wow, this code I just wrote is really clever", it should be a sign to sit back, take another approach and rewrite that code.
Clever code almost always means that in hindsight it's terrible and will introduce bugs.
In my opinion "x.indexOf(y) !== 0" is a lot more clearer and will immediately tells other developers what is happening. No point in saving space code, that's why we have minification libraries.
Nobody needs this correction, I hope, but to be clear, it's !== -1 that we're replacing with ~. Then again, maybe this stands as a valid reason to be explicit in the first place. ;-)
A perfect example of why "~x.indexOf(y)" may actually be better... you just messed up, as the alternative should be "x.indexOf(y) !== -1" or "x.indexOf(y) >= 0" or "x.indexOf(y)+1" ...
In any case, it's all a matter of style... because if you don't know that indexOf will return 0 for a positive match, you will still mess up.
That being said, ~indexOf is hardly tricky. if(string.indexOf(term)) is far trickier, because if you didn't realize it returning 0 was a positive result, you easily could write it without a -1 check and not notice it during testing if no values had an index of 0. Then months later you would have a hell of a time debugging it because it would look so innocuous.
On the other hand, by including the tilde, you ensure two things: 1.) Future developer knows what it does and has no problems. 2.) Future developer hasn't seen it before and goes straight to google to see what it does - at which point they learn and now will recognize it in the future.
So at the end of the day, by using a ~, it is explicitly clear that indexOf() should not be used directly as a coerced boolean, and it ensures that anyone touching the code will either know or learn why.
If you come from a C background you would probably parse the intent of that immediately. Bitwise complement is pretty basic stuff and is probably what the C compiler winds up optimizing `!<int>` to anyway. I'm guessing that the only reason it's used here is character optimization.
> ~x.indexOf(…) would be “starts with” rather than “contains”, for negative numbers such as -2 (from ~1) are truthy.
Nope, here's an example you can run it run in your console:
function contains(needle, haystack) {
return Boolean(~haystack.indexOf(needle));
}
var haystack = "The quick brown fox jumps over the lazy dog";
console.log(contains("The", haystack));
console.log(contains("dog", haystack));
console.log(contains("brown fox jumps", haystack));
It's a bit more than that. It can also be used to convert strings (containing numeric values) to Numbers. More commonly seen than the prefix "~~" is "|0", because of it's low order precedence.
With ~~foo you will always get an integer that fits inside a 32-bit integer range... regardless of the input... invalid numbers will be 0. Whereas with a +foo you may get NaN (for an invalid decimal input).
Part of this is because bitwise operations will convert whatever the input value is to a 32-bit integer value before performing the operation, and not fail (invalid input becomes 0 opposed to NaN).
I did some testing a while ago in V8 engine and didn't see any performance benefits using bitwise operations. It seems the engine do these optimizations anyway!
I wouldn't recommend anyone doing optimizations in especially JavaScript unless it's really needed. Remember that optimizations are the root of all evil!
99 comments
[ 2.9 ms ] story [ 153 ms ] thread[0] - https://soundcloud.com/stage7/8-bit-mentality
As a side note: I'm in college now and looking to propose an independent study on compression. Any suggested readings or algorithms I should look into?
[0] https://github.com/Siorki/RegPack
Think 1000.0 vs 1E3, printf("foo") vs puts("foo"), etc.
Lossy compression (which RegPack is actually an example of), typically involves lossless compression plus a preprocessing step to discard information so that the lossless compressor can do a better job.
The techniques for discarding information vary based on application. For images and audio, the most successful techniques tend to involve working in frequency space, so you'll want to read up on the FFT and related transforms.
For code compression, you have different constraints when discarding information because you have to produce a program with identical output to the original. Simple techniques involve removing comments and renaming variables to have shorter names. More advanced techniques involve more complex transformations of the AST, including language-specific tricks like wrapping javascript in a "with(Math){}" block.
Hope some of that helps.
My favorite: http://js1k.com/2014-dragons/demo/1868
for(T=[B=F=Z=D=i=0];i<600;i++)
The key here is that = is a right-associative expression operator which yields the right operand.
The block quotes provide containment.
The human brain is a master at recognising and codifying geometric 3d shapes. The developer who created this is a master at coding geometric shapes and transitions in javascript as well.
Also, shouldn't the number be expressed in bits rather than bytes?
There's no need for guesswork! Just dive into the literature.
Human memory is built precisely around remembering geographic locations, human faces and images[1]. The 'have I seen this before feeling' you get is your brain trying to match the demo location to memories ( my conjecture anyway )
[1] http://en.m.wikipedia.org/wiki/Method_of_loci
This makes you realise how old games must have been driven by the technology.
Programming is a form of art, to me.
1.) people can take away a lot from the code and animation which makes it a great example of a new art form. The street scene in oarticular conjures up emotions.
2.) just because a group of the Internet does not understand or appreciate art in all its forms, doesn't mean anything at all except they are ignorant when it comes to identifying artwork.
So please try this on Firefox and then on Chroome and see the difference. Firefox is not yet there, sadly.
I don't need my browser to drive full-screen 3D games & demos on my current-laptop hardware. That's not what I (or anyone else) is currently using their browser for. Maybe 5 years from now things will have changed. Maybe then truly everything will be in the browser. That's fine, but by then I will have bothered buying a newer, more powerful laptop, and the browser-engines will be even more improved and everything will probably be fine.
But right now? Performance gap between browsers being put to use they're not being used for? Watch me care less.
Honestly I'd much rather have people stop writing Chrome-only websites and going back to web-standards than having a faster JS-engine in my open-source browser, because that's not where things hurt these days.
Edit: the hatred for web standards in this thread is staggering. How about a reply saying why you don't think a fragmented web is a problem instead of silently downvoting a legitimate concern?
Chrome is open-source Chromium plus an auto-updater and Flash.
Chromium! = Chrome and more people who realize that (and vocalize it) the better.
Do you honestly not have a problem with that?
edit: also, these days browsers work together in standardization communities and implement stuff from other browsers. This was basically non-existent at IE6 time, in addition to IE6 being basically frozen and closed for years.
So yes I am shocked to hear that you don't care. And I'm a bit shocked to see you rant at a person that simply suggested Firefox's JS engine may not be as performant as Chrome's.
This is serious FUD with no evidence.
Which leaves the issue of your privacy: do you know what Google records of your data when using chrome, where it gets uploaded and stored, and how often?
I don't, and there's no way to know (due to closed source nature) so I don't trust it. That's not FUD. Those are facts.
A lot of security experts out there would be making noise if they discovered that Chrome was phoning home, or doing anything overtly malicious.
http://www.favbrowser.com/google-chrome-spyware-confirmed/
There's probably more, especially with sync enabled, like Google permanently storing your web site history, which cannot be verified from the client alone, because the server sync engine is 100% closed and hosted by Google.
Sync is pretty obvious since you clearly have no control over the backend. However, that is a non-issue for someone paranoid enough about where their data goes. Clearly you don't enable it.
I think a healthy dose of paranoia in today's world is fine. I worry a lot about what apps are sending what data where, and whether I have control over that. You, however, seem to just be making blatant claims and touting them as fact. You are part of the problem because you are spouting what amounts to misinformation, and not considering that we have tools available to us with which to verify what an application actually does and whether it is malicious or not.
I also remember that IE used to have far better canvas performance than Chrome or Firefox since IE9 was the first browser to hardware-accelerate 2D rendering.
From other comments in this thread, it sounds like things are improving in newer Firefox versions. There will always be worst-cases, but generally, I wouldn't say Chrome is really faster than Firefox.
It's also disappointing to see that nobody in this big thread arguing about JS performance has pointed out that this demo is not JavaScript-bound at all. Profiling shows 80%-90% of the time is spent in texture upload and/or CoreGraphics. JS barely even shows up in the profile.
Edit: much better in 35.0a2. I wonder what they did?
Curious: Does any of your work survive?
http://www.pouet.net/prod.php?which=61668
Making of: http://www.ylilammi.com/webgl/highway4k/Making%20of%20Highwa...
I'd recommend watching the video instead.
It was a complete eye opener to how computers work on a far more fundamental level than any other aspect of programming had previously revealed to me.
For anyone without a traditional CS educational background, if you don't know much about bitwise operations or binary, I highly recommend sitting down and spending a few hours exploring them - it will make you think about certain aspects of programming in a very different manner, which - at least for me - resulted in writing much better code.
Aside: While the double tilde is handy, I use the single tilde operator far more often in javascript. If you precede an indexOf statement with a tilde, it essentially turns `indexOf` into `contains`.
It works because indexOf returns the index the term is found at, or -1 if it isn't found. This means 0 is actually a successful result, but Boolean(0) = false. But bitwise NOT will clear all of that up: Edit: I'm not suggesting everyone go off and use ~indexOf all the time - I was simply sharing a related javascript bitwise "trick".Clever code almost always means that in hindsight it's terrible and will introduce bugs.
In my opinion "x.indexOf(y) !== 0" is a lot more clearer and will immediately tells other developers what is happening. No point in saving space code, that's why we have minification libraries.
In any case, it's all a matter of style... because if you don't know that indexOf will return 0 for a positive match, you will still mess up.
It only works in firefox and if I remember correctly, it is no longer part of the latest ECMA 6 spec.
Do you think the person maintaining your code 2-5 years from now will understand that easily and quickly?
For maintenance, it's important to be as clear as possible, not as tricky as possible.
That being said, ~indexOf is hardly tricky. if(string.indexOf(term)) is far trickier, because if you didn't realize it returning 0 was a positive result, you easily could write it without a -1 check and not notice it during testing if no values had an index of 0. Then months later you would have a hell of a time debugging it because it would look so innocuous.
On the other hand, by including the tilde, you ensure two things: 1.) Future developer knows what it does and has no problems. 2.) Future developer hasn't seen it before and goes straight to google to see what it does - at which point they learn and now will recognize it in the future.
So at the end of the day, by using a ~, it is explicitly clear that indexOf() should not be used directly as a coerced boolean, and it ensures that anyone touching the code will either know or learn why.
The premises was that the future dev won't know. It was hard to write, it should be hard to read moderately applies, I guess.
Things like that are only acceptable if you're optimizing a bottleneck.
Nope, here's an example you can run it run in your console:
Here are three potential cases:Part of this is because bitwise operations will convert whatever the input value is to a 32-bit integer value before performing the operation, and not fail (invalid input becomes 0 opposed to NaN).
I wouldn't recommend anyone doing optimizations in especially JavaScript unless it's really needed. Remember that optimizations are the root of all evil!
It's really impressive and he posted the explanation: http://birdgames.nl/2014/04/js1k-post-mortem-minecraft/