1995 Programming on the Sega Saturn

For the Saturn? I think it was well known that documentation was bad. You see where he said about figuring out how to use the second SH2 processor. Not even Sega could figure out how use both of them efficiently(due to poor design) until the end of the system's life so I don't think there would have been useful documentation on that.

The Saturn failed because consumers were burned by Sega's add-on in the past coupled with the fact that the system was expensive and lacked decent dev tools at launch making is difficult to program for.

I've always been impressed by the Nintendo dev kits I've read through and sometimes used.

http://n64devkit.square7.ch/

http://www.chrisantonellis.com/files/gameboy/gb-programming-...

The Saturn was not the best system at the time (not sure if that's what you were implying). The first title I worked on [as a Playstation developer] there was Saturn version being made in parallel; it just couldn't keep up with what I was doing on the PS1 and what the PC guys were doing with the first graphics cards. My memory isn't brilliant, but I seem to remember it had major problems moving textures around, so all textures ended up being half the resolution of the PS1. Our Saturn guy was constantly stressed and actually had a breakdown because the whole process got to him - I know this is mostly anecdotal, but perhaps it gives a sense of the difficulty of the machine.

Sega's follow-up, the Dreamcast, was an excellent machine, and tons of fun to code for. But by that point the PS1 had been so phenomenally successful that very few publishers were committing to Dreamcast titles. A development house I was working for at the time went under because the publishers were waiting for the PS2 and they ran out of money.

Best practices have been evolving since the dawn of programming. Much like today the technical culture at a given organization is the biggest influence on the quality standard for code. There are some places that still consider goto acceptable just like you can probably still find a doctor somewhere who will use leeches.

At the same time many things are considered taboo for trendier reasons that don't necessarily hold water. Many aspects of Functional programming for example were considered heretical during the heydays of Object Oriented programming until the pendulum started to swing the other way.

So what is considered a Taboo practice ebbs and flows with superficial trends in the industry as often as it does for reasons grounded in solid engineering.

Regardless though, the biggest influence on what is acceptable at any given time is the technical culture at an organization.

As somebody who was working in the games industry at the time (as Playstation 1 engine guy), the amount of hoops you had to jump through to make something go as fast as possible was enormous; and sometimes best practice falls by the wayside. The way your game stood out was to do more than the others, I remember hand optimising my C written engine into R3000 assembler and made it fit in 4k so it could fit in the R3000 instruction cache. This would involve manually writing concurrent operations where I'd use the 4 cycles it took to access something from memory (which meant 3 spare cycles waiting) to do other operations. It certainly wasn't pretty, but it broke Sony's own figures for how many polygons could be rendered per frame. That stuff mattered at the time, because doing more per frame meant the game could do more - nobody was going to thank you for pretty code that was slow.

As well as that, the industry was very much a cottage industry at the time, many programmers were self taught and came from an era where one person would make the entire game. I was one of those programmers, and in the days before you could readily find information online about how to do things 'correctly' you found your own way (no Google, no StackOverflow, ...).

Would I want to go back to writing code like that today? No way. But I understand why it happened.

I put 'correctly', because even today we don't know how to write code. It's still an open question, and anybody that tells you they have the 'one true way' needs some extraordinary proof - otherwise it's just arrogance.

My preferred method these days is functional, but after 30 years of programming - starting from a BBC Micro (8bit, 32K of RAM), I am still learning. Mostly becoming a good programmer (in my opinion) is learning to deal with the inadequacies of the wet-ware between your ears. It's all coping strategies for the complexity of the problems we're trying to solve today.

Wasn't it the stuff at the end? With all those magic numbers?

Mick is the author's name. I think it's a joke?