I'd describe that as a trend, rather than a consensus.
It wasn't an entirely bad idea, because comments carry a high maintenance cost. They usually need to be rewritten when nearby code is edited, and they sometimes need to be rewritten when remote code is edited - a form of coupling which can't be checked by the compiler. It's easy to squander this high cost by writing comments which are more noise than signal.
However, there's plenty of useful information which can only be communicated using prose. "Avoid unnecessary comments" is a very good suggestion, but I think a lot of people over-corrected, distorting the message into "never write comments" or "comments are a code smell".
You've rediscovered a state-of-the-art technique, currently used by JPEG XL, AV1, and the HEVC range extensions. It's called "chroma from luma" or "cross-component prediction".
This technique has a weakness: the most interesting and high-entropy data shared between the luma and chroma planes is their edge geometry. To suppress block artefacts near edges, you need to code an approximation of the edge contours. This is the purpose of your quadtree structure.
In a codec which compresses both luma and chroma, you can re-use the luma quadtree as a chroma quadtree, but the quadtree itself is not the main cost here. For each block touched by a particular edge, you're redundantly coding that edge's chroma slope value, `(chroma_inside - chroma_outside) / (luma_inside - luma_outside)`. Small blocks can tolerate a lower-precision slope, but it's a general rule that coding many imprecise values is more expensive than coding a few precise values, so this strategy costs a lot of bits.
JPEG XL compensates for this problem by representing the local chroma-from-luma slope as a low-resolution 2D image, which is then recursively compressed as a lossless JPEG XL image. This is similar to your idea of using PNG-like compression (delta prediction, followed by DEFLATE).
Of course, since you're capable of rediscovering the state of the art, you're also capable of improving on it :-)
One idea would be to write a function which, given a block of luma pixels, can detect when the block contains two discrete luma shades (e.g. "30% of these pixels have a luminance value close to 0.8, 65% have a luminance value close to 0.5, and the remaining 5% seem to be anti-aliased edge pixels"). If you run an identical shade-detection algorithm in both the encoder and decoder, you can then code chroma information separately for each side of the edge. Because this would reduce edge artefacts, it might enable you to make your quadtree leaf nodes much larger, reducing your overall data rate.
Thanks for the feedback, and the interesting ideas. It's good to know that I was on to something and not completely off :-)
I'm mostly doing this for learning purposes, but a hidden agenda is to create a low-latency codec that can be used in conjunction with other codecs that deal primarily with luma information. AV1 and friends are usually too heavy in those settings, so I try to keep things simple.
There was a constraint - since 2009, the Joint Photographic Experts Group had published JPEG XR, JPEG XT and JPEG XS, and they were probably reluctant to break that naming scheme.
They're running out of good options, but I hope they stick with it long enough to release "JPEG XP" :-)
The rods are only active in low-light conditions; they're fully active under the moon and stars, or partially active under a dim street light. Under normal lighting conditions, every rod is fully saturated, so they make no contribution to vision. (Some recent papers have pushed back against this orthodox model of rods and cones, but it's good enough for practical use.)
This assumption that rods are "the luminance cells" is an easy mistake to make. It's particularly annoying that the rods have a sensitivity peak between the blue and green cones [1], so it feels like they should contribute to colour perception, but they just don't.
Protanopia and protanomaly shift luminance perception away from the longest wavelengths of visible light, which causes highly-saturated red colours to appear dark or black. Deuteranopia and deuteranomaly don't have this effect. [1]
Blue cones make little or no contribution to luminance. Red cones are sensitive across the full spectrum of visual light, but green cones have no sensitivity to the longest wavelengths [2]. Since protans don't have the "hardware" to sense long wavelengths, it's inevitable that they'd have unusual luminance perception.
I'm not sure why deutans have such a normal luminous efficiency curve (and I can't find anything in a quick literature search), but it must involve the blue cones, because there's no way to produce that curve from the red-cone response alone.
Back of the envelope, in the two years since the game was released, this single bug has wasted at least US$10,000,000 of hardware resources. That's a conservative estimate (20% of people who own the game keep it installed, the marginal cost of wasted SSD storage in a gaming PC is US$2.50 per TB per month, the install base grew linearly over time), so the true number is probably several times higher.
In other words, the game studio externalised an eight-figure hardware cost onto their users, to avoid a five-to-six-figure engineering cost on their side.
Data duplication can't just be banned by Steam, because it's a legitimate optimisation in some cases. The only safeguard against this sort of waste is a company culture which values software quality. I'm glad the developers fixed this bug, but it should never have been released to users in the first place.
Steam compresses games as much as possible, so in the case of Helldivers 2, you had to download between ~30 and ~40 GB, which was then unpacked to 150 GB (according to SteamDB[0])
You are missing that each update takes AGES while it tortures your disk for patching the files (on my machine it takes 15min or so, and that's on an SSD). So I agree that this is careless and reminds me of the GTA5 startup time that was fixed by a dedicated player who finally had enough and reverse engineered the problem (see https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times...). I still find these things hard to accept.
Steam update durations depend on compression + CPU performance + SSD I/O. Things will be harder when the disk is almost full and live defragmentation kicks in to get free space for contiguous files. Some SSDs are fast enough to keep up with such a load, but a lot of them will quickly hit their DRAM limits and suddenly that advertised gigabyte per second write speed isn't all that fast. Bonus points for when your SSD doesn't have a heatsink and moving air over it, making the controller throttle hard.
Patching 150GiB with a compressed 15GiB download just takes a lot of I/O. The alternative is downloading a fresh copy of the 150GiB install file, but those playing on DSL will probably let their SSD whizz a few minutes longer than spend another day downloading updates.
If your SSD is slower than your internet capacity, deleting install files and re-downloading the entire game will probably save you some time.
In this case, the bug was 131 GB of wasted disk space after installation. Because the waste came from duplicate files, it should have had little impact on download size (unless there's a separate bug in the installer...)
This is why the cost of the bug was so easy for the studio to ignore. An extra 131 GB of bandwidth per download would have cost Steam several million dollars over the last two years, so they might have asked the game studio to look into it.
This article presents it as a big success, but it could be read the opposite way: "Developers of Helldivers 2 wasted 130 GB for years and didn't care because it was others people computers"
> An extra 131 GB of bandwidth per download would have cost Steam several million dollars over the last two years
Nah, not even close. Let's guess and say there were about 15 million copies sold. 15M * 131GB is about 2M TB (2000 PB / 2 EB). At 30% mean utilisation, a 100Gb/s port will do 10 PB in a month, and at most IXPs that costs $2000-$3000/month. That makes it about $400k in bandwidth charges (I imagine 90%+ is peered or hosted inside ISPs, not via transit), and you could quite easily build a server that would push 100Gb/s of static objects for under $10k a pop.
It would surprise me if the total additional costs were over $1M, considering they already have their own CDN setup. One of the big cloud vendors would charge $100M just for the bandwidth, let alone the infrastructure to serve it, based on some quick calculation I've done (probably incorrectly) -- though interestingly, HN's fave non-cloud vendor Hetzner would only charge $2M :P
Isn't it a little reductive to look at basic infrastructure costs? I used Hetzner as a surrogate for the raw cost of bandwidth, plus overheads. If you need to serve data outside Europe, the budget tier of BunnyCDN is four times more expensive than Hetzner.
But you might be right - in a market where the price of the same good varies by two orders of magnitude, I could believe that even the nice vendors are charging a 400% markup.
Yea, I always laugh when folks talk about how expensive they claim bandwidth is for companies. Large “internet” companies are just paying a small monthly cost for transit at an IX. They arent paying $xx/gig ($1/gig) like the average consumer is. If you buy a 100gig port for $2k, it costs the same if you’re using 5 GB a day or 8 PB per day.
> I imagine 90%+ is peered or hosted inside ISPs, not via transit
How hosting inside ISPs function? Does ISP have to MITM? I heard similar claims for Netflix and other streaming media, like ISPs host/cache the data themselves. Do they have to have some agreement with Steam/Netflix?
Yea netflix will ship a server to an ISP (Cox, comcast, starlink, rogers, telus etc) so the customers of that ISP can access that server directly. It improves performance for those users and reduces the load on the ISP’s backbone/transit. Im guessing other large companies will do this as well.
A lot of people are using large distributed DNS servers like 8.8.8.8 or 1.1.1.1 and these cansometimes direct users to incorrect CDN servers, so EDNS was created to help with it. I always use 9.9.9.11 instead of 9.9.9.9 to hopefully help improve performance.
The CDN/content provider ships servers to the ISP which puts them into their network. The provider is just providing connectivity and not involved on a content-level, so no MITM etc needed.
Makes sense, initial claim was that HD2 size was mainly because of duplicated assets, and any compression worth it's salt would de-duplicate things effectively.
> Originally, the game’s large install size was attributed to optimization for mechanical hard drives since duplicating data is used to reduce loading times on older storage media. However, it turns out that Arrowhead’s estimates for load times on HDDs, based on industry data, were incorrect.
It wasn't a bug. They made a decision on what to optimise which was based on incomplete / incorrect data and performed the wrong optimisation as a result.
As a player of the game, I didn't really care that it took up so much space on my PC. I have 2TB dedicated for gaming.
Why not offer 2 versions for download and let the user choose, whether they want to block their whole disk with a single game, or accept a bit longer loading times? Or let the user at installation time make an informed decision by explaining the supposed optimization? Or let the user decide before downloading, what resolution (ergo textures) they want as the highest resolution they will play the game at and only download the textures they need up to that resolution?
Because all of these suggestions require developer resources. Doing a quick web search it is estimated they have ~150 employees. A lot of triple-A studios have thousands or ten of thousands of employees. So they are relatively small game studio.
Also note that they are adding more game modes, mode warbonds, and the game is multi-platform and multiplayer. The dev team is relatively small compared to other game studios.
The game engine the game is built in is discontinued and I believe is unsupported. IIRC they are rewriting the game in UE5 because of the issues with the unsupported engine.
A lot of people have problems with Arrowhead (there been some drama between Arrowhead and the community). The install size of the game while a problem wasn't like the top problem. Bigger issues in my mind as someone that plays the game regular is:
e.g.
- The newest updates to the game with some of new enemy types which are quite unfair to fight against IMO (Dragon Roach and the War Strider).
- The other complaint was performance/stability of the game was causing issues with streamers PCs. Some people claimed the game was breaking their PCs (I think this was BS and their PCs were just broken anyway). However there was a problem with performance in the game, which was resolved with a patch a few weeks ago. That greatly improved the game IMO.
I can't answer all of this questions, but "why not offer 2 versions and allow the user to choose" was mentioned here [0].
Helldivers 2 is a multiplayer game, for the game 2 start, everyone in the lobby needs the game to be fully loaded. If one person would choose to have a slower version, it would make everyone wait longer. Which is definitely not a trade off you are willing to make as a game developer because makes the experience for other players worse.
There could be other options and better optimizations, such as lower textures that you mentioned, but I agree with the developers on having only a "fast version".
> the marginal cost of wasted SSD storage in a gaming PC is US$2.50 per TB per month
Out of curiousity, how do you come up with a number for this? I would have zero idea of how to even start estimating such a thing, or even being able to tell you whether "marginal cost of wasted hard drive storage" is even a thing for consumers.
I'd be very interested in hearing alternative estimates, but here's my working:
The lowest cost I could find to rent a server SSD was US$5 per TB-month, and it's often much higher. If we assume that markets are efficient (or inefficient in a way that disadvantages gaming PCs), we could stop thinking there and just use US$2.50 as a conservative lower bound.
I checked the cost of buying a machine with a 2 TB rather than 1 TB SSD; it varied a lot by manufacturer, but it seemed to line up with $2.50 to $5 per TB-month on a two-to-five-year upgrade cycle.
One reason I halved the number is because some users (say, a teenager who only plays one game) might have lots of unused space in their SSD, so wasting that space doesn't directly cost them anything. However, unused storage costs money, and the "default" or "safe" size of the SSD in a gaming PC is mostly determined by the size of games - so install size bloat may explain why that "free" space was purchased in the first place.
> whether "marginal cost of wasted hard drive storage" is even a thing for consumers
As long as storage has a price, use of storage will have a price :-)
Maybe average cost of next-size-up SSD price divided by a SWAG of a gaming PC lifetime? So if I had to buy a 2 TB NVMe stick instead of a 1 TB stick it's an extra $70 and I upgrade after 5 years that's only about $1 per TB-Month. I don't game I have no idea if those are good numbers.
The cheapest storage tier on s3 with instant retrieval is $.004 per GB-Month which implies AWS can still make money at $4 per TB-Month so $2.50 for consumer hardware sounds reasonable to me.
Experienced software developer, currently available for freelance work. I'd be happy to sign either a conventional months-long software development contract, or a short consulting contract.
Location: UK
Remote: Yes
Willing to relocate: No
Resume/CV: By request
Email: (my username) at protonmail dot com
My preferred coding style is high-rigour and highly-documented, which tends to be a great fit for contract work. I have a track record of delivering quality results under minimal supervision.
My specialist skills:
- The Rust language, which has been my daily driver for more than a decade.
Fields in which I'm highly experienced, but below specialist level:
- Web development, with a frontend bias (TypeScript, React, JS build systems, the Web platform, WebGL, WebGPU, Node, WebAssembly...)
- Native development (native build systems, FFIs, low-level Win32, basic fluency in C/C++...)
- Leadership, communication and technical writing, all learned in a previous career.
I should also mention a modest level of experience in computer vision, greenfield R&D, game engine development, programming language development, and data compression. I'm comfortable with ubiquitous tools like Bash, Make, Git, GitHub, Docker and Figma. (Sorry for the keyword spam; you know how it is.)
I'm currently offering a 50% discount for any contract which seems highly educational. My areas of interest include acoustics, DSP, embedded programming, Svelte, Solid, functional languages, Swift, and backend development in general.
I can be flexible on time zones. No interest in relocating long-term, but I'd be happy to visit your team in person for a few days to break the ice.
Thanks for reading, and I look forward to hearing from you :-)
If you set out to build a practical UI from first principles using 1995 technology, I think you'd end up with something a lot like Windows 95. It's like a checklist of all the things we should be doing.
Luminance contrast is used to create a hierarchy of importance. Most backgrounds are medium grey, so that all text and icons are low-importance by default. Text fields, dropdowns, check boxes and radio buttons are black-on-white: a subtle call to action. Window, button and scrollbar edges always include pure white or pure black. Active toggle buttons have a light grey background, sacrificing the "3D shading" metaphor in the name of contrast.
Most colour is limited to two accents: pale yellow and navy blue. Small splashes of those colours are mixed together in icons to make them recognisable at a glance. Deactivated icons lose all colour. The grey, yellow and blue palette is highly accessible for colour-blind people, and the yellow and blue accents also occupy unique points in the luminance space (the yellow sits between white and grey, the blue sits between grey and black).
Despite all of this restraint, the designers weren't afraid of high contrast and high saturation; white text on a navy blue background shows up very sparingly, always as a loud "YOU ARE HERE" beacon. The designers understood that navigation is more important than anything else.
The graphics are strictly utilitarian, with no unnecessary texture or visual noise. The entire UI is typeset using just two weights of 9px MS Sans Serif. The only skeuomorphic elements are some program and folder names, a tiny resizing grip at the corner of each window, and a simple simulation of depth when push buttons are clicked. 3D edges are used to make the scene layout easier to parse, not to make it look physical or familiar.
Related components are almost always visually grouped together, using borders, filled rectangles and negative space. (I suspect the designers would have used fewer borders and more fills if the palette of background colours had been a little larger.) Dark and light backgrounds are freely mixed in the same UI, which requires both white and black text to be present. The depth of recursion (boxes in boxes in boxes...) is fairly shallow. Homogeneous collections of components are always enclosed in a strong border and background, which enables sibling components to be displayed with no borders at all between them.
All of these tasteful design choices were fragile, because you can only preserve them if you understand them. Windows XP made the background colours lighter, which reduced the available dynamic range of luminance cues; it tinted many backgrounds and components yellow or blue, which made chrominance more noisy; it introduced gradient fills and gradient strokes, which were less effective at grouping components; it added soft shading to icons, which made their shapes less distinct; and so on. Almost every change broke something, and so after just one major revision of the UI, most of the magic was already gone.
That could be made to work by stacking a transparent OLED panel in front of a transparent LCD panel. The LCD would absorb light, and the OLED would emit light.
I just tried to search for some examples, but I can't find any. Maybe the displays can't be made thin enough to eliminate parallax between the two images?
Interesting approach. It doesn't even introduce an extra rounding error, because converting from 32-bit XYB to RGB should be similar to converting from 8-bit YUV to RGB.
However, when decoding an 8-bit-quality image as 10-bit or 12-bit, won't this strategy just fill the two least significant bits with noise?
Could be noise, but finding a smooth image that rounds to a good enough approximation of the original is quite useful. If you see a video player talk about debanding it is a exactly that.
I don't know if JPEG XL constrains solutions to be smooth.
It wasn't an entirely bad idea, because comments carry a high maintenance cost. They usually need to be rewritten when nearby code is edited, and they sometimes need to be rewritten when remote code is edited - a form of coupling which can't be checked by the compiler. It's easy to squander this high cost by writing comments which are more noise than signal.
However, there's plenty of useful information which can only be communicated using prose. "Avoid unnecessary comments" is a very good suggestion, but I think a lot of people over-corrected, distorting the message into "never write comments" or "comments are a code smell".