9 ms·
A RAM Edition of Dirty Coding Tricks
- tomalpha 9y agoProblem 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. 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.
- warent 9y agoWhen 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. OH MY 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!
- dmoy 9y agoMaybe never had to physically blow air on a video game to make it work either, ha.
- cosarara97 9y agoI bought a nintendo switch with zelda, and the cartridge wasn't detected the first time I put it in. Took it out, blew a bit on it, back in, working perfectly! Some things never change.
- golergka 9y agoIt's Nintendo. I wouldn't be surprised if they designed cartridges this way on purpose now.
- wging 9y agoYou'll run into today's equivalent soon enough :)
- fnl 9y agoMakes 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?
- applecrazy 9y agoThese stories are from games made in the late 90s to early 2000s. Rust didn't exist then.
- fnl 9y agoYes, obviously. Yet, I'd assume space/memory problems persist today to - games are always pushing the PC hardware envelope.
- royjacobs 9y agoYou can't do resource management at compile-time for games that have 50gb of assets. Also, Rust may help with accidental memory leaks, but you still have to deal with things like heap fragmentation.
- fnl 9y agoInteresting point. Normally, your programming language can do little about fragmentation other than requesting a better allocator, if available (Windows?). Makes me think, maybe Rust's model would allow it to plan for better allocation requests? (Not saying Rust does that, just came as an idea.)
- MaulingMonkey 9y agoThe main advantage I see Rust having here is making it a little easier to (ab)use the stack for temporary stuff in a way that can be verified to be safe. Nothing you can't already do in C++ at the expense of the occasional heisenbug. Games often create their own allocators for a variety of reasons (specialized allocation strategies for speed or fragmentation reasons, adding debug statistics, enforcing memory budgets for (sub)systems, etc.) - although that's not terribly OS or language specific.
- k__ 9y ago"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." Well, that's basically how most websites work, lol
- evincarofautumn 9y agoAs long as the process is acceptably fast, nuking & restarting (with an appropriate amount of isolation) is a fine approach to many things that would be harder or less efficient if done the “right” way. Memory pools and “let it fail” architecture in Erlang come to mind; and there’s a practice sometimes seen in Forth, where you ensure that the codebase itself is always small enough that it can always be easily rewritten, for example if requirements change enough that incremental development would be harder.
- k__ 9y agoI do it like that on mobile too. New screen? Okay, lets throw everything away. As long as performance is okay, I don't keep stuff around in memory.
- Cthulhu_ 9y agoServerless architecture right there. That or PHP and similar tools - at least back in the good ol' days. But functionally, it's still that a PHP scrip runs a whole application for the duration of one request, then everything is wiped and the whole thing is restarted for every request. I mean it can work and it's a viable tactic if startup time is fast enough.
- russellbeattie 9y agoWhenever 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. 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.
- gizmo686 9y agoTo add on to this, I am currently working on a project where the only source of persistent storage is [0], which offers 64B of general purpose SRAM. It is a $0.70 low power clock with built in support for battery backup. Our main processor has more memory, but that goes away when we loose main power. Still, 64B should be enough for everyone. [0] http://www.mouser.com/ds/2/268/20005010F-737592.pdf http://www.mouser.com/ds/2/268/20005010F-737592.pdf
- Cthulhu_ 9y agoI love tiny things like that, there's already so much you can do with it. I wrote a thing way back when, probably a TI chip or something, which had like 300ish? bytes of memory. It got commands from a serial in (which was a bluetooth device, commands were sent from a java application on a laptop), the commands were a simple self-made thing which was a command (two numbers) and an argument (like, "set speed to 10"). That then controlled a PWM for the engine and things like that. RC boat with a few hundred bytes of memory. I'm reinventing all that now with using raspberry pi's and arduinos and such. I just got an EPC32, which is a $5 device that should have wifi and bluetooth and such built in already.
- TeMPOraL 9y ago> 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 I think you're underestimating the accretion of software bloat. You remember the days when you did exactly the same things, exactly as fast, with 1GB machines? 512MB machines? As long as devs don't give a fuck (er, they make "professional decision" of optimizing dev time (over product quality)), the days of limited memory are not going to be behind us.
- mattnewport 9y agoA 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. 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.
- bastawhiz 9y agoSadly this usually works only once, especially if it's one person doing it. I used to work on the performance team at a Bay Area company. One of the things we did to keep our JavaScript bundle sizes under control was introduce a "ratchet". There was a threshold, enforced by CI, that you couldn't let the bundle size exceed without getting in touch with us first and figuring something out. [0] This worked wonders for a while, until a few different teams were starting new feature development. At that point, the ratchet was forcing teams to pause their feature development to do cleanup work, which made the PMs very unhappy. Engineers got salty because they would remove dead code, only to find that another engineer had gobbled up the space they'd freed before they could land their own commit. Engineers started working around the ratchet by hoarding dead code and disguising it to look "not dead" so that it could be easily removed later when a few dozen kilobytes were needed. There were many thing that weren't good at this company, and the culture around ownership of the shared codebase was definitely one of them. I'd like to think that there are plenty of teams that don't have this problem, but I'm inclined to think that it's human nature to subvert these sorts of things by default. [0] This was necessary because of the volume of tech debt. Teams/engineers had a bad habit of building new things, then not cleaning up the stuff the new things replaced. At one point, we estimated that over a third of the JavaScript was dead code. Some teams had gotten to the point where the codebase contained >2 versions of their product, while only one of them was physically accessible to users.
- mattnewport 9y agoBack in the era where this was somewhat common on games it only had to work once. In those days you burned a master for a console game and once it shipped that game was done. There were no zero day patches (or any other kind of patches) and no updates to the game once it shipped. Often it would be the lead programmer on the game who put this array in and it wouldn't necessarily be known about by everyone. It wouldn't have worked well if people were constantly grabbing bits of memory from it during development. It worked because it was a 'secret' and its use was reserved for shipping.
- torgard 9y ago> Ultimately Crash fit into the PS1's memory with 4 bytes to spare. Yes, 4 bytes out of 2097152. Good times. Wow. I am absolutely blown away by this.
- Nition 9y agoIf you like that, you have to read this (in 13 parts): http://all-things-andy-gavin.com/2011/02/02/making-crash-bandicoot-part-1/ http://all-things-andy-gavin.com/2011/02/02/making-crash-ban...
- bryanlarsen 9y agoI've worked on a couple of projects that only had a few bits of free ROM left. Not really all that surprising, you stop optimizing for space once it fits. One of the projects was heavily squeezed to make it fit, the other didn't need much squeezing, but you couldn't tell the difference by looking at the free space.
- kaushiks 9y agoHere's another interesting story from the DOS days: https://blogs.msdn.microsoft.com/larryosterman/2004/11/08/how-did-we-make-the-dos-redirector-take-up-only-256-bytes-of-memory/ https://blogs.msdn.microsoft.com/larryosterman/2004/11/08/ho...
- Const-me 9y agoRAM usage still matters a lot. Not only because consoles, also because RAM usage often translates to storage bandwidth, and CPU-GPU bandwidth. Some of the tricks still apply today. For example, modern GPUs support all kinds of weird texture formats. Here’s a link for PC: https://msdn.microsoft.com/en-us/library/windows/desktop/hh308955(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/hh3... Other platforms have conceptually similar stuff.
- throwmeaway32 9y agoThis is giving me fond memories of things I had to do or had heard about from colleagues:- - 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. - 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(..). - have separate executables for different levels which had different features, to save memory. - Write a small block allocator to make <256byte allocations quicker and more efficient. - 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. - 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). - 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. - 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. - have no build machine (Gold master got made off whatever code the leads machine had). - Use sourcesafe (no atomic checkins....) - Use a few batch files and a directory share for 'source control' of art assets. - 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). - 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'. - 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) Do stuff(int val) { foo * bar; If (val<10) { bar = gStuff[val]; } else { bar = (foo* )val; } }