A pretty common trick that was part of game programmer lore back in the PS2 / Xbox era was to have a large static array hidden away in some code file somewhere. When days before shipping you couldn't quite fit the release build in to memory this allowed a heroic programmer to miraculously 'find' a few hundred extra kilobytes of memory by reducing the size of the array by just enough to fit.<p>There was a less common variant of this for finding some extra performance by reducing the iterations of a loop doing no-ops somewhere in the main game loop.
"When finishing a level, the game would reboot the console and restart itself with a command-line argument(the name of the level to start) ... into the next level. Voila, the perfect(?) way to clear all memory between levels."<p>Well, that's basically how most websites work, lol
Whenever I think, "Thank goodness the limited memory days are behind us", it pops up again and again. Sure, you can buy a new iMac Pro with 128GB of RAM(!!) and smartphones regularly have 8GB available, but the increasingly popular IOT devices and smart consumer hardware (like streaming media boxes, etc.) try to limit the BOM cost and thus limit memory as much as possible. Tiny memory leaks become an issue, or random crashes from wonky media codec implementations, etc.<p>I think the skills (and hacks) that used to be useful only to game developers and OEMs are now going to be needed by a much wider audience of devs.
<p><pre><code> When finishing a level, the game would reboot the console
and restart itself with a command-line argument
(the name of the level to start) ... into the next level.
Voila, the perfect(?) way to clear all memory between
levels.
</code></pre>
OH MY<p>At 22 years old, this is one of those moments where I'm in awe of the strange issues and workarounds that existed merely ~5-10 years ago which I'll probably never have to deal with. Very funny!
Problem solving within a constrained system. It’s fun stuff and I always find it amazing how adversity and particularly time pressure can bring out the ingenuousness in people.<p>I guess wartime inventions are possibly an extreme example (google Hobart’s Funnies some time for some good clean ingenuity), but shipping console games to a deadline seems to have a similar effect.
RAM usage still matters a lot. Not only because consoles, also because RAM usage often translates to storage bandwidth, and CPU-GPU bandwidth.<p>Some of the tricks still apply today. For example, modern GPUs support all kinds of weird texture formats. Here’s a link for PC: <a href="https://msdn.microsoft.com/en-us/library/windows/desktop/hh308955(v=vs.85).aspx" rel="nofollow">https://msdn.microsoft.com/en-us/library/windows/desktop/hh3...</a> Other platforms have conceptually similar stuff.
> Ultimately Crash fit into the PS1's memory with 4 bytes to spare. Yes, 4 bytes out of 2097152. Good times.<p>Wow. I am absolutely <i>blown away</i> by this.
Here's another interesting story from the DOS days:<p><a href="https://blogs.msdn.microsoft.com/larryosterman/2004/11/08/how-did-we-make-the-dos-redirector-take-up-only-256-bytes-of-memory/" rel="nofollow">https://blogs.msdn.microsoft.com/larryosterman/2004/11/08/ho...</a>
Makes me wonder why Rust isn't popular with game devs. Wouldn't Rust's borrow checker and resource management at compilation time make most of the described memory reclaiming issues obsolete?
This is giving me fond memories of things I had to do or had heard about from colleagues:-<p>- To improve game loading speed of a CD - Load level on PC from hardisk, log all filenames loaded to a txt file and then use that to order the files when writing to the final CD.<p>- Load all files into PS1 devkits memory, write out all memory in a binary blob to the harddisk, burn that memory image to CD to use for fast level loading (just load it in a single fread(..).<p>- have separate executables for different levels which had different features, to save memory.<p>- Write a small block allocator to make <256byte allocations quicker and more efficient.<p>- Find a tiny piece of memory in the PS2 IOP chip which doesn't get wiped on a devkit reboot (for some reason) and use that as 'scratch' space to write log messages to track down a hard to repro crash that rebooted the kit.<p>- Change the colour of the tvs border to different colours to track down a race condition that only existed on burnt disks and we had no debugger. The border colour setting code was quick enough to not affect the race condition, so choose some places in code to arbitrarily set to certain colours, burn the disk, test it, when it crashed see what colour the border was, then put some more colours in possible areas, re burn the disk and etc (so basically binary search the code areas using border colours).<p>- Use compiler optimisations settings for 'size' instead of 'speed' as the smaller executable code size meant you stayed in the DCache more which actually made the code quicker than compiling for 'speed' which resulted in generally larger code.<p>- Burn a master CD image for publisher, get the game ID code wrong, open up the disk image file in a hex editor and manually edit it rather than go through the whole build process again.<p>- have no build machine (Gold master got made off whatever code the leads machine had).<p>- Use sourcesafe (no atomic checkins....)<p>- Use a few batch files and a directory share for 'source control' of art assets.<p>- Have values in config files we gave to games designers which did nothing (this was accidental but they swore changing them made a difference to the game).<p>- Have a advertising deal with a company to have a special cheat code in the game to unlock some stuff, the programming code that does this has a bug that ships that means you have to alter the code incorrectly to get it to work....so tell the company that 'Your code was too easy so we made it harder'.<p>- Have a developer write code like this as he swore that passing a extra parameter would have slowed the game down:-
(psuedo code, but original was in C)<p>Do stuff(int val)<p>{<p>foo * bar;<p>If (val<10)<p>{<p>bar = gStuff[val];<p>}<p>else<p>{<p>bar = (foo* )val;<p>}<p>}