Quote on SNES programming from Blizzard ex-programmer

[LostTemplar]

I just stumbled upon an article that is basically about the development/history of StarCraft, but there was one part which I found kind of interesting:

In the early years, when our games were programmed for 16-bit game consoles, our programming staff would review soon-to-be-launched Super Nintendo (SNES) titles, and would crowd around games trying to puzzle out how their developers had accomplished some feat of technical magic and derring-do. The SNES was an odd combination of a glacially slow 2.58 megahertz (not gigahertz) processor with a tiny 64 kilobytes (not megabytes or gigabytes) of memory coupled with exotic microchips designed to rapidly blast bits onto the screen — if you could figure out the right incantations to make it all work.

We'd stand staring at a game talking in phrases that only a few thousand folks in the whole world — most of them working for Nintendo — knew anything about. Someone would toss off an idea like "perhaps they're using the hblank interrupt to set the scroll register to adjust the view distance in mode 7″, and we'd all do our best to wrap our heads around that idea, learning a great deal in the process. Our artists and designers would be similarly wowed by their own show-floor discoveries.

That's something I've been doing all the time since I became relatively proficient at SNES programming - playing a game and wondering how the developers achieved a particular effect. Only that today, we can just look at the disassembly without getting into too much legal trouble...

[henke37]

I tend to do the same thing these days, but in other locations.

[Nightcrawler]

Being an engineer by nature, I approach near everthing like that. What does it do? How does it work? Is that efficient? How can that be improved etc. It all started when I was young and asked my Dad how clocks worked. I need to know how everything works now. I spend much time just learning how things work from my electronics to refrigerators to cars. I must know! It's never ending learning!

[FAST6191]

I suppose a +1 to the chorus of the people before me is in order (made all the more amusing when people look at me aghast and mumble "you can't do that"), to be fair I have positioned myself as a reverse engineer so that is probably not as out of place for me as it could be.

I mainly came here to say I still hear of that happening although more often now in regards to engines rather than hardware. Some nice quotes to that effect in http://www.youtube.com/watch?v=RN8m-UjsR50

As for games I fear my sticking to newer PC games and consoles has removed something of the potential for that- more often than not it is not wondering how they twisting rendering hardware to near breaking but what completely nuts formats they used to do something. Granted I would rather that than something like http://catb.org/jargon/html/story-of-mel.html and what I know of hardware methods I value an awful lot but there are times where I feel something is missing.

[Karatorian]

Just gotta say: Hblank interrupts are the bomb. The GBA has automagical Hblank DMA, which is even better.

[furrykef]

I know he was probably speaking off-the-cuff and probably didn't have the opportunity to fact-check, and they're indeed a minor point, but the specs he quoted are wrong:
* The CPU speed was 21.5 MHz (21.3 on PAL), not 2.58, so it was actually ten times as fast as he gave it credit for. The speed he quoted is more in line with the NES, which ran at 1.79 MHz (1.66 on PAL). (EDIT: Wrong. See the following two posts. While he still quoted the wrong speed, it wasn't far off the mark.)
* SNES actually has 128 KB of RAM (plus 64 KB of video RAM).

I'm sure the broad points of what he says are accurate, though, 'cause I've imagined what I'd be doing if I were working in a game dev shop back in the day and that's pretty much how I pictured it, and I bet there was a lot of reverse-engineering of those tricks once they got their hands on the games (though I'm sure they were hush-hush about it because you're not supposed to be doing it).

I'm glad game programming has evolved beyond arcane tricks, though. They're neat to learn about and study, but their necessity was no good for the industry, and had a lot to do with why a lot of old games were crap (think LJN and TH*Q here). Back when id made Doom, it was holy shit, how did they do that?!. Now any kid can make a Doom clone with graphics that eat the original game's graphics for breakfast. (It still takes time and effort, as with making any complete game, but it doesn't require a fraction of the skills John Carmack had.) A lot of people think that's a shame, and I see where they're coming from, but let's look at the big picture here: who are game designers and what are games? Game designers are artists, and games are their art. The ease of modern game programming closes the gap between the artist and his art. That's a very good thing.

It all started when I was young and asked my Dad how clocks worked. I need to know how everything works now. I spend much time just learning how things work from my electronics to refrigerators to cars. I must know! It's never ending learning!

Truly the mark of a brilliant engineer. You might make something big one day...

[LostTemplar]

It's true that that's the input clock speed (which for example is used in full by a few of the cartridge extension chips if I remember correctly) but it actually gets divided by 6-12, depending on what memory region the CPU is accessing. This results in the CPU having effective clock speeds of 1.79Mhz up to 3.58MHz. Yeah, the SNES CPU is pretty much a slowpoke.

You're right with the RAM sizes, though.

[syntax error]

The SNES 65816 speed is 3.58 mhz double of the NES it was planned to be compatible
like the Atari 7800 has a 2600 mode where its downclocked.

[furrykef]

I stand corrected.