6 ms·

Same idea as this game development legend https://www.dodgycoder.net/2012/02/coding-tricks-of-game-developers.html https://www.dodgycoder.net/2012/02/coding-tr

Same idea as this game development legend https://www.dodgycoder.net/2012/02/coding-tricks-of-game-developers.html https://www.dodgycoder.net/2012/02/coding-tricks-of-game-dev... > he had put aside those two megabytes of memory early in the development cycle. He knew from experience that it was always impossible to cut content down to memory budgets, and that many projects had come close to failing because of it. So now, as a regular practice, he always put aside a nice block of memory to free up when it's really needed.

295310e0 6y ago
If true, I hate that story. Think of the better art assets that were needlessly left behind. How is it that said block of memory had never been identified by any profiling?
- emmab 6y ago
  If it would be detected by profiling that does make the technique asymmetric in that it would only stick around if nobody profiled to find it.
  - hinkley 6y ago
    Or if you didn’t have an understanding with the sort of people who would run the profiler...
- usefulcat 6y ago
  > Think of the better art assets that were needlessly left behind. Consider how long it takes to edit or recreate art assets to reduce their size. Depending on the asset, you might be basically starting over from scratch. Rewriting code to reduce its size is likely to be an even worse option, introducing new bugs and possibly running slower to boot. At least smaller, simpler art assets are likely to render faster. This is also the kind of problem that's more likely to occur later in the schedule, when time is even more scarce. Between these two factors (lack of time and amount of effort required to get art assets which are both decent looking and smaller), I think in practice you're actually more likely to get better quality art assets by having an artificially reduced memory budget from the outset.
- _carbyau_ 6y ago
  I see it as a "Choose your problem." affair. 1. Deal with possibly multiple issues possibly involving multiple people with the politics that entails resulting in a lot of stress for all involved as any one issue could render it a complete failure. 2. Have extra space you can decide to optimise if you want. You could even have politics and arguments over what to optimise, but if nothing happens it all still works so there is a lot less stress. I pick 2.
- Rule35 6y ago
  Better PMs do this today by having buffer-features they can cut when needed. It'll handle the not-enough-memory issue as well as a meddlesome VP who think you're over-subscribed and wants you to cut to meet your dates. Also, don't forget you're hearing decades-later retellings of someone else's story. I don't doubt that they trickled this extra space out as changing requirements mandated it, but that they kept from doing so until the team had actually reached a certain level of product-maturity and reclaimed all of their own waste first. Remember that the PMs goal is to ship. Them blocking some assets but actually shipping is a success. Better 95% of the product than 0%.
Bost 6y ago
There's a difference between "The server is not responding right now. We're loosing customers.", and "Low resources during product development". Actually the latter may be a case of enforcing premature optimization. So no, it's not the same idea.
- smarx007 6y ago
  I think we are thinking of a different baseline. You are thinking along the lines of "this should run, we can reduce server costs later", I would suggest (if I may) "the app needs to run on any Android device with 2GB RAM". And then you develop a game to run on a 1.5GB RAM phone, expecting that it will eventually fit into 2GB RAM budget.
Cerium 6y ago
In my work it is very common to make the memory map a little smaller than it has to be. If you can't ship an initial version in a reduced footprint you will have no hope of shipping future bugfixes.
- nitrogen 6y ago
  Many years ago I spent a couple of weeks fixing a firmware bug. The firmware was only a few dozen bytes shy of the EEPROM. I just #ifdef'd out a bunch of features to focus on debugging what was broken, but to get the fix released I had to manually optimize several other parts of the code to get everything to fit in the 2MB or whatever it was. Would've been nice if someone had reserved some space ahead of time. Maybe they did, but nobody was around who remembered that codebase.
benhurmarcel 6y ago
https://thedailywtf.com/articles/The-Speedup-Loop https://thedailywtf.com/articles/The-Speedup-Loop
- Blackthorn 6y ago
  My favorite part of that story is how the initial question about overflow should make it obvious that what they're doing doesn't work, but nobody noticed.
  - umanwizard 6y ago
    Is it an overflow because `int` was typically 16-bit in those days?
    - Blackthorn 6y ago
      Yeah.
pjmorris 6y ago
I'd read in 'Apollo: Race To The Moon', Murray and Cox, that the booster engineers had done something similar with their weight budget, something the spacecraft engineers wound up needing. Contingency funds of all sorts are a great thing.
djmips 6y ago
Back in the late eighties a colleague of mine was making a game for the Atari ST and he purposely put in some time wasting code in the game loop so that he had to work against a smaller budget which gave him some contingency for later on when he needed some extra cycles.

295310e0 6y ago

If true, I hate that story. Think of the better art assets that were needlessly left behind. How is it that said block of memory had never been identified by any profiling?

emmab 6y ago
If it would be detected by profiling that does make the technique asymmetric in that it would only stick around if nobody profiled to find it.
- hinkley 6y ago
  Or if you didn’t have an understanding with the sort of people who would run the profiler...
usefulcat 6y ago
> Think of the better art assets that were needlessly left behind. Consider how long it takes to edit or recreate art assets to reduce their size. Depending on the asset, you might be basically starting over from scratch. Rewriting code to reduce its size is likely to be an even worse option, introducing new bugs and possibly running slower to boot. At least smaller, simpler art assets are likely to render faster. This is also the kind of problem that's more likely to occur later in the schedule, when time is even more scarce. Between these two factors (lack of time and amount of effort required to get art assets which are both decent looking and smaller), I think in practice you're actually more likely to get better quality art assets by having an artificially reduced memory budget from the outset.
_carbyau_ 6y ago
I see it as a "Choose your problem." affair. 1. Deal with possibly multiple issues possibly involving multiple people with the politics that entails resulting in a lot of stress for all involved as any one issue could render it a complete failure. 2. Have extra space you can decide to optimise if you want. You could even have politics and arguments over what to optimise, but if nothing happens it all still works so there is a lot less stress. I pick 2.
Rule35 6y ago
Better PMs do this today by having buffer-features they can cut when needed. It'll handle the not-enough-memory issue as well as a meddlesome VP who think you're over-subscribed and wants you to cut to meet your dates. Also, don't forget you're hearing decades-later retellings of someone else's story. I don't doubt that they trickled this extra space out as changing requirements mandated it, but that they kept from doing so until the team had actually reached a certain level of product-maturity and reclaimed all of their own waste first. Remember that the PMs goal is to ship. Them blocking some assets but actually shipping is a success. Better 95% of the product than 0%.

Bost 6y ago

There's a difference between "The server is not responding right now. We're loosing customers.", and "Low resources during product development". Actually the latter may be a case of enforcing premature optimization. So no, it's not the same idea.

smarx007 6y ago
I think we are thinking of a different baseline. You are thinking along the lines of "this should run, we can reduce server costs later", I would suggest (if I may) "the app needs to run on any Android device with 2GB RAM". And then you develop a game to run on a 1.5GB RAM phone, expecting that it will eventually fit into 2GB RAM budget.

Cerium 6y ago

In my work it is very common to make the memory map a little smaller than it has to be. If you can't ship an initial version in a reduced footprint you will have no hope of shipping future bugfixes.

nitrogen 6y ago
Many years ago I spent a couple of weeks fixing a firmware bug. The firmware was only a few dozen bytes shy of the EEPROM. I just #ifdef'd out a bunch of features to focus on debugging what was broken, but to get the fix released I had to manually optimize several other parts of the code to get everything to fit in the 2MB or whatever it was. Would've been nice if someone had reserved some space ahead of time. Maybe they did, but nobody was around who remembered that codebase.

benhurmarcel 6y ago

https://thedailywtf.com/articles/The-Speedup-Loop https://thedailywtf.com/articles/The-Speedup-Loop

Blackthorn 6y ago
My favorite part of that story is how the initial question about overflow should make it obvious that what they're doing doesn't work, but nobody noticed.
- umanwizard 6y ago
  Is it an overflow because `int` was typically 16-bit in those days?
  - Blackthorn 6y ago
    Yeah.

pjmorris 6y ago

I'd read in 'Apollo: Race To The Moon', Murray and Cox, that the booster engineers had done something similar with their weight budget, something the spacecraft engineers wound up needing. Contingency funds of all sorts are a great thing.

djmips 6y ago

Back in the late eighties a colleague of mine was making a game for the Atari ST and he purposely put in some time wasting code in the game loop so that he had to work against a smaller budget which gave him some contingency for later on when he needed some extra cycles.