Thank you for sharing. I recently have begun an interest in programming for old 1990's systems and this provides a great insight into the "best system" of the time and how developers felt about it.
Curious about the dev kit. You mention that Sega provided sample code and there was at least one other dev platform, did Sega provide support and good documentation or did you always basically have to figure everything out for yourself? Is this true for other vendors (ie, Nintendo, Sony and now MSFT)?
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.
The Sony PSX (original Playstation) English dev docs were also pretty bad, IMO/IME. I worked at a game company in 1995-1997 where we were porting our PC title to PSX and to Saturn. I was leading the PSX project which eventually shipped and was an "OK" title (but nowhere near the then state-of-the-art IMO). The Saturn project was eventually cancelled as the team couldn't get enough performance out of the Saturn and really struggled to get much pace of development.
We were using a dev kit that I seem to recall was 3 ISA PCBs (though pictures on the internet now show only 2, so maybe my memory is faulty). There was also a "blue" physical playstation that would boot unencrypted disks, so if we were willing to go through a full CD burn cycle, you could test there, which is how we did QA and potential golden master testing, but most development was on the ISA cards.
Compilation toolchain was gcc-based, and we did almost all of our debugging with printf. :)
Most interesting to me technical tidbit: We did build our own pre-emptive interrupt system to ensure we could run the game physics engine at either 15 or 30 Hz (technically slightly less, as it was on the NTSC vertical blank). Sony support said it wasn't possible... ;)
To the extent Sony won that round of console wars, I don't think it was on the quality of documentation, at least not the English translations.
I guess you'd feel that way if you came from a PC background. For console developers, Sony's SDK for the PS1 at the time was pretty good compared to the alternatives.
The technical information was decent. The English translation was rough at times. I can't recall the exact quote now, but my favorite was documentation around the interrupt handling area (IIRC). It went something like, "It must never be forgotten to fail to not enable the XYZ..." It was 3 or 4 negatives and utterly ambiguous as to what was meant. In cases like that, Sony support in the US was willing to run down the original Japanese text and re-interpret it for us, but those often took 3-10 days for the cycle to run its course, especially if there was no code demo to exercise that particular feature/subsystem.
The SDK was good. He's complaining about English docs, which is pretty valid if you look at the Genesis and Nintendo's docs. Especially considering they had to outline brand new 3d functionality, while the sprite/blit engines on all the 2d consoles were pretty similar (here's an address in RAM/VRAM, blit it to this position, vscroll this far, load this tile from this address, etc).
I will readily agree to the /expensive/ part. I distinctly remember, as a kid, looking at that system on the highest shelf in the game store in the mall, and thinking that it cost a LOT of money.
Checking with the internet, USD 399/449 (a game included), but that's in 1995 dollars. The CPI places that as being nearer to 625 USD today!
It puts complaints about VR headsets in a different light when you think about how much those consoles you loved as a kid cost after adjusting for 20+ years of inflation. When you compare how expensive a NES was in real terms at launch with how little you got in terms of possible experience, it drives home how much computing has advanced over the years and how high (spoiled?) peoples' expectations are now that they bitch about Oculus costing $700 or whatever.
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.
>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.
IIRC because of the way the Saturn did texture mapping, all texture coordinates would be forced to be axis aligned quads (like traditional 2D sprites), which caused big problems for games coming from other platforms that had more freeform texture atlases. That could be at least a part of why your team had problems with textures.
Funnily enough I just found an interview somebody must have done with me years ago [1]. I forgot I'd done it. There's a screenshot of the Saturn version. If you click through to the 'Saturn Power' magazine scans you'll see the Playstation screenshots [2] (slightly offside that the PS screenshots were sent as an example of the Saturn version!) - it's pretty obvious that the Saturn version looks terrible compared to the PS
Here's my quote re: the Saturn version:
"However the Saturn version was lagging behind quite badly - the textures looked pretty awful because they had to be down-sampled to fit in the smaller texture memory, and the geometry engine was struggling due to the more limited ability of the Saturn"
I've been experimenting with developing homebrew with this system as it's me and my band's personal favourite.
As for the second SH2, by reading the official SEGA documentation, you can clearly see there's some genuinely awesome functionality in there, that, if used, could definitely offset a whole bunch of tasks in simple ways, such as rendering and managing 3D objects, and a whole bunch of other neat stuff.
I imagine this is how Sonic Team managed to pull off NiGHTS Into Dreams..., Burning Rangers, and whatever have you.
This is all well and awesome from a programmer's perspective, but I can't imagine, with low sales figures and a high initial-level learning curve, it would've been financially feasible to produce high-quality titles for the platform that utilized these features.
The comment at the end about this being acceptable leaves me wondering. I started programming in 2013 and doubt there was once a time where "bad" coding was ok. Surely there was always someone on the other side of the fence. I suppose when it comes down to it, there is getting it done and getting it done today.
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.
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.
https://www.youtube.com/watch?v=6-YxOpZ7mDo
For anyone in doubt of the Saturn's capabilities when programmed for properly. It is said this was done with the aid of the 4 meg ram expansion cart and was nearly completed when it was cancelled due to the early demise of the Saturn.
Yu Suziki has always been capable of doing amazing things with Sega's console's. The resolution of Virtua Fighter for the Saturn for example which leveraged the second SH2 processor for some duty and Ferrari 355 Challenge for the Dreamcast
Curious about the dev kit. You mention that Sega provided sample code and there was at least one other dev platform, did Sega provide support and good documentation or did you always basically have to figure everything out for yourself? Is this true for other vendors (ie, Nintendo, Sony and now MSFT)?