Hacker News new | ask | show | jobs
by Jetrel 1630 days ago
I was really surprised to discover that quite a few games in the SNES/Genesis era actually weren't written in assembly. They were usually "touched up" in assembly; there would be inlined assembly stuff for a lot of core loops and hardware interaction, but apparently quite a few games actually used "high level languages" for large tracts of the code. I'm merely relating hearsay here, but at least one primary source (Secret of Evermore) suggested this was the case.

The thing is that once it's compiled down to a final rom, all the scaffolding used to build it is gone, so there's so little evidence left that it's pretty plausible for people to think it was just done completely in assembly (particularly since there's significant evidence of hand-crafted assembly routines in such a product, since they did that for parts of it).

I think there's a lot of "transposing of knowledge" there, where people know how 8-bit games got built, and assume it was the same for the 16-bit era, but I suspect the 16-bit era was where the transition away from that started, so there was a bit of both.

1 comments

As I said, C code did exist but it was slower so it wasn’t the norm. I don’t know of any other languages being used on those systems (I think C++ was supported on the following generation of consoles, albeit SDKs took longer to be released on some consoles than others). If anyone knows of non-C languages being used I’d love to hear about it.

Back then compilers weren’t as good at writing optimised machine code as they are now and the consoles of that era were built with assembly in mind anyway so it was an easier job writing assembly for them than it would be on modern architectures.

That all said, it seems to be a lot more common these days (ie with the homebrew community) to use higher level languages even on easier platforms like the GameBoy.

I had both the official Sega dev kit and the SN Systems one. IIRC they both came with a C compiler. I don't remember any C++ compilers for the 16-bit consoles. C++ was just coming into PC game development at that time. I was in the industry then and I definitely used some C++ code for PC game development.

I once called up SN Systems as their office was down the road and asked if I could visit (this was about 1996) and they were such a nice bunch of people. They had very early prototypes of every console stacked on a back wall. Stuff that would not see the light of day for at least another 20 years. Early PlayStations, 32X, Saturns, Megadrives, Mega CDs. I was looking at a Mega CD dev station and they just handed it to me and said I could have it O_O. I think they gave us a couple of SNES and Megadrive dev kits too. They said they would have given us boxes of the things but they'd just thrown them out yesterday and the rubbish had already been collected.

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.

> 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.

> 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).

> 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.

The Koei strategy games on NES ran in a bytecode virtual machine. The actual game program would be written in C and compiled to the virtual machine. This allowed them to use the same codebase as the computer versions of their strategy games. As for why they use a VM rather than compiling to 6502, my guess is it saved ROM space (for example a 16 bit memory + memory add would be one instruction instead of 7)

More information: https://forums.nesdev.org/viewtopic.php?f=2&t=15931

There were a few game engine that adopted this approach (though I can mentally visualise the games, my mind has gone totally blank trying to name said engines). I wouldn’t go so far as to say it was common practice but it certainly was a technique used by a few game developers.

A lot of the time is was as much down to portability as anything else. However I’m not that familiar with Koei (aside having a few titles as a gamer) to comment on their design decisions.