NES C programming for dummies

[darkhog]

I'd like to someone write such thing. We have plenty of ASM tuts, but every NES-specific cc65 tutorial I found usually ends on Hello World program.

Now, I have nothing against SOME (by "some" I mean "very little") assembly in places where it is needed, but full assembly coding is hard for most people. No IFs, instead of using variables with simple names, we have to operate directly on registers, etc.

So I ask you (especially people who did things with cc65 in the past) to write more advanced tutorial for writing game with cc65. The tutorial would cover all aspects of game making from making gfx and sfx to displaying sprites in game and playing sounds/music. And of course will be made with more advanced library than nes.lib, I propose KNES (which author's I PM-ed about such thing, but apparently he doesn't have time for this now).

So could someone make such tut? And please refrain from posts like "LEARN 6502 ASM OMFG LOL". For dummies, a.k.a. noob programmers who barely understand C and are more happy with languages like Pascal, like me it's too hard.

Don't get me wrong - I want to learn and want to make NES games (even so I can tell somebody "omg I just made NES game, see?"), and while some assembly is good, it's too hard to write all things in ASM.

[Kasumi]

(This is essentially a "LEARN 6502 ASM OMFG LOL" post. I am sorry.).

No IFs, instead of using variables with simple names, we have to operate directly on registers

No direct ifs, I'll give you. You could construct some basic ones with macros, though. As for operating on registers: You can just write/find a subroutine for that, and never touch it again. My game updates tiles. I just feed it the tile numbers like you'd pass arguments to a function. The register stuff is done automagically. Like what you're looking for in C.

Am I operating directly with SDL's internal variables when I call SDL_Init( SDL_INIT_EVERYTHING ); to initialize it?

For dummies, a.k.a. noob programmers who barely understand C and are more happy with languages like Pascal, like me it's too hard.

If you wanna make games without learning how to program, there are tools for that. (Not for NES, of course) I find assembly language easier than C in nearly every way. There's a post in your previous topic from someone else saying basically the same thing. If you are a noob programmer, learning an assembly language may really help you. 6502 assembly was easier for me to learn, I understand exactly why the code works the way it does, and it helped me understand how software really works. And yet BASIC and Visual Basic totally confuse me. They're far too abstract (especially VB. It does so much for me, I can't follow it).

Shiru already did more than most would in this regard by putting together his awesome Alter Ego package. You've also mentioned thefox's KNES. But you have rejected both. I think you will have to meet someone halfway somewhere, because I propose it would be harder to put this request together for whoever does it, than it would be for you to learn assembly language.

You sound like you want to jump behind the wheel of a car without learning how to drive. How long are you willing to wait for someone to fulfill this proposal? Is your desire to make an NES game really that great if you don't want to learn all the nitty-gritty? Why not just prototype the game in C with NES (graphical) limitations in mind, and then find an assembly language programmer? Or not even find an assembly language programmer? Just keep it Retraux like Megaman 9 and 10.

I bet more of us here could program whatever game you have in mind, than could make this C dream project. It'd even be easy to make a set of subroutines wrappers for dealing with the NES registers (PPU registers, reading joypad, etc.). Even if someone does create this, it may still be necessary for you to know assembly to debug the output when something goes wrong that you don't understand.

What's your real goal? Do you just want your game on NES, or do you actually have to be the one to make it? Because if you ask a programmer to remake a hypothetical C program of your game for NES, someone else is doing some of the work. If you ask a programmer to create a large set of tutorials and easy to use tools, someone else is doing some of the work. So why is it so important for you to have it the second way? (None of these are rhetorical questions. I'd actually like to know your goal here)

As a random aside, check this out: http://bataribasic.com/ It may be your dream, except it's for Atari. (Never tried it, no idea if it's any good)

[darkhog]

Am I operating directly with SDL's internal variables when I call SDL_Init( SDL_INIT_EVERYTHING ); to initialize it?

You compare high-level language (probably c++ as most of SDL games are written in it) to assembly. It's like comaring joypad to graphic tablet - both are input devices, but have different targets. In ASM you can't just put score=45;, you need to operate directly on memory which isn't necessarily simple especially if score can exceed 255 (i.e. is bigger than 1 byte).

And yet BASIC and Visual Basic totally confuse me. They're far too abstract (especially VB. It does so much for me, I can't follow it).

No wonder since BASIC is abbreviation for Bad And Slow Interpretable Commands .

Shiru already did more than most would in this regard by putting together his awesome Alter Ego package. You've also mentioned thefox's KNES. But you have rejected both.

I didn't rejected any of them, but KNES has near to no documentation except sample platformer which's code is really hard to understand ("template" example doesn't count. It's easy to understand but as name suggest is only template for your new games)

It'd even be easy to make a set of subroutines wrappers for dealing with the NES registers (PPU registers, reading joypad, etc.). Even if someone does create this, it may still be necessary for you to know assembly to debug the output when something goes wrong that you don't understand.

I can always ask for help here. It'd be easier (for me) than learning assembly.

I had too bad experiences with x86 assembly. Won't try this again.

[3gengames]

I had too bad experiences with x86 assembly. Won't try this again.

That's x86, the most confusing and stupid assembly ever. 6502 is nothing like it, how about you try it first? It's pretty much the most straightforward assembly can be, it's nowhere near that bad. x86 is disgusting, you'll never find me doing that crap even.

[Shiru]

Actually, I had an idea to write such a tutorial right after Alter Ego. I improved the low-level library, and started to make an example, but ultimately lost motivation. That's because it is really major amount of work that only would help very few people - my methods aren't really suitable for newcomers (like, I don't use any IDEs; my tools aren't really comfortable, etc).

Also, even with C and low-level library, you still need to learn assembly and NES hardware to some extent, to be able to solve all the kinds of problems that could arise in the process. I still don't think that C is easier to use than ASM on NES - it could simplify certain parts, but generally things aren't developed well enough, like, say, on PC, you can't just forget about low-level things. You can't even write in proper C for NES, you have to follow certain limitations to make resulting code faster (no local vars, for example).

I think that some kind of an integer BASIC compiler actually would be better entry-level tool for NES, something like bAtari BASIC (Atari 2600) or BasiEgaXorz (Sega Genesis).


By the way, you can structure your ASM code with macros, making it more readable. Like, make a macros set_score(n), add_score(n) that will contain needed code, and then you can just use these as a kind of a function.

[Dwedit]

I started out with Z80, then moved to ARM, then moved to 6502. Knowing any assembly helps you learn another. And knowing ARM makes 6502 easier. Only real problem is that the carry flag is the opposite on Z80 vs 6502/ARM.

[tepples]

For someone proficient in 6502 who knows some ARM (like myself), does Z80 make it easier to learn x86?

[darkhog]

Actually, I had an idea to write such a tutorial right after Alter Ego. I improved the low-level library, and started to make an example, but ultimately lost motivation. That's because it is really major amount of work that only would help very few people - my methods aren't really suitable for newcomers (like, I don't use any IDEs; my tools aren't really comfortable, etc).

How could I motivate you?
//edit: And for me best IDE is notepad+compiler.

Also, even with C and low-level library, you still need to learn assembly and NES hardware to some extent, to be able to solve all the kinds of problems that could arise in the process.

As I said, I don't have problem with using some assembly. The problem is writing whole game in ASM.

And for your BASIC suggestion, it is abbreviation for Bad And Slow Interpretable Commands and there is such tool for NES, called nBASIC, but it's crap.

[thefox]

And for your BASIC suggestion, it is abbreviation for Bad And Slow Interpretable Commands and there is such tool for NES, called nBASIC, but it's crap.

nbasic (by Bob Rost) has practically nothing to do with BASIC, except for the name. BasiEgaXorz etc are much closer to the "real" BASIC, and thus much easier to use.

[Shiru]

I don't think there is a way to motivate me. I'm personally don't need such a tutorial, and also I highly doubt that there is target audience that would be actually able to make games, but the only thing that stop them is lack of a tutorial.

Regarding your joke on BASIC, I've said 'compiler'. The two I mentioned are compilers, not interpreters. So they aren't slow. And C on NES is not fast as well, compiled BASIC and C are pretty much comparable in this case.

[Kasumi]

In ASM you can't just put score=45;, you need to operate directly on memory which isn't necessarily simple especially if score can exceed 255 (i.e. is bigger than 1 byte).

You can get pretty close. As Shiru (and I) said, just write macros/functions. Then you'll never have to write whatever is in the macro again.

Also why is two instructions so much harder than one?

lda #45
sta score

is so much harder than score = 45?

If so, is setmem score #45 harder?

You don't even need to use hex if you don't want to. As for setting a 16 bit value, that has to be done fairly rarely (at least for values other than 0 in my experience). One can probably write a macro for that too, but not in the assembler I use. (At least not in a way that would be preferred by you)

I think your preconceptions are making it seem harder than it is. You can actually make assembly very easy for yourself. Let's pretend this is the only way to do things. Can you deal with it then, or will you give up? There are only 56 instructions, probably <12 of which you'll use regularly.

I can always ask for help here. It'd be easier (for me) than learning assembly.

More people here could help with assembly.

I also notice you answered none of my questions about why your NES game has to be done specifically this way. Give them some thought. I'm truly curious.

[Brickman]

I really started learning C when i used the gameboy advance devkit called 'Hamlib' The original site seems to be down but you should be able to find the dev kit around (i think it was eventually given away freely.) It's a great all in one SDK with some good demo /sourcecode if i remember.

Here's a book written using Hamlib:
http://www.cc.gatech.edu/classes/AY2006 ... g/gbabook/

Alot of what you learn about working with tile based graphics can then be applied in Nes C dev. I personally think nes dev is a little too picky for a straight C beginner...it frustrates me and i've been hobby coding since 2004.

[cpow]

//edit: And for me best IDE is notepad+compiler.

Which...dare I point out...technically isn't an IDE.

Seriously though...there's an IDE out there that will let you step through and symbolically debug Alter Ego or any other game written in C/Assembly. Sure...it's not perfect...but I know the author so...if there's any suggestions on how to make it more appealing/useful, I'm sure I could convince him.

And for the record...I created an Alter Ego project to be used with said IDE. For the same reason already mentioned several times in these threads...it's much easier to provide a working [in this case stellarly-so] example for people to step through than to provide countless "ok now we're going to take the cake out of the oven and add frosting" build-up tutorials.

[3gengames]

You're forgetting that 6502 is built to be simple and isn't x86 assembly. You should go through the first few Nerdy Nights tutorials and learn how the 6502 works and you'll see it's really, really simple. I know it requires a certain way of thinking that is rare for even other programmers, but still when you can think that way, it becomes really straightforward and simple. IMO, if you'll take the dive and just go through the first 6502 assembly tutorials, even if you learn it you can make a more educated decision of what is right for you. Just saying you don't wanna learn and use 6502 because x86 is total garbage isn't that good of an ide, heh.

[darkhog]

ok, could you post link to these tuts?