Gamasutra: The Art & Business of Making Gamesspacer
Dirty Game Development Tricks
View All     RSS
October 23, 2014
arrowPress Releases
October 23, 2014
PR Newswire
View All

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Dirty Game Development Tricks

June 24, 2013 Article Start Previous Page 2 of 4 Next

Jamming the cartridge

Michael A. Carr-Robb-John, Monolith Productions

In 1993 I was finishing off Desert Strike; I was doing the conversion from the 16-bit Mega Drive / Genesis to its humble little brother, the 8-bit Master System. The game was exceeding the desired cartridge size by about 12K, and going to the next size cartridge was out of the question. Today, 12K sounds incredibly small, but back then it was a major deal. During development, I had budgeted and planned all the sound and graphic resources and they were within their limits. The only section I hadn't been so strict on was the code. In those days, games were written in assembly language -- in this specific case, Z80 assembly -- so I had only one option left. I spent a week going through and finding redundant code and rewriting things to use a smaller memory footprint (usually at the cost of being more processor-intensive.)

By the time I had finished, the game fit onto a cartridge with just 98 bytes! The game was burned onto ROM and tested for a few days by the chaps in QA before being submitted to Sega for certification. Unfortunately it didn't pass on the first time, and the required fixes pretty quickly used up those 98 bytes. I think when we did publish, there were only 6 bytes free!

The Dalton Allocator

Jonathan Adamczewski, Insomniac Games

Toward the end of one project, we discovered that after playing through the game for many hours, movies would not trigger when they were supposed to. Fragmentation within one of our memory allocation heaps had made it impossible to reliably allocate the large blocks of memory that were needed for full-screen movie playback.

We needed to find a way to be sure that we could always get the memory we needed. However, it was too late in the project and too risky to consider defragmentation of the heap, we didn't have enough spare memory available to set aside exclusively for movie playback, and taking space away from other systems at that stage was impractical.

It was clear that when movies were playing, there were many other systems sitting idle, so we gave some consideration to "borrowing" memory from them. However, these other potential sources were either too small, or else also suffered from the same kind of fragmentation problems that we were already seeing. There was plenty of free space available for the GPU, but for various reasons we could not use that for the movie-playback buffers. So we needed another source of space.

While looking into another problem, a particular pattern of memory allocations within our main game-asset heap stood out: When the game started up, a number of assets were loaded from disk, and once in memory were never modified. Some of those assets were very large. None of them were needed while a movie was playing.

This gave us an idea: What if we were to copy the contents of one of the larger asset files to somewhere else in memory? The GPU's memory would work just fine as a place to temporarily stash the asset, and then we could temporarily reuse the space in the asset heap for movie playback, copying the asset data back from GPU memory when the movie finished.

So that's what we did. We chose the largest set of animation clips used for one of the game's heroes (named Dalton). The animation system was switched off, animation clips copied into the GPU's memory space, and the memory handed to the movie-playback system. At the end of the movie, the animation data was copied back to where it belonged, the animation system restarted, and the game proceeded as if nothing horrible had happened. The implementation ended up being fairly straightforward, though the process does span a number of frames to ensure that all the systems involved are safely synchronized with each other through each step of the process.
The memory for the movie system has since been described as coming from "the Dalton Allocator" after the character whose animation clip memory was usurped.

(I've since discovered that there's some history of this kind of thing at the studio -- of both stashing random things in GPU memory, and failing to set aside enough space earlier in the project...) 

Article Start Previous Page 2 of 4 Next

Related Jobs

WB Games
WB Games — Kirkland, Washington, United States

Principal Technical Artist
Demiurge Studios, Inc.
Demiurge Studios, Inc. — Cambridge, Massachusetts, United States

Senior Software Engineer
CCP — Newcastle, England, United Kingdom

Senior Backend Programmer
Guerrilla Games
Guerrilla Games — Amsterdam, Netherlands

Animation System Programmer


Juan Belon Perez
profile image
And that's why I admire Insomniac team

Daniel Accardi
profile image
Chris Pruett, marry me?

Will Buck
profile image
That is one dedicated husband, bravo to you Chris!

Aaron San Filippo
profile image
The (S)self exploitation one from Garret is awesome and scary at the same time. I worked with a guy who came from Insomniac before, and he was always going on about fixed point math hacks and stuff and some of the horrors he had seen before. Now I can appreciate all of that a bit more.

Koray Hagen
profile image
I only wish there was more. Absolutely hilarious.

Amir Ebrahimi
profile image
Re: The Dalton Allocator, I did something similar at Naughty Dog because we had to fit code and art into a 3MB (IIRC) memory block and quite frequently artists would go up to the very limit and us programmers would be scrounging around for every KB to get the level to fit within memory. Frustrating? Yes. How to solve? Mis-report the memory by 256KB :)

Aaron San Filippo
profile image
I've heard similar stories before - reserve some "shipping time" memory and don't tell the art team about it. Very efficient solution to the problem ;)

Joseph Moore
profile image
Yeah, that's a very common technique. On a DS title I worked on, we reserved a rather sizable chunk of memory on the side as a "just in case" buffer. Whenever a level designer needed a bit more memory for levels, an artist a bit more for textures, or a sound designer a bit more for audio, we could dole it out. (We, of course, made a great show of scrounging and optimizing to obtain the requested memory.) By the end of our development cycle, the buffer was nearly gone.

Brian Schmidt
profile image
Joseph--that's funny...
When I was doing Genesis/SNES music and sound, I'd do the same thing, though in reverse. My system was designed to submit a single black-box binary file to the developer. I'd always make sure my first delivery filled up my entire audio budget, even though most of the binary was empty. That way, I could "save the day" by being able to add in sounds late in the game, or by "optimizing" my audio to give some back to the developer...

Jane Castle
profile image
@Joseph Moore..... lol! You are like a memory banker loaning out memory.....

Sean Sanders
profile image
I love this series! That (s)Elf manipulation trick is the nastiest / coolest.

The "Dalton Allocator" sounds familiar. I discovered when working on a PS3 game that Audiokinetic, the makers of the audio engine we licensed, actually had a recommended knowledgebase article on streaming audio stored in GPU memory, which we exploited to great effect.

y h
profile image
hehe, very nice material, inspiring in many levels !

and I rise my hand to ask for more of these !

Leroy Sylva
profile image
I chuckled at the HR hacks story.

Jacob Pederson
profile image
I actually did something similar to Chris Pruett, with a Diablo 1 on PS1 save file, successfully moving it from emulation to the real system by copying headers.

Reverend Ted
profile image
The PC version of DRIV3R has a bug (or it seems like it has a bug) where the Cheats menu doesn't unlock after beating the game. To this day I have only a vague sense of how I managed to figure out where in the ProfileData the "triggers" were stored, but I managed to locate and unlock them by hex editing the ProfileData file (a component of the DRIV3R savegame system). Felt pretty proud of myself for that one.

David Hawisher
profile image
The EULA exploitation is HORRIFYING. And clever.

Aiden Eades
profile image
Jamming the cartridge isn't really a dirty programming trick though, it's just optimization, sure it's not optimiation in terms of speed, but it's still a form of optimization.