Programming language, beginner question

[fsakura]

I have recently started learning to program games for NES.

How do you guys typically write programs?
Do you write whole programs in assembly? OR write them in C, compile with cc65 or something like that?

Which is efficient way?

-fsakura

[Bregalad]

Personally for now I write 100% in assembly, but that might change in the future.

Even if you code in C, some parts which are close to hardware will have to be coded in assembly.

Also, you'll have to adopt a particular coding style if you want CC65 to generate not-too-horrible code (by that I mean, less than 10x the size and execution time of the same code written in assembly), like declaring all variables STATIC, using loops in reverse order explicitely, and so on... doing so will reduce your code's readability and therefore if it's not portable and readable why use C in the first place ?

I should definitely do some kind of serious benchmarking to show how good or bad is CC65 for particular programs but I lack the time. I think the Atalan language looks like a promising alternative, as it is more suited for CPUs like the 6502 which is not very well suited for a C compiler to generate optimized code, which means that you'll either have to do departs from standard C, or code your algorithms in a weird non-standard way in order to be remotely efficient.

[koitsu]

Assembly. Next question. ;)

[lidnariq]

Which is efficient way?

(emphasis mine). So ... there's many different efficiencies here.

For quick tests, and even simple games, it's hard to argue with using cc65... even if it is the odd "looks awfully odd C" that compiles to something small and fast. The amount of time it will take you to spin something out will be dramatically lower, because more of the more boilerplate code is taken care of by something else. I personally really hate doing arithmetic in assembly (at least, beyond the simplest bit shifts and addition), so C is really nice here.

On the other hand, if you need special startup code, or you want to update large numbers of background tiles per frame, you'll need to write substantial portions of the thing in assembly anyway.

You might consider looking into uc65 or ca65hl, which are not C, but do afford some of the conveniences of higher-level programming.

[tepples]

I personally really hate doing arithmetic in assembly (at least, beyond the simplest bit shifts and addition)

Then you'll probably get a kick out of the floating-point library I'm working on, at least for turn-based games.

[fsakura]

Thanks everyone for replies. Looks like there is no real advantage in using C here.

For now I have decided to use ASM, because it is helping me to know what happens exactly.
I am using ca65 compiler and ld65 linker to get my rom.

-faskura

[Pokun]

I'm also a beginner and I use only assembly. I looked into CC65 and one of the first things I read was something like "you'll need good knowledge of assembly" and after that I went back to assembly.

[Sverker]

Assembly is really not as bad as some people make it sound. The more about it you learn, the learning curve gets easier.

[slobu]

Nerdy Nights still the place to go for that first NES assembly tutorial?
http://nintendoage.com/forum/messagevie ... eadid=7155

[rainwarrior]

I recently made this: Minimal NES example using ca65

It's not really an assembly tutorial, just an attempt to demonstrate how to use the NES with a very small example that I hope is followable.

[mml]

Only Assembly, only hardcore

My advice is to learn more about 6502, really useful.

[miau]

Assembly. I tried C in the past, it worked well and was nice for a change, but I couldn't have done it without knowledge of 6502 ASM. Once you've written a bunch of utility macros/sub-routines and feel comfortable, programming in assembly can be pretty fast, actually. Admittedly, complex arithmetic continues to be a pain. Also, sometimes it doesn't matter how slow a particular piece of code is, so in C you could opt for convenience and "write regular C" for a bit instead of the usual "odd C that is faster/smaller".

If you have no prior programming knowledge, assembly is easier to pick up IMO. You can learn C for 2 years and still not have a clue what you're doing (nor what the compiler is doing, which is important on a limited platform like the NES).

Also: ASM is fun.

[Bregalad]

Also, sometimes it doesn't matter how slow a particular piece of code is, so in C you could opt for convenience and "write regular C" for a bit instead of the usual "odd C that is faster/smaller".

The problem is that even if you absolutely do not care about the speed, compiled C code will be much larger than hand written assembly and this can be a problem if you aim for a mapper with no or few bankswitching features.

Even if you want to aim for a larger cartridge, you still want to use that extra space effectively and not waste it completely to store horrid bloated code.

[rainwarrior]

What I'm doing for the game I'm currently working on is writing it in C++ as a windows program (with a graphics/sound API designed around the NES specs), and when parts of the program become close to their final design, I port them into the NES version of the program. I'm acting as a human compiler, more or less.

I find doing it this way, I don't have to spend much time iterating/debugging assembly code because I already know what I want it to do going in. The difficult work of trying to find the right algorithms, tweaking the design, etc. is done more easily in the C++ version of the game. At the same time, I still get assembly code that's small and efficient enough, since I'm not going through a C compiler.

Occasionally I do end up wanting to tweak something that's already been ported to NES, and I have to update code in two places at once, but this has so far been fairly easy to keep up with.

[zzo38]

I prefer to use a macro assembler. The software is only written for NES/Famicom/emulators, so the code does not need to be portable to compile into native code of other systems.

C codes compiled into the 6502 will be larger and slower too, as mentioned above, and I do agree to generally want to not store a lot of bloated code. I might use large ROM for level data or more complicated stuff, but the program can be written pretty small in assembly language compared to the level data. Using smaller ROM not only means you can use a smaller ROM cartridge (if you only have a large one, you can just copy the data several times so that it acts like a smaller ROM), but also makes the iNES ROM image file smaller, to take up less disk space and less download times.