nesdev.org

Posted: **Wed Jun 20, 2012 3:30 pm**

I know how to program, but I have no idea how to program in Assembler. And when I have a look at tutorials, it doesn't look like fun to me, unlike working in a higher programming language. That's why I'd like to know: Is there a C or C++ compiler for the NES that you can write actual programs with?

Posted: **Wed Jun 20, 2012 4:01 pm**

Zooming Secretary is written in C, and has source code available.
But C on the NES is not that fast, probably 4-8 times slower than equivalent ASM code (wild guess).

Posted: **Wed Jun 20, 2012 4:05 pm**

NESICIDE can be used to develop/debug C or assembly programs for NES.

The speed factor of C is, IMO, not noticeable in Zooming Secretary or Alter Ego.

Posted: **Wed Jun 20, 2012 5:16 pm**

I really should be mentioned that any game written for the NES in C is going to get wretched performance.

You really should just learn 6502 if you're interested in programming the NES. You'd be surprised how simple it is. Much, much simpler than C.

EDIT: maybe I should actually read the replies before I reply. Looks like dwedit already mentioned that C performance would suck. =P

Posted: **Wed Jun 20, 2012 5:32 pm**

If you think assembly isn't fun in it's own way, you've never programmed assembly. It's 10x better than x86 or Z80, so be happy. 6502 is simple, and fun.

Posted: **Wed Jun 20, 2012 6:31 pm**

Disch wrote:I really should be mentioned that any game written for the NES in C is going to get wretched performance.

C code itself generally has awful performance compared to assembly (especially on the NES), but that doesn't mean the game itself has to have wretched performance.

cpow wrote:The speed factor of C is, IMO, not noticeable in Zooming Secretary or Alter Ego.

Yes.

Performance isn't necessarily the bottleneck that will stop you from making your game. It can be, but it doesn't have to be. I think just getting the code written and working is a much bigger bottleneck. I find C code a lot faster to write, and easier to debug, and a lot of the time that's worth much more to me than the performance hit. A lot of things in any given game do not have to be high performance. If it takes you one or four frames to set up the next level, the user is not going to notice, but if it takes you one day or a week to write it...

Shiru wrote a great article about getting started in C: http://nesdev.com/bbs/viewtopic.php?t=8493

You will eventually need to learn some assembly, but you might be able to get a fair bit done without it just by using Shiru's work as a springboard.

Posted: **Wed Jun 20, 2012 7:09 pm**

I'd say programming for the NES in C is feasible for a wide variety of single screen games, but I wouldn't expect something like SMB3. Scrolling, object management and collision detection are already too demanding in assembly.

I'm with the gang that thinks 6502 assembly is fun. If you don't think so it's probably because of the shock that is the initial transition from a high-level language. Once you master it though, assembly can be really fun.

Posted: **Wed Jun 20, 2012 7:45 pm**

Disch wrote:Much, much simpler than C.

Well, I'm very fluent with C and 6502 asm, and I strongly disagree with your statement. C is easier than ANY assembly language, from almost any point of view. The thing with assembly is that you have to know not only instructions, but general architecture of the target machine, which involve a bit more of knowledge of computer system in general (processor flags etc.) which is a lot of things to learn as a beginner. Moreover, while with C there's room for programming errors, with assembly there's even more room for silly errors you can't get with higher level programming (unmatched push/pop, accidental clubber of temp reg/mem, etc). Maybe highly arguable, but the last pages of this thread proves my point.

I mean, let's consider this very simple example:

C:

Code: Select all

int somefunction(int a, int b)
{
   int c = a + b;
   return c;
}

Assembly (6502):

Code: Select all

somefunction:
   ; let's suppose parameters are in temp1, temp1+1, temp2 and temp2+2
   ; and reuse temp1 & temp1+1 for return values.
   lda temp1
   clc
   adc temp2
   sta temp1
   lda temp1+1
   adc temp2+1
   sta temp1+1
   rts

That's 2 lines of C code (that could be put in one line; matter of style) against 8 in 6502 assembly. You forgot the clc? Tough luck, you'll have slightly inacurate results, which will have some strange result depending when you call it. Forgot the rts? Well, your program will be screwed. There's plenty of way simple code can go wrong in assembly, and your assembler will not catch 'em. In C that's another matter: forget the return statement, you'll get a warning; give the wrong number of parameters, it will error out. You can still screw thing up with pointers, but at least it's not with the very basic.

Just look also: in assembly, you'll have to know where your data is so you get them correctly, and you must know its size too. In C, I don't give a heck of where my data is and its size, or the registers used, I just want to add them, period. If I want to multiply two numbers, I don't even care of the algorithm, I just want to be more focused on my algorithm. Code look more natural, I have less things to consider when doing code.

Now, don't get me wrong, I'm not saying C is better than assembly, and I didn't consider performance, which in some implementations (on NES in particular) is really not the best, or other limitations in the NES implementation (mapper handling), but at least it is always easier than any assembler language and the most accessible for a beginner.

Posted: **Wed Jun 20, 2012 7:54 pm**

How many lines of code does it take to get something actually on the screen and working in C vs assembly? I can get a RLE compressed screen and start up the hardware in about 100 lines total, including the subroutine. I'd like to see the most optimized C output of doing the same.

Posted: **Wed Jun 20, 2012 8:02 pm**

...

If I'm more comfortable in C and you're more comfortable in assembly, what's the difference? If we both can produce quality games that people enjoy playing, what's the difference? If C and assembly both can be used as springboards for entry into the arena of programming for NES and for learning the other, what's the difference?

The OP asked about the availability of a C compiler for NES. The simple answer to that is "yes, there is a C compiler for the NES." Responding with "C sucks" and "you'll never make a game like SMB3 with C" doesn't answer the question, it just fuels the fire to turn this into a flamethread.

Posted: **Wed Jun 20, 2012 8:47 pm**

There is a C compiler for the NES. It is certainly a viable way to make games. Speed-wise, I'm very confident that you can make a scrolling game like SMB or Final Fight (i.e. short range attacks and 4-5 characters on the screen), but probably can't make a good Contra-like game (requires processing many objects). The main problem is not speed, but code size, but there are ways to deal with it, it is not a complete show stopper. If you get a speed bottleneck, you always can make an assembly equivalent of this exact part of the code, which is way easier that writing everything in assembly.

Writing in C is few times faster and easier than in assembly code, even 6502 one, so it worth to consider if you don't have much time to work on a project.

For games that pushes NES hardware to the max you have to choose assembly. However, to my knowledge, from all homebrew games only one actually attempts to do that - Hiatus Ward, which is not even finished currently.

Posted: **Wed Jun 20, 2012 8:58 pm**

3gengames wrote:How many lines of code does it take to get something actually on the screen and working in C vs assembly? I can get a RLE compressed screen and start up the hardware in about 1100 lines total, including the subroutine. I'd like to see the most optimized C output of doing the same.

Input:

Code: Select all

#include "neslib.h"

#include "test.h"	//packed nametable data

const unsigned char palette[16]={ 0x0f,0x21,0x10,0x30,0x0f,0x14,0x21,0x31,0x0f,0x29,0x16,0x26,0x0f,0x09,0x19,0x29 };//palette data


void main(void)
{
	pal_bg(palette);//set background palette from an array

	unrle_vram(test,0x2000);//unpack nametable into the VRAM

	ppu_on_all();//enable rendering

	while(1);//do nothing, infinite loop
}

Output is 365 lines, but it uses a library that is ~1000 lines of code without a music player (another 1000 lines). All that assembly code is commented, even the compiler output (it includes corresponding parts of the source code).

Posted: **Thu Jun 21, 2012 6:27 am**

cpow wrote:"you'll never make a game like SMB3 with C" doesn't answer the question

Of course it does. In addition to knowing that there is a C compiler, he must know about the limitations of using that language. I didn't say that out of spite, I was just making it clear that even though you can use C, assembler is more capable.

Posted: **Thu Jun 21, 2012 6:53 am**

I somehow think that 'you'll never make a game like SMB3' statement is close to the truth for homebrew projects, with assembler or not.

Posted: **Thu Jun 21, 2012 7:03 am**

Shiru wrote:I somehow think that 'you'll never make a game like SMB3' statement is close to the truth for homebrew projects, with assembler or not.

But in the very distant future, Maybe it is possible if we keep learning everything about 65xx ASM by then...

McKids (McDonaldLand in PAL reigons) is almost compared to SMW, Although it took a official dev team 2 years, It may still lead us to inspire to recreate another engine several or more years after this year (If we still exist...)

So maybe there can be a chance, May be a long-shot, but it is possible!

nesdev.org

Programming for the NES in C or C++

Programming for the NES in C or C++