3 ms·

Unless you're suggesting that games fit into memory completely, why would you not want your storage to be as high throughput and low latency as possible even fo

by lxgr 1y ago

Unless you're suggesting that games fit into memory completely, why would you not want your storage to be as high throughput and low latency as possible even for reduced texture sizes?

delusional 1y ago
I'd argue that game sizes at this point are whack, and I think the reason for that is the speed and size of modern storage. We started chasing our own tail, faster/bigger storage leads to larger games which needs faster/bigger storage and on it goes. The problem isn't that either of those things are inherently bad. A game being "large" doesn't mean anything as long as it works, and a storage device being fast/large is good. The problem is when both of those things conspire to spiral out of control and we end up having to invent faster/larger storage devices without any need other than "well this size worked". I guess it's a problem of incentives. The developer of the game doesn't pay when the game is larger, I do.
- parineum 1y ago
  > I guess it's a problem of incentives. The developer of the game doesn't pay when the game is larger, I do. This is everywhere in computing but there's a better reason for it than you're giving. It's a cheaper/easier for companies to develop "bloated" software that runs on more powerful hardware. That includes uncompressed textures/sound (because why bother finding a codec or fine tuning quality tradeoff when you can just get give uncompressed data). But the end result, for you, is more software is available and more developers exist (because writing efficient and performant code is much harder). A game like Stardew Valley, for instance, probably doesn't exist. I've put a ton of hours into that game and I think it's excellent but, not to cast any shade, the game isn't exactly a masterclass in efficiency. It's only slightly more advanced than a SNES game but it consumes many many time more resources. The benefit to you is that an inexperienced software engineer with a great idea can bring their idea to fruition using all sorts of bloated tools.
  - delusional 1y ago
    > A game like Stardew Valley, for instance, probably doesn't exist. I've put a ton of hours into that game and I think it's excellent but, not to cast any shade, the game isn't exactly a masterclass in efficiency. It's only slightly more advanced than a SNES game but it consumes many many time more resources. Stardew Valley is a great example of why storage does not follow the same logic of "fewer constraints lowers the barrier of entry". Stardew is 600MB, it does not benefit from terabytes of capacity or 1900MB/s speeds. Instead, the only games pushing that frontiers are otherwise well staffed and well funded efforts that just don't bother. Call Of Duty would not be a worse game if it was 200GB instead of 300GB. No understaffed indie game I know of takes up a large amount of storage.
    - parineum 1y ago
      An SNES cartridge holds up to 48 megabits. SV has better visuals and sound but is it that much better? I don't think SV would have been made by ConcernedApe if he only had a SNES sdk. I believe he used XNA, at least initially. All that framework adds weight but it made SV possible. The tradeoff is 600 megabytes vs 48 megabits. I'll take SV any day of the week.
kbolino 1y ago
In this scenario, low latency would be a lot more useful than high throughput.
- lxgr 1y ago
  Why? Both high latency and low throughput (given large asset sizes) mean longer waiting times.
  - kbolino 1y ago
    Wait, why large asset sizes? Aren't we talking about "reduced texture sizes" etc.? To me, this also implies reduced video sizes, compressed audio, and so on. So the scenario as I understand it is that, broadly, no individual asset is that large, but all of them together exceed what can fit in RAM. In that case, there would be a working set of loaded assets which is smaller than all available assets, and consequently, there would be a need to load different assets on demand quickly. So yeah, latency would be more important than throughput, though of course you would still need halfway decent throughput (time-to-last-byte is a kind of latency, after all).

by lxgr 1y ago

Unless you're suggesting that games fit into memory completely, why would you not want your storage to be as high throughput and low latency as possible even for reduced texture sizes?

delusional 1y ago

I'd argue that game sizes at this point are whack, and I think the reason for that is the speed and size of modern storage. We started chasing our own tail, faster/bigger storage leads to larger games which needs faster/bigger storage and on it goes. The problem isn't that either of those things are inherently bad. A game being "large" doesn't mean anything as long as it works, and a storage device being fast/large is good. The problem is when both of those things conspire to spiral out of control and we end up having to invent faster/larger storage devices without any need other than "well this size worked". I guess it's a problem of incentives. The developer of the game doesn't pay when the game is larger, I do.

parineum 1y ago
> I guess it's a problem of incentives. The developer of the game doesn't pay when the game is larger, I do. This is everywhere in computing but there's a better reason for it than you're giving. It's a cheaper/easier for companies to develop "bloated" software that runs on more powerful hardware. That includes uncompressed textures/sound (because why bother finding a codec or fine tuning quality tradeoff when you can just get give uncompressed data). But the end result, for you, is more software is available and more developers exist (because writing efficient and performant code is much harder). A game like Stardew Valley, for instance, probably doesn't exist. I've put a ton of hours into that game and I think it's excellent but, not to cast any shade, the game isn't exactly a masterclass in efficiency. It's only slightly more advanced than a SNES game but it consumes many many time more resources. The benefit to you is that an inexperienced software engineer with a great idea can bring their idea to fruition using all sorts of bloated tools.
- delusional 1y ago
  > A game like Stardew Valley, for instance, probably doesn't exist. I've put a ton of hours into that game and I think it's excellent but, not to cast any shade, the game isn't exactly a masterclass in efficiency. It's only slightly more advanced than a SNES game but it consumes many many time more resources. Stardew Valley is a great example of why storage does not follow the same logic of "fewer constraints lowers the barrier of entry". Stardew is 600MB, it does not benefit from terabytes of capacity or 1900MB/s speeds. Instead, the only games pushing that frontiers are otherwise well staffed and well funded efforts that just don't bother. Call Of Duty would not be a worse game if it was 200GB instead of 300GB. No understaffed indie game I know of takes up a large amount of storage.
  - parineum 1y ago
    An SNES cartridge holds up to 48 megabits. SV has better visuals and sound but is it that much better? I don't think SV would have been made by ConcernedApe if he only had a SNES sdk. I believe he used XNA, at least initially. All that framework adds weight but it made SV possible. The tradeoff is 600 megabytes vs 48 megabits. I'll take SV any day of the week.

kbolino 1y ago

In this scenario, low latency would be a lot more useful than high throughput.

lxgr 1y ago
Why? Both high latency and low throughput (given large asset sizes) mean longer waiting times.
- kbolino 1y ago
  Wait, why large asset sizes? Aren't we talking about "reduced texture sizes" etc.? To me, this also implies reduced video sizes, compressed audio, and so on. So the scenario as I understand it is that, broadly, no individual asset is that large, but all of them together exceed what can fit in RAM. In that case, there would be a working set of loaded assets which is smaller than all available assets, and consequently, there would be a need to load different assets on demand quickly. So yeah, latency would be more important than throughput, though of course you would still need halfway decent throughput (time-to-last-byte is a kind of latency, after all).