Were any commercial SNES games written in C?

Although many (most?) commercial Sega Genesis games were written in 68000 assembly language, some (including Ecco, The Lion King and Sonic Spinball) were written in C.

Are any commercial SNES games known to have been written in C (or another compiled language), or are they all believed to have used 65816 assembly?

Yes, some were written (at least partially) in C, was that all you wanted to know?

I was asking myself the exact same question.

What matters to me however is not a yes/no answer, but a clear and accurate reference to : Game X was programmed with language Y.

Do you have any examples of games which used C?

Is there a way to know (or to estimate) whether a game made significant use of C, based only on a ROM dump?

Possibilities:

• If you see C format strings, then C was likely used. NovaSquirrel found (at least a subset of) C format strings in Koei games.
• Or if you see the calling conventions of a particular C compiler popular at the time, then C was likely used.
• Or if you see the characteristic unoptimized instruction sequences of a particular C compiler popular at the time, then C was likely used.

Which of C compilers were popular at that time ?
What was their calling convention ?

How does one identify such a string?

The only 65816 C compilers I know of from back then was ORCA/c, the zardoz toolchain and TMorita's lcc retarget (which used ORCA/m for the assembly/linker backend).

They (TMorita) supposedly used C for Zombies ate my neighbors. There was also this obscure japanese puzzle platformer that blatantly used the zardoz compiler (bought by wdc, called wdc816cc these days).
I've heard rumors that square used C in some of their later titles, still haven't seen anything that confirms this though.
Ballz 3D might have been written partially in C, it does a lot of things that imply that C was used.

Yes, it's possible, why do you want to know?


I don't think C strings indicate that C was used, C strings end with $00 and sometimes contain modifiers like %d and %s etc. This is a pretty useful format and I'd think assembly programmers back when used it as well.

For the avoidance of doubt, by format strings I meant strings with format specifiers like "%d" and "%s" in them. These are what Nova found. True, an assembly language implementation of a subset of sprintf() called by pure assembly language could also use format strings. But Koei was trying to target multiple platforms with different instruction sets.

So let me add a fourth heuristic:

• If the game came out on in several instruction sets (68000, 65816, and whatever the F else), and its code isn't tightly optimized, and it doesn't use a bytecode platform such as SCUMM or Z-machine, C was likely used.

I heard Chrono Trigger was written in C, but I don't remember where I heard it and it's probably false. If the Lion King on the Genesis was written in C, does anyone know if the SNES version is? (I don't know much about C, but this would probably allow for an easy conversion, if I'm right.)

I do not know the inner working of the game, but this was maybe about the DS or the Playstation version.

Of note that a game programmed in assembly would be more likely to use sentinel values (a non-character value, e.g. 0xFF) than stuff like "%d" in strings, so finding printf-style formatting can hint at it being C (if the program also uses the stack heavily, chances are that's indeed the case). Also having a subset means nothing since games made in C for those consoles usually would have their own implementations of the standard functions and even then only the stuff that was needed (IIRC Sonic Spinball only implemented three format specifiers, for example - yes, I know that isn't SNES but point stands =P).

It was the SNES version I'm fairly sure. Going purely off memory from something discussed like 15 years ago: there are printf()-style strings found within the game code, and some reverse-engineering done by Internet people (whose names I forget) implied a lot of the methodology used looked C-focused, i.e. heavy use of stack-based addressing if I remember right, so that functions/etc. can get called by pushing pointers on the stack + accessing them within the subroutine.

Chrono Trigger is also one of those games where Square did stuff like lda #$2100/tcd just so they could access SNES MMIO registers via DP addressing.

I found out what the game written in C was called, it's Sutte Hakkun. If you don't have wdc816cc and want to see what compiled C code for 65816 might look like, have fun.

Sorry but no, there is no printf()-style strings in the SNES version of CT. The game doesn't even use ASCII to begin with, and a search for %d or similar in the ROM does not reveal anything.


Source, please.


This would rather point to hand-optimised assembly, although this is not necessary contradictory with another part of the game being written in C.

Many games actually may be coded in C, I heard japanese devs mostly used C and that even SuperFX-2 title Doom coded in C with no assembly involved what so ever. Makes sense for me, if some game's slowdowns too much.

So that's why it looks the way it does. I can understand the SNES part pulling a port down (video bandwidth) but there are definitely plenty of things that are the actual SuperFX's problem. Not having texture mapped floors is definitely not the SNES's problem, and I would have thought that a 20Mhz processor would be able to handle a seemingly perfect port of Doom, but apparently not. What kind of specs would your computer need to run Doom back in the day, because they must have had to be pretty good...

I remember running Doom on my 386DX-40 with 4MB of RAM. It was playable, but it was definitely not running at full speed.

EDIT: Found a video of it running on a 386DX-40. It's pretty slow in big rooms with lots of enemies.

Doom would (barely) run on a 25 MHz i386 PC with 4 MB of RAM. A 33 MHz i486 PC with 8 MB was recommended. (Source, via Google doom system requirements)

I think I ran the demo ... for hilarity ... on my 386sx/16 with 2MB of RAM. I believe it worked, although I think had to drop the resolution to zoomed in all the way? I forget.
Of course, the thread that tepples linked implies that it tested for and refused to run with less than 4MB of RAM, so maybe my memory is wrong.

Well, dang... The GBA can run a seemingly perfect port of Doom 2, (censorship doesn't affect processor speed ) and it definitely doesn't have anything like 4 MB of ram. I guess the GBA's small resolution helps cuts back on CPU power. (Which I know isn't directly related to ram, but still.) Do you know what resolution Doom was running in in the video? I know the GBA technically has a 32 bit processor, but from what I've heard, it takes quite a performance hit when accessing rom when in 32 bit mode, (If I remember correctly) so it's better to just use Thumb which is 16 bit. Of course, CPU speed isn't everything as some processors are more efficient than othersI'm looking at you, Stef.

Three things going for the GBA are IWRAM (32K of zero wait state memory, almost like a software-defined cache), execute-in-place ROM (less need to swap textures and things in and out of RAM), and advances in compiler technology for the ARM and Thumb ISAs.

Okay, as customary, I'm not doing anything to really improve the conversation, but I got a couple of good laughs after reading the NOW ONLY prices: (And I'm sure these would be twice as expensive in today's money.) https://books.google.com/books?id=v9TVJ ... MB&f=false
(I didn't know it was that costly to play a game of Doom. )

Random comment in passing for @Espozo: if you're ever willing to try learning C, I'd be happy to buy you C Programming: A Modern Approach, 2nd Edition by K.N. King, which is worth every cent. It's probably the best C book I've ever read; extremely good visual diagrams, layouts, clear explanations, and great real-world examples. Having some assembly background (meaning conceptually) really helps when it comes to understanding C, especially pointers (the #1 thing people have trouble grasping -- but assembly programmers tend to say "oh it's just indirect addressing, got it" and that's the end of it), and some of the syntax (no argument, it get a little hairy at times). Just let me know + get an Amazon wishlist + add it and it'll appear.

And as for those PC prices: I'm the one laughing. Those really aren't very expensive. Shall I scan or photograph the sales receipt for my Apple IIGS, circa late 80s? Or maybe point you to something like this?

Know your roots. And in knowing your roots, realise how ridiculously affordable computers/technology is today. What you get now, for how much you pay now, is pocket change compared to then.

But it has ROM it can access directly (what's the size of GBA Doom's ROM?). Remember the RAM requirement deals with the fact that PCs have to load everything into RAM to be able to do anything at all =P

Back on the question of the thread title: does anybody know if the Mortal Kombat ports look like they're made in C? (I know the Mega Drive ports are, in fact I wouldn't be surprised if they just used the arcade code which is also in C)

I'd love to see that GSU C compiler (ie. what you've heard isn't worth jack without sources or critical thought).

Wrong - I had a strong assembly background when I learnt C, but I still had major trouble with pointers. It's a fact the syntax of C becomes awful as soon as you start using pointers (and you HAVE to be using pointers to do anything in a meaningful way in C), the language discourage the use of pointers when in fact it's a key element of the language.

That being said I never had any problem to the concept of a pointer thanks to my assembly background, but using them in C is at first a nightmare until you figure how everything works out.

If you don't see what I mean and want me to provide concrete arguments I'll be happy to provide them but I doubt it's here the place to do so.

I'd love to see any survived GSU assembler, not mentioning C compiler.

Can you cite something about this? Just saying "I heard this" doesn't really help. Finding clues to a game being compiled is more useful than just guessing or going off what some unknown person may have said. Unless they actually cited some evidence to support their claims.

I'm really septic about the fact that Doom on SNES was coded in C, is there any C compiler for the SuperFX in first place ? I don't think so...

Here's something I found from http://en.wikibooks.org/wiki/Super_NES_ ... X_routines, although I'm not sure how useful it is:

Unless by "compiler" they mean "assembler".

I would make a whole lot of sense, explaining how programmers were capable of making such a mess, but still were able to somehow finish the game on schedule. That's the thing about programming, if you try to rush through it, you're bound to get stuck later on.

There's no official argonaut or nintendo C compiler for the GSU, but iirc carmack has dabbled in compiler development so it's certainly a possibility.
I might skim through it at some point and see if there's anything indicative of compiler (ab)use.

Compiler, or assembler? Who wrote this article, are they active on this board?

Before QuakeC I don't think Carmack did any compiler development that saw use, and more importantly he was always quite ruthlessly chasing performance rather than some more academic higher level "elegance". Most of the original Doom rendering code is x86 assember.

Also, the SNES port was programmed by Randy Linden of Sculptured Software using their own SFX2+ development system. IIRC there was some C support in their dev kit, but again, using C for the rendering code (or anything in game, really) and get the performance of the SNES Doom port is quite unthinkable.


I'd be surprised if this was referencing anything but your ca65 SuperFX macros.

The only part of Doom that used x86 assembly was a small procedure that dealt with ray casting. This could have been implemented in C - why not I don't know? All the rest of the rendering including texturing was written in C. The source code was uploaded over ten years ago and is available on GitHub.

C on a 486 is a very different beast than C on the 65816...

The latest SNES game I've personally looked at which was almost definitely written in C (or some other higher-level language) is HAL's mediocre port of SimCity 2000. Take a look and you'll notice the direct page pointer being used as a frame pointer, with functions doing an obscene number of reads/writes to direct page memory to deal with variables in really roundabout ways that feel exactly like the sort of code a (not particularly clever) compiler would generate, being much larger, slower and less idiomatic than anything that tends to be seen in hand-written assembly. There are also some functions that behave basically identically to C standard library functions like strcmp, etc.

Some late-era EA Sports titles are similar, including a stack-based calling convention, even more naive compiler-isms (like explicitly allocating 0 bytes on the stack for functions with no local variables), a stubbed-out version of printf used for debug output, etc.

I haven't looked into the SNES port of Doom as much as some other games, but what I've seen of it looked rather hand-written to me.