FinalZero wrote:
Quote:
GBA can run C or any other subset of C++ where exceptions and dynamic casting are turned off at the compiler.
So, the C++ compiler for GBA supports/supported inheritance (and virtual methods, etc)?
The C++ compiler for GBA was either GCC, Green Hills, or any other C++ compiler supporting ARMv4 and Thumb.
FinalZero wrote:
Quote:
All Xbox 360 games from small developers are written in C# due to the .NET CF platform's lack of P/Invoke and Emit.
What are "invoke" and "emit", and why does their lack prevent using another language?
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.
FinalZero wrote:
Is it only concern about speed that prevented people from using higher-level languages? or the lack of tools, perhaps?
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.
Shiru wrote:
Comipled code is of course slower than hand written assembly code, few times slower
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.
Shiru wrote:
it won't help anything if there will be 60% of free CPU time in a game
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.
rainwarrior wrote:
I think most PC game developers were moving into C maybe around 1990. For consoles, more like 1994.
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.
rainwarrior wrote:
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
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.