[1] https://www.pcgamer.com/biggest-game-install-sizes/
[2] https://www.pcgamer.com/how-hitman-3s-devs-shrank-the-entire...
no CPU required
it's marketed by Microsoft as "direct storage"
GPU decompression is also a thing though, so compression is still a way to save I/O.
For HDDs, yes, compression is generally a win. HDDs are dead as far as game development is concerned, all modern targets have flash storage.
Some compression codecs that produce smaller files are also MUCH slower to decompress, which swamps any benefits from the reduced i/o. This is part of why sometimes people pick less efficient formats for use in games.
Games sometimes have a lot of sound effects. It's easier to stream 35 GB of data from disk than it is to decompress, like, 10 streams of audio at the same time with whatever CPU you can dedicate to audio.
I do think they could have figured something out, like compressing the right subset of audio assets, but I just want to give the context for why they made that choice.
Maybe 50 hours is a lot for a non story based game but even then once you factor in all the sounds and all their variations to reduce repetition you might be up there.
https://www.escapistmagazine.com/titanfall-dev-explains-the-...
I can attest that MP3 and OGG decompression (the two audio codecs that would have likely been used at the time) are both pretty slow. It adds up.
MP3 isn't slow. I was playing MP3s on a 100 Mhz 486 DX4 in 1996. Certainly a system in 2014 can handle decompressing MP3s on the fly.
Even if you didn't want to do it on the fly during game play, they easily could have been decompressed at load time and it would have taken only a couple seconds. It's not like ENTIRE 35 GB of audio needed to be loaded all at once, nobody had that RAM back then, and very few people (especially gamers) have that much now.
"It's not like ENTIRE 35 GB of audio needed to be loaded all at once" misunderstands the nature of games fundamentally. Some games do potentially need the ability to access any of thousands of sound effects at a moment's notice with the lowest possible latency.
It's like trying to use PNG for texture compression instead of better suited formats.
The minimum requirements to play this game were a 200MHz CPU w/ MMX and 64MB RAM - I was pretty close to this baseline. So anyway, I discovered that the game played at much better FPS (like 30 instead of 5) if you turned the music off - but only when playing MP3 - CD Audio had no hit. Now perhaps the game used a sub-par audio codec, but that single MP3 decode stream was enough to make the game unplayable.
Anyway that's not to say that I would expect MP3 decoding to be a problem in 2014, in fact you can likely play audio with no noticable increase on CPU usage, but when you have multi-stream audio (think voices, background music, sound effects from various channels - guns, explosions, etc.) I can see it starting to add up - especially when the CPU is already constrained for the graphics, game logic and perhaps of course everyone's favourite anti-piracy/anti-cheat logic.
[^1] For younger readers, yes, CD Drives used to come with built-in DACs and a special cable you could hook directly into the audio card, allowing you to listen to CD Audio on PC for "basically" free in terms of CPU cycles.
Heck, just the geometry is probably far larger than folks anticipate.
People often repack video games, making programs to compress and decompress them so they are easier to pirate. It's not uncommon to see a 2-3x reduction in size, for bit-identical results.
This allows it to be ran automatically after download without having the user need to launch the game.
I'd expect that they use a compression that is good for transport, at transport time. I'm not too shocked that they have the assets in a way that is easy to use at runtime.
The crackers who remove copy protection often repackage (or someone else does) to greatly reduce size; since they’re in there poking around the code they can see what isn’t used.
This isn’t new, either, ancient console games have unused assets and even entire levels in the code but disabled.
I can see some benefits to having uncompressed assets in that it would help with asset loading. I'd still be surprised to not have any form of compression at all happening. I'd also be curious to know just how much the assets could be compressed.
So it’s exactly speculation. A lot of games have done a lot of things for a lot of reasons over the decades.
Why are new games so large? Good question. This entire thread is speculative.
The thread might be speculating about _why_ they do that, or whether this particular game does that, but that's a non sequitur, that isn't what I was talking about.
Has any game in the past 5 years that has an install size >100gb used uncompressed assets? I would be very very surprised! The likelihood of this being the case on PS5 or XSX hardware is approximately zero.
Yes I’m familiar with the infamous uncompressed audio in Titanfall.
Fortnite didn’t publish what they did. But I promise it’s not “bEnableCompression=true”. Compression is used up and down the stack with the utmost of care. Even the older games that didn’t use compression did so only after great consideration of the trade offs.
“Games as a Service” games like Fortnite, Destiny, and Call of Duty have often bloated and then been optimized. The fix is never bEnableCompression. It’s more about how the content is sliced and packaged. How to efficiently serve new content is a really tricky problem. And a somewhat new problem that didn’t exist 10 years ago. At least for consoles.
Can you capture a trace in RenderDoc to prove this? Or show raw bmp/uncompressed dds files on disk?
8k texture with mipmaps takes about 100mb with BC7. Which is huge. Should be around 30-40mb with kraken and oodle texture.
> I do wonder how much of it is that a Kraken license costs money and it takes time to integrate, though...
Kraken license doesn't cost anything for Unreal developers. And Sony licensed it for all PS5 games.
Check this out, you can sort by the number of submissions to filter out indie games https://docs.google.com/spreadsheets/d/14CVXd6PTIYE9XlNpRsxJ...
I am kind of curious on why they wouldn't use compression in transport, as it were. I'm still mostly assuming that they do.
Encoding is the hard part, but only need be done once when building the final release.
It's a shame that IFS hamstrung the adoption of fractal compression with their expensive license fees - wouldn't necessarily have been The Future Of Images but at least we'd have had the option.
Sony included dedicated compression support in the PS5, licensed from a leading middleware company, specifically to make it easier to use compression in games. Games are using it.
I don't know why you're trotting out this misinformed BS.
You can also simply watch the statistics when Steam is installing a game - the amount written to disk is larger than the amount downloaded over the network, because they also compress assets in flight to reduce bandwidth usage (the most important thing, since raw assets often load faster from an SSD as long as you have available storage.)
You can argue every single file should be compressed at rest on persistent storage after install, but that's a losing argument. People really hate longer load times, so compression at rest is only appropriate if it improves them.
Yeah, I could've indicated better that I'm talking about on-disk compression of files.
>Sony included dedicated compression support in the PS5, licensed from a leading middleware company, specifically to make it easier to use compression in games. Games are using it.
Not really if we look at 3rd party games. Jedi Survivor is likely not using that since it takes 147 gigs on PS5 and only 139 on Series X. Warzone doesn't use it, Fortnite doesn't use it(despite Epic's acquisition of RAD), Hogwarts Legacy doesn't use it, Elden Ring doesn't use it, FIFA doesn't use it. These are some of the most popular games on the platform. My point was that he is talking about something beyond LZ compression when most games aren't using tools that are available off-the-shelf.
>You can argue every single file should be compressed at rest on persistent storage after install, but that's a losing argument. People really hate longer load times, so compression at rest is only appropriate if it improves them.
We have hardware-accelerated decompression in all current gen consoles and GPU decompression on PC. We would be in much better world if everyone used that.
I find this extremely unlikely. The packaging tools by default will compress files when building a package. Decompression is transparent and done by the hardware; the game doesn't have to implement anything or link any libraries. You would have to explicitly select "no compression" during packaging. Warzone definitely uses it - I worked on Cold War, Vanguard, and MW2 specifically on streaming and decompression across our supported consoles.
You're talking nonsense. I worked on Fortnite and have direct experience with it and the HW decompression on PS5. I can even point you to the patch [0] where Fortnite enabled oodle compression and shrunk the game by 60GB.
[0] https://twitter.com/FortniteStatus/status/131867784125345382...
>You can argue every single file should be compressed at rest on persistent storage after install, but that's a losing argument. People really hate longer load times, so compression at rest is only appropriate if it improves them.
Is this really true? I feel like you'd need an absolutely blisteringly fast SSD to match something like an modern, optimized lz decompressor's speed.
In a crunch situation, I can think of how easy it is for some to be able to circumnavigate various pitfalls while others fall into them and have no time to address it.
Very much a skill/experience thing. There’s countless examples of games that run horribly given their level of presentation, or have no business being so impressively performant on the hardware they’re running.
I can guess what execs will pick when faced with “delay the game or ship a massive bundle.”
However, it also tends to demand more and pay less, so there is churn and burnout and when it comes time to triage, the triage can cut very deep.
If I were to dive into the JIRA for any one of these "missing compression" incidents, I wouldn't expect to find an easy win, I would expect to find "missing compression" beneath a pile of much worse bugs like "level 2 crashes on AMD cards." So it goes.
Yeah, I've often heard that the advice for people who really want to make games is to get some friends together and try to put out something together as a side gig while you work somewhere boring to pay the bills.
SWE at a game studio, especially any AAA game studio, is an awful experience. The expectations are high and the salaries are low because there's a seemingly unlimited bunch of young adults that want to make games.
And yes, it takes extraordinary talent. Your code needs to be able to generate a frame in under 16 milliseconds in order to maintain 60 fps. If you want to appease the hardcore players with these crazy 360 hz monitors, you need to get your game loop down to a mere 3 ms.
The amount of shortcuts and optimizations needed to pull that off is insane. At that level, you're trying to figure out how to minimize cache misses and branch mispredictions. How many Node devs are thinking about those?
Just as a counter point - I work at one of the largest AAA game companies and we have great work life balance(been here 9 years). Don't remember when was the last time I worked more than the required 7.5h/day, never worked on the weekend, the people I work with are all passionate about their work and want to deliver something great. The pay is "ok" - it's not exceptional but it allows for good quality of life. In comparison all my friends who went to work in traditional software development are paid somewhat more than I am but they all 100% hate their jobs, so......I don't think it's a bad trade off.
As for the infinite supply of people wanting to do this - it's only really true at junior level, as soon as you talk anyone above junior it's extremely hard to recruit and you might be getting a handful of candidates a year. We've been trying to hire a senior rendering programmer for over a year now and we've had like 5 candidates total.
If most commercial software is a feature factory, games are "megafactories" because they are not really competing on the robustness of the implementation, just on delivering a certain kind of experience that delivers some interactivity and shows off some assets, and that tends to lead towards approaches that hack one feature on top of another and then lean on manual testing to catch "enough" errors. Many games also take characteristic shortcuts that eliminate some options for game design in order to simplify the tech.
The larger companies will often keep their tech teams separated from their game teams and treat the tech coders more generously. This comes with all the pluses and minuses of siloing the work - sometimes they solve the wrong problem, but do it well.
When I talk to people in the game industry, it sounds a lot like my experiences outside it. Plenty of programming skill to go around, but the skill is often allocated inefficiently, and everyone's under pressure to just ship stuff and move on to the next deliverable.
I'm not saying that you are doing this, I am saying that this is done.
watch some GDC developer videos on YouTube. these people work HARD for performance.
All inference of Stable Diffusion is done in FP16 at best, with multi-step models, and models themselves are highly inefficient. I would be surprised if in May 2024 4090 isn't capable of generating 8k(8192x8192) Stable Diffusion quality image in less than 1 second. And also you wouldn't realistically need to
> also why not just compress it? Any quality degradation from compression will be less than the artifacts produced by an AI image generator
Because it allows for much more variance in content. I'm a bit sick of seeing tiled textures everywhere TBH. Also virtually all textures would be AI generated in less than 5 years.
You make it sound like my electricity bill would be lower by just downloading the bigger files...
The issue at hand around install size comes down to the engines, their ability to decompress asset bundles, the fidelity of the assets (8k vs 8k,4k,2k,1024) if no runtime optimization is done. WAV sounds vs OGG vs MP3 vs flac, there’s a lot of shit in those asset packs. You could compress it all like they do, into a folder structure you can index and load from, or you can write that game code to make boss fights cause camera shake, the decisions you make making a game are really all about making the game and little to do with how best to deliver your content.
Some texture formats like DXT are already compressed. Raw PNG’s could have compression. All these things are possible if the engine supports it.
There is no excuse for them to be shipping a 150GB game on the PS5 when so many cross-gen games are 40-60% smaller on PS5 than PS4
he's saying that game asset paradigms are headed in the wrong direction rapidly.
How does that work?