Rich Geldreich

I think you had a maladjusted TV or something. On a good TV or composite monitor, pixel art should have fairly sharp edges. Most televisions had adjustment controls for various thing (sharpness, contrast, tint, color, etc); so many people didn't know how to properly adjust them, though.

My first video game system was a cheapo b/w pong clone knockoff thing from radio shack. My second was an Atari 2600. Later my parents bought me a TRS-80 Color Computer 2 with 16K (which eventually got upgraded to 32, then 64K), and then still later a Color Computer 3. An NES was in there somewhere, and I played on friend's Sega Genesis systems and C=64 computers (plus Apple IIe, PCjr, and others).

Pixel art (back then, they were just "sprites" or "tiles" to us - I'm not sure if the term "pixel art" was a thing then - I never heard it, but it doesn't mean it wasn't) wasn't fuzzy or soft, unless things weren't adjusted right.

The only other time it might be a little funky was if the machine in question was trying to use artifacting in some manner:

http://nerdlypleasures.blogspot.com/2013/09/the-overlooked-artifact-color.html

As you can see - artifacting could introduce a certain level of "fuzziness" to graphics; but scroll to the bottom of that page, to see what the CoCo 2 could do in the hands of someone competent with the effect.

The CoCo 2 got 4 colors on an effectively black/white screen mode by interleaving black and white values - spaced close together on the screen, the NTSC system…

I researched Valve quite a bit before applying there (I did not get in, but one of their senior team members wrote me a nice message).
Some interesting bits I found:

- The average engineer there makes at least $400k/year with bonuses, although it could be much more (or less, if they somehow wind up in a bad project). IIRC Valve makes around $2m of profit for every head in the company (they only have ~300 employees or so).

- In spite of the seemingly ideal flat organization, many people find themselves unhappy there. One former employee hints at some reasons here:
http://richg42.blogspot.com/2015/01/open-office-spaces-and-cabal-rooms-suck.html
From other employees, I have heard that the flat organization and bonus structure leads to unnecessary drama/rivalry, poor communication (or even fear of communication), lack of innovation (creating your own project is discouraged, and teams have financial incentive to stick with projects that pay the highest bonus), etc. This is not to say Valve is a "bad" place to work at, I am sure it beats the hell out of many other job environments, even ignoring the excellent pay.

- If you do want to work there, you will probably have had to shipped multiple titles AND be recommended by an existing team member (alternately, writing a popular mod is equally lucrative). Typically, applying through their website will not get you a job - they usually hire by actively looking through a pool of candidates that they already know of. They also look for…

Some of this is because I'm wrapping it inside a ghetto CSS 3D presentation framework I've been reusing for almost 2 years, built when this stuff was buggy as hell. Mea culpa.

But compared to any game running on the same underlying hardware... Remember all the aimbots, wallhacks and more that people have been hacking in for years? How many crashes you've experienced? "Please install the latest driver". "You must restart the game to apply this setting". How about the fact that every game pretty much freezes the UI while it's first loading? You don't want web sites to work like that. WebGL has fundamentally different priorities, but they're not all bad.

GPU drivers have favored performance over stability for years. Modern games are a giant pile of hacks, but devs can afford the massive QA operation required to hide this fact. Heck, Nvidia turned game engine hacking into a feature, allowing you to add modern effects into old engines through their drivers.

See for example if you can figure out which vendor is which in this Valve developer's tell-all:

http://richg42.blogspot.co.uk/2014/05/the-truth-on-opengl-driver-quality.html

In this discussion https://news.ycombinator.com/item?id=8911369 someone quoted this page http://mattmahoney.net/dc/text.html as saying it compiles to about 150k. I can't find the current listing, but I'm on mobile :/

Btw: the author's blog talks about LZHAM quite a bit http://richg42.blogspot.com/

edit: Looks like it's up to 190k

Compression Compressed size Decompresser Total size Time (ns/byte)
Program Options enwik8 enwik9 size (zip) enwik9+prog Comp Decomp Mem Alg Note
------- ------- ---------- ----------- ----------- ----------- ----- ----- --- --- ----
lzham 1.0 -d29 -x 25,002,070 202,237,199 191,600 s 202,428,799 1096 6.6 7800 LZ77 70
xz 5.2.1--lzma2=preset=9e,dict=1GiB,lc=4,pb=0 24,703,772 197,331,816 36,752 xd 197,368,568 5876 20 6000 LZ77 73
gzip 1.3.5 -9 36,445,248 322,591,995 38,801 x 322,630,796 101 17 1.6 LZ77

Nvidia's proprietary driver breaks upon every new kernel release, which is why they have a shim. Furthermore, Nvidia can't ship their driver in the official Linux kernel due to copyright issues, and they're forced to handle all the maintenance burden of their driver (whereas AMD reaps the benefits of Intel's GPU driver bugfixing, and vice versa, thus lowering both Intel's and AMD's driver costs on Linux).

Besides, Nvidia's been having trouble with their Tegra GPUs on Android, and as a result have been forced to pitch in a bit on Nouveau (the reverse-engineered open-source Nvidia driver). They're still having trouble with their driver situation on mobile, as a result of their unwillingness to play ball with the kernel.

Actually, that last sentence above - I'm really not too confident on that, I've heard various hearsay but the only source I concretely remember is the "other drivers" section of http://richg42.blogspot.com.au/2014/05/the-truth-on-opengl-driver-quality.html

Also, while AMD's OpenCL implementation has more features on paper, the runtime is frequently broken where NVIDIA's claimed features actually all work. Everything I've heard from people who've used it is that they ended up with so much vendor-specific code to patch around AMD's bugs and deficiencies that they might as well have just written CUDA in the first place.

This is an old article but the old "vendor B" stuff still rings incredibly true with at least AMD's OpenCL stack as well.

https://richg42.blogspot.com/2014/05/the-truth-on-opengl-driver-quality.html

Thus NVIDIA actually has even less of a lock-in than people think. If you want to write a better OneAPI ecosystem and run it on OpenCL runtime... go hog wild! NVIDIA is best at that too! You just don't get the benefit of NVIDIA's engineers writing libraries for you, all that obviously takes place in CUDA.