nesdev.com

What languages have been used to develop games for consoles over the years? I know that people worked directly with assembly for the NES, and probably for the SNES too, but what about the N64? Were things fast enough yet that they could use C (and maybe C++?). What about the GBA? (I assume that for the GB and GBC, people used assembly directly.)

Assembly code (mostly) and C for all mentioned consoles. C++ - maybe for N64.

There were rare cases of more exotic languages, mostly among hobbyist devs, like Lisp for NES.

GBA can run C or any other subset of C++ where exceptions and dynamic casting are turned off at the compiler. Audio mixers, software 3D engines, and other time-critical code were written in ARM assembly language and loaded into a limited amount of fast RAM. PS2 can run Lisp, like in Jak and Daxter. Several games for modern platforms are written in Lua on top of a C++ engine. All Xbox 360 games from small developers are written in C# due to the .NET CF platform's lack of P/Invoke and Emit.

Lisp? That seems like an odd choice for such an old machine...


So, the C++ compiler for GBA supports/supported inheritance (and virtual methods, etc)?


By modern platforms, you mean XBox360, PS3, and Wii?

What did the generation before (XBox, PS2, Gamecube) commonly have used? What about the PS?


What are "invoke" and "emit", and why does their lack prevent using another language?

* * *

Is it only concern about speed that prevented people from using higher-level languages? or the lack of tools, perhaps? I remember seeing some game for the NES here was made with cc65's C compiler, and it didn't (seem) to have speed issues.

Are you kidding ? I tried to make a program that basically writes text on the screen, and even that was too much to handle, it lagged.

Well, here's what I was talking about: viewtopic.php?f=22&t=7999

Maybe it hides its lag behind the text that flashes multiple times before loading the next level.

You must have been doing something wrong. Shiru's games don't have any lag. Also in KNES I have included a basic platformer demo which is entirely written in C (Shiru's games use an assembly library), so if you have trouble with showing text on screen, I don't know what to say.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

Lisp was just a cool enthusiast's experiment. Learn more.

It is quite abstract question if C on the NES has performance issues. Compiled code is of course slower than hand written assembly code, few times slower - so 'yes' in this regard. However, a game may not require 100% of CPU time and work full speed, smooth, etc, even with not very effective code (it won't help anything if there will be 60% of free CPU time in a game) - so 'no' in this regard.

Yes, mostly assembly for a long time for games on all systems. C came in to use a lot earlier for home computer games, but a few developers were still writing in mostly assembly well into the 90s.

There are a few rare examples on the NES that it has been suggested were using some C (e.g. Koei's Romancing Saga II).

I think most PC game developers were moving into C maybe around 1990. For consoles, more like 1994. Many were using C for PSX.

Nowadays C++ is pretty dominant, I think it took hold in the late 90s, not sure when.

(This is all based on personal anecdotal experience with old game source, and developers I've talked to. I don't know anything about N64 or GBA stuff, so I won't comment there.)

This is not true. The XNA platform requires C#, as I understand, but outside of XNA C# is not typically used for 360 development. C++ is the standard language for 360.

The vast majority of games commercially released for 360 are written in C++. Perhaps you could limit your definition of "small developer" to someone who is using XNA. Probably anyone who can't get access to a 360 devkit is going to use XNA, but we should be clear about how "small" the small developer has to be.

Of course I know that compiled code is slower than hand-written assembly code. I was (and am) asking about whether real games were written in asm or not, and if they were, would the speed loss gained by using compiled code be as big as feared and that the game would be reduced in quality?. Of course, I realize that this answer will vary from game to game.

Thanks for the all the responses so far.

The C++ compiler for GBA was either GCC, Green Hills, or any other C++ compiler supporting ARMv4 and Thumb.


In programs that mix native code and managed (CLR) code, P/Invoke is the way that a module compiled to CLR bytecode calls a module compiled to native code. The trouble is that standard C and standard C++ cannot be compiled to CLR bytecode; it must be compiled to native code. This rules out using standard C or standard C++ in the Xbox Live Indie Games or Windows Phone 7 environment, neither of which allows the use of native code.

Emit is the way to create CLR bytecode at runtime. Languages that use the Dynamic Language Runtime, such as IronPython, use Emit for something, and I'm not sure what. The trouble is that the .NET Compact Framework, used by the Xbox Live Indie Games and Windows Phone 7 environments, does not implement Emit. This rules out using IronPython and other DLR languages in those environments.


Speed and tools are part of it, but memory use is another. In a lot of cases, the available C compiler generates substantially larger code, which hurts if you're trying to squeeze a lot into one PRG ROM bank.


Not always. Some platforms, especially x86 and ARM, have enough engineers working on the optimizers that they approach native code, but the 8-bit microprocessors aren't among them.


This is true of NES, not of Game Boy or anything else battery-powered that lets the CPU enter a low-power state during free CPU time.


The exact moment when it changed was sometime during the Jaguar's life. When porting Doom, someone figured out how to make a C compiler work around the broken instruction cache of the Tom CPU.


That's exactly what I meant by a small developer. Remember that my audience ended up including someone who had never heard of basic .NET Framework concepts such as P/Invoke or Emit and was thus unlikely to have heard of XNA. As I understand it, the console makers' developer qualifications are designed to poach developers from other platforms, not to nurture startups. To get the devkit for Nintendo platforms, for example, a company has to have a dedicated secure office and a previous commercial title on someone else's platform, and I don't imagine that PlayStation and Xbox are any different.

I was ninja'd four times in a row while writing this comment.

The qualifications for getting developer hardware from Nintendo, Sony, or Microsoft are arbitrary. The real qualification is not really having an office or something like that (even though that has been used historically as one of Nintendo's arbitrary reasons); the bottom line is whether they think you have a viable business strategy.

Anyhow I just wanted to be clear that most XBLA games by developers that you might consider "small", like Super Meat Boy, or Braid, are written in C++ and do not use the XNA platform. However, the XBox Live Indie Games service is entirely XNA/C#, so far as I know.

On the subject of rom banks, when did rom banks stop being used? N64/PS era (They had 32-bit physical addressing, iirc.), I assume? Then again, I suppose that CDs and DVDs are like rom banks somewhat...


When you say this, what does it mean exactly? C++ has many features that are obscure and difficult to use. Do they just restrict themselves to a subset of the language? (But one that's a superset of C.)

Sega Genesis doesn't use banks (expect for 1-2 games), it has a huge chunk of linear memory.