5 ms·
Reading bits in far too many ways
- panic 8y agoThis is part 3 of a series; part 1 was discussed here: https://news.ycombinator.com/item?id=16417490 https://news.ycombinator.com/item?id=16417490
- godelmachine 8y agoI seldom understand his posts. He goes way too deep into the nitty gritty details, which is actually good. However, its quite tough for me to apply his teaching to real life apps. I had gone through his Twitter and LinkedIn and looks like he works in video game industry.
- royjacobs 8y agoHe works for RAD Game Tools, a developer of middleware for games. He also used to be part of the demoscene group Farbrausch, responsible for 64k intros such as FR-08 and the 96k first person shooter Kkrieger.
- jacobush 8y agoKkrieger was totally mind blowing, and for me the first painfully clear demonstration between the difference between tech demo and product known and used by the masses. It was science fiction level technology. Wikipedia says development was started in 2002, but I have (possibly completely wrong) recollections of seeing some kind of (non playable, 320x200 resolution) demo way earlier than that.
- royjacobs 8y agoYour recollection doesn't seem accurate, sorry :) Btw, it might be interesting to know that AAA games also use plenty of procedurally generated assets through tools like Speedtree and Substance, but they are typically generated offline instead of application startup.
- userbinator 8y agoVery important for things like video codecs, since this is an inherently serial process and (as mentioned in the article) attempting to parallelise it is not really possible nor gives much gain. Also interesting to note that the ultra-naive "pull one bit at a time and accumulate them until you have enough" method which often taught in CS courses when they cover Huffman compression and the like is basically a useless dead-end. In practice, no one decodes variable-length-codes that way because it is far too slow.