[laumars]

Yeah C was definitely available for the 16 bit but and think I recall C++ being available for the N64 but that was a later generation (and thus released several years later) than the Mega Drive and SNES era.

By the time the N64 / PlayStation / Saturn generation was released, it was more common to expect SDKs. As you say, an expectation likely driven from PC development. SN Systems, being by that point acquired by Sony, would have been excellently placed for the PlayStation dev kits. Unfortunately from the stories I’ve read, Sega were really late in delivering an SDK for the Saturn instead expecting developers to continue to write code in assembly. Which was one of the many issues developers had with that console.

Unfortunately I wasn’t lucky enough to have access to any dev kits for any generation of consoles prior to the PS2 / Dreamcast era. Instead specialising in PC games (and 8-bit micro computers before IBM-compatibles took over) instead. But I have gone back and written some homebrew stuff for the older consoles since. Nothing good enough to boast about on here though.

[kingcharles]

> Unfortunately from the stories I’ve read, Sega were really late in delivering an SDK for the Saturn instead expecting developers to continue to write code in assembly. Which was one of the many issues developers had with that console.

The Saturn launch was a serious fuck-up for developers who struggled to get anything working. I don't know if they shipped a dev kit without a C compiler. It would be a total nightmare accessing all the 3D hardware without C. And they'd had the 32X for a good while before that. They'd definitely given the earliest prototypes of the 32X to SN Systems for them to make their own dev kit. I saw two prototypes there, one they said was called The Fridge as it was the size of a small refrigerator, and another they called the Pizza Box which was the size of a rack mount unit.

[laumars]

> I don't know if they shipped a dev kit without a C compiler. It would be a total nightmare accessing all the 3D hardware without C. And they'd had the 32X for a good while before that

Their complaints were exactly that. Plus it didn’t help that Saturn didn’t really do 3D. It was a dual graphics but both chipsets were designed around sprites. So the Saturn emulated 3D by transforming squares into triangles. Imagine trying to do that in assembly. It’s definitely beyond my capabilities that’s for sure.

Slightly envious (if that’s the right word?) that you got To experience all those dev kits though. The 16 bit era is probably my favourite era in console games (even though the Dreamcast is my favourite console of all time).

[kingcharles]

> So the Saturn emulated 3D by transforming squares into triangles. Imagine trying to do that in assembly. It’s definitely beyond my capabilities that’s for sure.

All my early 3D engines were in software (x86 assembler), this was in about 1990, before any 3D hardware came along. Doing the 3D texture-mapping is actually really simple, even in assembler, once you know how. Figuring out the algorithm was really hard because it was so hard in those days to find out any information about this stuff.

What I couldn't figure out until several years later was how to fix the issue of perspective warping on the textures. Again, the solution is so simple once you know it, but as a kid it was beyond me, until the Internet came along and opened up a world of coding I'd never seen before.

[laumars]

My point wasn’t that 3D is hard. It was that doing 3D on the Saturn was uniquely much harder because the hardware was designed for 2D sprite manipulation rather than polygons. Thus to create polygons on the Saturn you had to transform 2D square sprites into triangles (in a way that’s not to far from mode 7 on the SNES except you have to do it for every bloody sprite and not just an entire layer) and then place them on a 2D canvas at just the right points to make it looks like a connected three dimensional shape.

It was nothing like software rendering 3D in DOS nor anything like how the N64 and PS handled 3D (and they had their own problems too). I’m fact it was nothing like how anyone did 3D maths apart from Segas own engineers and that’s only because they’d already been using those same graphics chipsets in arcade cabinets. Hence where there are so many ports of Sega arcade games on the Saturn.

Segas approach created all kinds of problems when working in 3D that was technically possible in 2D on the same hardware: like the lack of understanding about depth/z-index (since you’re not actually working with polygons), broken alpha blending (which was supported by the hardware but didn’t work properly with transformed sprites because the act of transforming them meant pixels overlapped and thus the alpha blending became uneven) and so on and so forth.

And this is without even touching the usual problems that developers have with SMP. It wasn’t that uncommon for developers to only utilise one processor, effectively halving the capabilities of the machine, just to do away with the concerns of parallel processing.

Then to top all that off, you had to figure it all out in assembly. You couldn’t abstract some of those problems away in C (at least not initially).

While it’s true a lot of developers were still wrestling with how to do 3D in the mid to late 90s, the Saturn was uniquely awkward for 3D. It was a fantastic 2D system but it sucked for writing any 3D games on it.

[kingcharles]

Gotcha. 3D on all those sprite/character based hardware of the 8/16-bit era that didn't allow pixel access to the display buffer is a nightmare.