This page is a mirror of Tepples' nesdev forum mirror (URL TBD).

# What do we want in a tutorial?

Nerdy Nights is a huge improvement over the tutorials that preceded it (GBAGuy, etc.) But it has come to my attention in this topic that even it has room for improvement. What might the outline of a new tutorial look like? And would it be a good or bad idea to rely on libraries for things like linker script, system init, nametable clearing, and gamepad reading, without explaining them in the first lesson?

I'm guessing it'd start like this:

Chapter 1: Gathering tools
Installation of ca65, GIMP, and tile converter would need to be described separately for apt-based Linux, yum-based Linux, OS X, and Windows

Chapter 2: Hello World
1. Immediate mode and PPU addressing: Turn the screen green
2. Indexed addressing and looping: Display "Hello World"
3. Subroutines: Display "Hello World" at different positions
4. More looping: Display a pattern of "Hello World"
5. Indirect indexed addressing: Display multiple strings
6. Reading the controller (using a library): Display one set of strings, then another
7. Wrap-up: Text file viewer

Chapter 3: A bouncing ball
1. Clearing and filling OAM: Display a circle
2. Position variables and waiting for vblank: Move the circle
3. Position comparison: Limiting the circle's movement
4. Velocity variables: Bounce the circle off the walls
5. Nametable updating: Displaying the state of the controller
6. Binary to decimal conversion and nametable updating: Displaying the position of the circle
7. Reading the controller and 2D movement: Control the circle's direction
8. Acceleration and subpixel math: Give the circle some momentum

Other chapters: Air hockey game, Brick breaking game, Platforming, Scrolling, Sound effects, Music

Any leaps too far in the pacing?
Random thought: what would happen if it focused first on sprites and later on backgrounds? (at least having sprites alone you can make some minimal games, but having backgrounds alone will limit your choices more)
Will there be a primer on ASM language, or will this be explained as you go? I think alot of people get confused with CMP instructions.

Also, I like a wiki kind of approach, with links to further information on each page.
Sik wrote:
Random thought: what would happen if it focused first on sprites and later on backgrounds? (at least having sprites alone you can make some minimal games, but having backgrounds alone will limit your choices more)

What kind of game could be made with only sprites? You'd probably need a background to 1. define where the sprites are allowed to go (such as top and bottom walls in Pong) and 2. display the score. Even if you could do so with only sprites, I conjecture that doing so with a background would be easier to understand.

dougeff wrote:
Will there be a primer on ASM language, or will this be explained as you go?

Both. The installation chapter will link to the list of 6502 tutorials if the user wants to learn assembly language in another environment first. But each instruction and each addressing mode will be explained as it's first used. This is why I've broken "Hello World" down the way I did.
I'm really glad you're doing this. If there's anything I can do to help with the project, I'd be happy to do so. If the pace ends up feeling too fast, you could always break up the lessons you have planned.

I'll throw out a few ideas in no particular order:

Disambiguation of the flags and the operands that use them. As long as I thought BEQ was "branch on equal", I wasn't really understanding what that operand did. I had several CMP #$00 commands which were totally redundant. Perhaps some collision detection with the other objects in the ball game. Stack usage. I don't think this ever gets covered in Nerdy Nights, not even to protect your registers during NMI. Optimization of code. This would be a later tutorial, but I think it would be helpful to address general ways to improve programming for the system, perhaps as a wrap-up. Sometimes writing efficient code in assembly is much different than a higher level language, and sometimes a new potential developer may not have experience with programming at all. You could show some ways to replace operands with others that take less clock cycles, as well as structure, such as creating unrolled loops, something that you'd almost never do with a higher language, and why/when you would do things like that in assembly. I'm putting together a spreadsheet of the operands, and their various clock cycles and byte lengths if that's useful for a download file. This is probably covered all too well in other articles online, but general best practices in programming would be useful for anyone like myself who hasn't had classical training. Conventions for naming variables, commenting on code, indenting, structuring blocks of code might be helpful. Just a link to another article would be plenty. Nerdy Nights doesn't really go into animation. This might be useful, especially for someone who's never programmed before. Programming enemy AI perhaps. That would be a more advanced topic. For me, and I'd imagine a lot of people, I can read stuff a lot but it doesn't usually click until I do it a few times. I'm not really sure how this information would come in to play, as it would be the reader's responsibility to read, practice, and then come back and reread, but maybe you could pose completing a program and then review the completion in the next article. Nerdy Nights gives incomplete programs but doesn't really go over and say, "let's review that task and see how you did" Operands that confused me most at the start: AND, OR, EOR - The first thing I tried to do with one of these was to: Code: CMP #$xx
AND #$nn That obviously didn't work. I thought about these commands from their higher-level language uses. I had to look at and break down the functions of the seven logic gates in a very simple manner before I actually got this. BIT - This kind of goes with the last one, as those without assembly experience probably won't be used to the idea of directly working with the 1s and 0s of a byte. Most people who really use computers probably know a bit is a 0 or 1, and that a byte is 8 bits, but how just those two options create a functioning computer system didn't really start to come in for focus for me until I started doing this. Anything to do with the flags - I didn't get these at first, and I feel like it helped a lot to understand that every branch instruction is checking these flags. In a higher level language, you're controlling all of your branching with variable values, but here, all of the variable values are controlling the flags which control your program flow. I think because of that they deserve more attention than they get. tepples wrote: Sik wrote: Random thought: what would happen if it focused first on sprites and later on backgrounds? (at least having sprites alone you can make some minimal games, but having backgrounds alone will limit your choices more) What kind of game could be made with only sprites? You'd probably need a background to 1. define where the sprites are allowed to go (such as top and bottom walls in Pong) and 2. display the score. Even if you could do so with only sprites, I conjecture that doing so with a background would be easier to understand. Baby's first pong game is best done using the top and bottom borders as the boundary, and foregoing score entirely - for this, sprites are fine. The goal isn't to make a fun, complete, NTSC-safe-zoned game (I know that last bit was going to get mentioned), but just to get people familiar with the idea of putting a few elements together. Tepple's example looks pretty good so far. If there's something to criticize I would say that it looks like it takes an awful long time before you can make a game lol. But I don't know how long each lesson is. And if they properly teach you how to make structured code it may be worth it. The other thing is that you are using ca65 (newbies might want to make their first ROM as fast as possible lol). Also I wonder what you mean by reading the controller by using a library? Aren't you teaching how to program everything by themselves? Or are you covering controller reading later? For sound, I don't really have anything to complain about in the Nerdy Nights sound tutorial that Metal Slime wrote, as the sound engine he teaches you to make is quite versatile. Except that he never finished it. He is still missing how to use the DPCM channel, any expansion sound channel and PAL compatibility. He also mentioned something about sound effects and more advanced drums in his next lesson that never came. I guess he was going to introduce the DPCM channel there. For animation, there are nothing in Nerdy Nights but NA has other tutorials here: http://nintendoage.com/forum/messagevie ... adid=33287. I think teaching assembly as you teach how to program the NES is fine. That's how I learned 6502 after all. Pokun wrote: The other thing is that you are using ca65 (newbies might want to make their first ROM as fast as possible lol). Lesson 1 would get people to the point where they can build a working ROM from a source zipfile. This is intentionally a more complex program than the first program of lesson 2 because I want to exercise more of the toolchain (ca65, ld65, Python, Pillow, GNU Make, GNU Coreutils) to prevent problems later. Quote: Also I wonder what you mean by reading the controller by using a library? Aren't you teaching how to program everything by themselves? Or are you covering controller reading later? A later lesson would explain what goes on in nrom128.cfg (linker script), nrom.s (iNES header), init.s (init code), pads.s (controller reading), and ppuclear.s (OAM and nametable clearing), which come with the template. I think lesson 1 should be a warning about how game development is going to suck up hundreds of hours of your life, and after months of frustrations and bug fixes, you will still have a game that's only 1/100th as good as most of the commercial games of that era. And if that's ok with you...here's how to make a game. I'm kidding, I love this stuff, even the annoying technical documents. I see your tutorial is going to have Python. Would you say that Python is easier to use than C++? I only know C++, Pascal, and JavaScript, oh and 6502 ASM, which I learned back in high school because we had an Apple II. Code examples that make everything look easier than it really is. dougeff wrote: I see your tutorial is going to have Python. Would you say that Python is easier to use than C++? I only know C++, Pascal, and JavaScript, oh and 6502 ASM, which I learned back in high school because we had an Apple II. Because the NES cannot read PNG files, we first need to convert them to a format that the NES understands. I could make data conversion tools in PHP, JavaScript, Pascal, or C++ instead, but then we'd have to install PHP, Node, Free Pascal, or GCC in chapter 1. In my experience, Python is easy to install on both Windows and Debian, and I imagine it's just as easy on Fedora, FreeBSD, or OS X. One thing it has over C++ is memory safety. Like JavaScript, Python has exceptions instead of "undefined behavior", which means it's harder to shoot your own sit bone than in C++. Ok, I'll give it a try...a little later...the next programming language I want to learn is ASM for the SNES. It's your tutorial, so do it with the tools you're most comfortable with. If you're going to teach beginners with ca65, that might as well be a tutorial on its own...(although I suppose config files are the only thing you'd HAVE to comprehend). 2 questions about python: 1. What version do you use? 2. How to install Pillow on Windows? tepples wrote: Quote: Also I wonder what you mean by reading the controller by using a library? Aren't you teaching how to program everything by themselves? Or are you covering controller reading later? A later lesson would explain what goes on in nrom128.cfg (linker script), nrom.s (iNES header), init.s (init code), pads.s (controller reading), and ppuclear.s (OAM and nametable clearing), which come with the template. I see, that makes perfect sense. tepples wrote: dougeff wrote: I see your tutorial is going to have Python. Would you say that Python is easier to use than C++? I only know C++, Pascal, and JavaScript, oh and 6502 ASM, which I learned back in high school because we had an Apple II. Because the NES cannot read PNG files, we first need to convert them to a format that the NES understands. I could make data conversion tools in PHP, JavaScript, Pascal, or C++ instead, but then we'd have to install PHP, Node, Free Pascal, or GCC in chapter 1. In my experience, Python is easy to install on both Windows and Debian, and I imagine it's just as easy on Fedora, FreeBSD, or OS X. One thing it has over C++ is memory safety. Like JavaScript, Python has exceptions instead of "undefined behavior", which means it's harder to shoot your own sit bone than in C++. Still if you made it in C++ you could just include a binary for Windows users and they wouldn't have to install anything at all. For Linux users it shouldn't be any harder than installing Python (plus Python extension for bitmaps) and they are likely already setup. nicklausw wrote: If you're going to teach beginners with ca65, that might as well be a tutorial on its own...(although I suppose config files are the only thing you'd HAVE to comprehend). That's what I meant by "A later lesson would explain what goes on in nrom128.cfg (linker script)". It'd probably be around when it gets to mappers. Quote: 2 questions about python: 1. What version do you use? Currently 2.7, but on a forward-oriented tutorial, perhaps switching to 3.4 might be better. In Ubuntu and probably other Debian-based distros, sudo apt-get install python-imaging gives Pillow in the former, and sudo apt-get install python3-imaging gives Pillow in the latter. Quote: 2. How to install Pillow on Windows? Recent versions of Python include pip, for which the procedure is \path\to\pip.exe install Pillow from an elevated Command Prompt. Pokun wrote: Still if you made it in C++ you could just include a binary for Windows users But then I'd need regular access to an up-to-date Windows PC on which to test all build procedures in the tutorial. And the user would still need to install a compiler for the Sound chapter in which I teach the reader how to make a lookup table generator. If I would teach someone with a NES programing tutorial, when I get to the graphics section I would teach it under a CHR-RAM setup first and save CHR-ROM for a more advance side section. CHR-RAM is much more similar to how GPUs of modern, and not so modern, systems where the only thing that's read only is the initial program package. Uploading tile data by$2006 and $2007 also demonstrates more clearly the real separation between CPU and PPU buses. As for tool dependency issues, the only thing I can think of is to illustrate the native NES data structures, and how the bytes behave with single pixel changes, so that it will be possible for human beings to enter data manually by .db statements or make a tool for themselves, and or point out other options like YY-CHR. I've put the outline on a wiki page. What emulator should we use on each platform? On Windows, FCEUX is probably fine until you get to the raster effects part, at which point you need to buy an EverDrive N8 or PowerPak. On Debian family, I've been using FCEUX (SDL), which Debian packages, for Ctrl+R in my editor and FCEUX (Windows) in Wine for debugging. Fedora doesn't package any console emulators because Red Hat fears Nintendo's legal department. OS X native emulators tend to rely on a payware "Emulator Enhancer" plug-in for half their features. And which text editor? I use gedit 2 on Xubuntu 14.04 (a Debian derivative), but gedit 3's "new face" without a menu bar scares me. I'd prefer not to depend on Vim or Emacs because each of those editors differs from mainstream desktop UI conventions so much that it would need a separate full-fledged tutorial by itself. In any case, it needs a way to easily run a program from within the editor (the Ctrl+R binding). Finally, I've never been entirely sure about the copyright license of NESdev Wiki. Otherwise, we'll need to build this tutorial on a wiki with a well-defined license, such as my own wiki which is CC-BY. For text editors I liked KDEvelop (although it's more of an IDE). For Windows I'd use Notepad++ (I have highlighting file for 6502). It has a standard plugin that can execute external programs when pressing F6. 43110 wrote: If I would teach someone with a NES programing tutorial, when I get to the graphics section I would teach it under a CHR-RAM setup first and save CHR-ROM for a more advance side section. CHR-RAM is much more similar to how GPUs of modern, and not so modern, systems where the only thing that's read only is the initial program package. Uploading tile data by$2006 and $2007 also demonstrates more clearly the real separation between CPU and PPU buses. What's so advanced with CHR-ROM? It's super straightforward. CHR-RAM on the other hand requires a mapper which should come in a later chapter. I don't think teaching things out of order is a very good idea. tepples wrote: nicklausw wrote: Pokun wrote: Still if you made it in C++ you could just include a binary for Windows users But then I'd need regular access to an up-to-date Windows PC on which to test all build procedures in the tutorial. And the user would still need to install a compiler for the Sound chapter in which I teach the reader how to make a lookup table generator. Why is that? I don't see the difference between the CHR conversion tool and other tools like the assembler. Wouldn't you need to do that anyway in that case? But if you are using other Python scripts you might as well go with Python from the beginning. Pokun wrote: What's so advanced with CHR-ROM? It's super straightforward. CHR-RAM on the other hand requires a mapper which should come in a later chapter. I don't think teaching things out of order is a very good idea. NES development was once new to me, and I can tell you the single most surprising unintuitive thing to me was the CHR-ROM, both that the tile gfx was fixed in rom, and that the data has to be included after the end CPU vectors. That second point is especially important when working with a flat file as it has caused confusion in the past. Learning CHR-RAM before CHR-ROM may seem out of order historically because CHR-ROM games came first, but I argue that CHR-RAM first is natural, not only because of the possible confusion, but because it can follow the lesson about uploading nametable bytes via the same PPU ports. CHR-ROM can then come later as a precursor to CHR page switching for faster animation. tepples wrote: And which text editor? If ubuntu includes gedit by default, recommend it. If not, consider recommending it anyway. gedit has not lost functionality through it's face lift. As long as it's not wordpad or libreoffice, and is a plain text editor, it should be fine. 43110 wrote: As for tool dependency issues, the only thing I can think of is to [...] enter data manually by .db statements Note to self: 43110 likes to trace the holes. Before the MArtist rant in ''The New Tetris'', there was the Y.S. rant in the Famicom cassette version of ''Pachi Com''. In Pachi Com, Y.S. wrote: Does company N develop with company I's PROS80? I'm AMAZED they can make stuff on that weird (3″ floppy disk) machine! Do they 'trace the holes' when drawing art, too? If you're sick of tracing holes, I'll sell Bear's art machine (ROM) and debugger for$40 grand... [phone omitted] That's cheap if you want pretty art!!!

("Tracing holes" means programming graphic data directly without the use of any artist tools.)

But anyway, I've slotted in a chapter that explains CHR RAM, tile data formats, and the tile converter tool. I'm just trying not to front-load the exposition too much.

43110 wrote:
both that the tile gfx was fixed in rom, and that the data has to be included after the end CPU vectors.

ld65 allows specifying segment contents in any order in the .s files, so long as memory areas are in the correct order in the linker script. An NROM-128 linker script would automatically place CHR ROM contents after PRG ROM, just as it places the header before PRG ROM.

43110 wrote:
I argue that CHR-RAM first is natural, not only because of the possible confusion, but because it can follow the lesson about uploading nametable bytes via the same PPU ports.

In my opinion, CHR ROM improves pacing. Copying a full alphabet from PRG ROM into CHR RAM requires use of the (d),Y addressing mode because the alphabet is more than 16 letters long, and 16 tiles is the limit of a,X or a,Y. This in turn would move the introduction of (d),Y addressing mode forward to the start of chapter 2, when I had hoped to introduce it midway through. Or should I include filling CHR RAM in libstufftobeexplainedlater the way I am doing for the iNES header, reading the controller, and clearing OAM?

43110 wrote:
gedit has not lost functionality through it's face lift.

If we recommend both pre- and post-facelift gedit, we'll have to walk the user through configuring Ctrl+R in both pre- and post-facelift gedit depending on what apt-get decides to give him.

Now for my post that took like 6 hours to write, because I had a hard time conveying that I am really VERY positive to this, and I just want to help out in some way by giving some ideas. Also, swedish is my 'modersmål' so it is pretty hard sometimes to express exactly what I intend to.

I think this is the start of a great initiative! I for one would have loved this back in mid 2013 staring at a grey/gray screen

What comes to mind is the professional aspect of this setup. I don't have anything against the setup nor the 'tools' themselves. In fact, this approach could be the very defacto standard of comming NES dev. The answer to: how do I make my own NES game? to keep it simple. Well, you do this.

A lot of folks here use ca65. I can't complain since I never had the time nor patience to actually try it out for myself.
It would really be easier to help people if every piece of code and tool "worked the same" for everyone. It is a neat idea.

However, for a lot of people starting from pretty much nothing - not all of them, the intimidation factor of having to install, script and configure "this" and "that" in order to get "that and this" to work is what might keep them from even starting.
Yes, sooner or later you will have to do this anyway in some form.

Even though most of us don't see a problem with a bit of configuration, I can see why newbies would prefer to "drag and drop" instead of having all this setup for some 8 pixel sprite on a background that 'doesn't even stomp Goombas'. I was one of them.

"I need to do all that?? Nah screw that, here is something much simpler.."

And that might be the reason why many eventually come to this forum with NN based tutorial code for NESASM3 asking for help.
Don't get me wrong, we (as a community) need the best, most experienced and talanted people to make a once and for all tutorial as good as the wiki, in a 'real life situation' whereto people can look for reference.

But now, that will also require the reader to adapt to a more complex set of tools in order to get started.
I really like my ASM6. I know it may not be as advanced as ca65+stuff, but I haven't yet found anything I can't do with it. As long as I can't find a reason to change, why do it? The png to chr converter (?) sure would be sweet though..

Anyway.. So maybe there could be... 2 or 3 different options for the newcommer to start with in order to adjust to their taste? Anyone want/able to translate the tutorial code from one assembler to another to keep every bit of choice there could be?

Just some thoughts.

Like I wrote, it is hard for me to type in english exactly how I mean, but I hope my opinion is of any use.
tepples wrote:
43110 wrote:
As for tool dependency issues, the only thing I can think of is to [...] enter data manually by .db statements
Note to self: 43110 likes to trace the holes.
100% true. It's why I love understanding file format definitions, and that this was never finished.

tepples wrote:
In my opinion, CHR ROM improves pacing...

I agree it would be a bit much to explain in the Hello World chapter, since the point there is showing the shortest path to displaying a word on screen. Since for that chapter you'll most likely be providing the CHR page and skimming over all the assembly details, it would not matter if it's CHR-RAM or CHR-ROM. CHR-RAM with a unexplained upload routine has the benefit of keeping the cart setup the same all the way to the part where 16-bit indexing is explained, but either choice is fine.

About gedit, I guess I never got used to using a hot key for compiling, so I failed to see it missing. I don't know what further to say about choice of text editor.

Also before I start editing your outline or anything, Nerdy Nights has been often praised for it's sound and music engine tutorials. Would taking it's outline be a good start for the sound and music sections?
Re:Sound and music

I would like to see a tutorial explain how to go from a DAW to produce a MIDI, to Famitracker, to exporting data, to incorporating into an actual NES game. I've never seen such a step-by-step beginning to end music tutorial. And ca65 seems like the best choice. I would nominate Rainwarrior for writing that one.
dougeff wrote:
I would like to see a tutorial explain how to go from a DAW to produce a MIDI, to Famitracker, to exporting data, to incorporating into an actual NES game.

Once it's in FamiTracker, the manual for Shiru's FamiTone takes it the rest of the way. But I myself would need a tutorial to get from zero to MIDI. Which free DAW should I use for this tutorial?

One problem with authoring NES music directly in MIDI is that NES music engines tend to prefer repeated phrases/patterns to save space. Listen to the music from WORLD 1-1 in Super Mario Bros. or the bass line in the song that few Silver Surfer players had heard all the way through before NSFs. I'm not sure if MIDI supports any analogous construct.
Perhaps you could export the Treble and Bass line separately, as 2 separate MIDI file. Import them separately, and loop the Bass. And, I'm not sure that there are any good free/open DAWs out there. I have 2 that were fairly expensive, and 1 that came with a Computer Music magazine. I thought, maybe, you could have a more advanced tutorial than Nerdy Nights.
tepples wrote:
One problem with authoring NES music directly in MIDI is that NES music engines tend to prefer repeated phrases/patterns to save space. ... I'm not sure if MIDI supports any analogous construct.

MIDI files can be annotated with events, but it can also be practical to detect loops during export. 4klang does this already with MIDI. (I suppose some forms of LZ compression are generic forms of loop detection?)

If it's your own exporter, you can create whatever method for identifying loops/repeats that works for you. In my own engine the exporter automatically detects patterns/instruments/macros that are the same and merges them. The pattern order is rebuilt based on unique data, rather than just using what Famitracker gives. I prefer to do it this way than try to optimize within Famitracker, because it makes it easier to split shared ones later.

Startropics has a really cute music data format. Each track has up to 256 bytes per channel, and there are loop/repeat command codes. It's nice and compact, though it limits song length/complexity quite a bit.

Also, why would you want to use anything besides Famitracker to make your NES music? (Or even PPMCK / Muse / Deflemask.) These things already give a great 1:1 NES composition experience, why do you want to use a generic format like MIDI?

A lot of people seem to have good luck with shiru's Famitone too. It's one of the only "drop in" solutions that this homebrew community has.
Quote:
why do you want to use a generic format like MIDI?

I don't use MIDI this way, currently. But, the DAW interfaces are so much better than the Famitracker interface. I can record direct from a MIDI keyboard into a DAW and edit the notes directly and easily.
Famitracker actually has MIDI input support, if you want to use a MIDI keyboard to enter notes into it.
Oh. I can't know everything.

Well, that sort of proves my original point. A new tutorial should show how to do music with Famitracker.
I've seen that one before. It doesn't explain how to incorporate a song into an NES game, of course.
Late due to no internet access.

mikejmoffitt wrote:
tepples wrote:
Sik wrote:
Random thought: what would happen if it focused first on sprites and later on backgrounds? (at least having sprites alone you can make some minimal games, but having backgrounds alone will limit your choices more)

What kind of game could be made with only sprites? You'd probably need a background to 1. define where the sprites are allowed to go (such as top and bottom walls in Pong) and 2. display the score. Even if you could do so with only sprites, I conjecture that doing so with a background would be easier to understand.

Baby's first pong game is best done using the top and bottom borders as the boundary, and foregoing score entirely - for this, sprites are fine. The goal isn't to make a fun, complete, NTSC-safe-zoned game (I know that last bit was going to get mentioned), but just to get people familiar with the idea of putting a few elements together.

Yeah, this. Or maybe for something more complex, a shmup that has player, bullets and enemies (no background or scoring or whatever, just a barebones one). In any case it would be way more useful in order to get started understanding how to make games on the NES.

tepples wrote:
And which text editor? I use gedit 2 on Xubuntu 14.04 (a Debian derivative), but gedit 3's "new face" without a menu bar scares me.

Yet this is what I have somehow (the only serious difference is that the preferences dialog is in the taskbar and not the menubar, and that's something you'd rarely touch anyway). gEdit 3.10.4 on Gnome in Classic mode.
dougeff wrote:
I've seen that one before. It doesn't explain how to incorporate a song into an NES game, of course.

Alright. Well, making a tune in Famitracker is a separate task from putting it in a game. For putting it in a game, you need some music engine to run it. I already suggested Famitone, if you want something that's easy to drop in (lots of people have had success with this). It has documentation and examples too, which is effectively a tutorial, isn't it?

Or are you just saying you're unsatisfied with all existing guides for this? I'm not offering to create one, by the way, but it might be productive toward the goal of the thread if you could explain what it is you want in more detail.
Not for me. I'm happy with my own music engine for now. I thought we were brainstorming for what should go in a new tutorial.
I just wish there was a good MML sound engine that's easy to plug in to a game, so you wouldn't have to resort to trackers. I'm no musician but I can read sheet music at least which makes MML more appealing. I looked into PPMCK at first but realized it was mostly designed for making NSF files. Then I found NSD.Lib and it seemed good at first, but I couldn't find anything about PAL compatibility in it and it's ca65/cc65 only.

Metal Slime's Nerdy Night sound engine tutorial is the closest thing I found. It's not exactly MML but its sound format translates to notes quite easily. It has loop/repeat and such command codes, is easy to plug in and easy to port to another assembler syntax. I almost got it to work in PAL mode too.
Pokun wrote:
I just wish there was a good MML sound engine that's easy to plug in to a game, so you wouldn't have to resort to trackers. I'm no musician but I can read sheet music at least which makes MML more appealing.

Then perhaps I should get to work on designing an MML dialect for the music engine I used in Thwaite and RHDE, whose note duration table coincidentally matches the first eight lines of "The sound length" listed here. Is there an MML syntax standard that all MML processors are expected to follow?

Before I write anything, I'll have to ask elsewhere about the wiki's licensing policy.
Re: Rainwarrior

I tested MIDI input to famitracker, and I guess you CAN do everything in famitracker, and don't need an external program, except maybe to edit DPCM samples. I may try this technique in future projects.
mikaelmoizt wrote:
However, for a lot of people starting from pretty much nothing - not all of them, the intimidation factor of having to install, script and configure "this" and "that" in order to get "that and this" to work is what might keep them from even starting.

I agree with that. A toolchain tutorial would be really great, but I think it should be kept far, far away from the introduction-level stuff. You can do a lot with just asm6.exe, one .asm file, one .CHR file and a .bat file to build it. And something like a PNG2CHR converter hopefully could be provided in exe format. IMHO, one of the big hurdles for people wanting to get into NES programming, is simply lacking the confidence that they can pull it off. Making it as simple as possible, and giving them complete control over the process without any unnecessary steps, I believe could help out with that.

Nerdy Nights covers the basics fairly well, so people can always be directed to that too, for a simpler start.
Memblers wrote:
A toolchain tutorial would be really great, but I think it should be kept far, far away from the introduction-level stuff.

Agreed. If the very first thing in the tutorial is installing and setting up all those things, I bet many people will simply want to go with Nerdy Nights instead. Unless you found a way to pack everything into a nice little installer that people can double-click and click "next" to install everything at once.
I agree that it can be detrimental to introduce complex toolchains too early. It can be difficult for newcomers to see the benefits of using a complex setup like that. It should be easier to justify after the reader has already experienced firsthand some of the problems of doing the same work manually. I think the same approach can also be useful for introducing stuff like .repeat and macros. First show the naive/basic way, then show how it can be simplified.

Of course one problem with this approach can be that some people might read the tutorial selectively and end up with a bunch of bad practices. For example, should proper initialization code be introduced early on or later? If early, the important bits can get lost in the complexity. If late, some people will come asking why their non-initializing ROM doesn't work on their flash cart.

(One more unrelated note: I think you should use a hex editor quite early on to demonstrate how changes in the source code are reflected in the resulting binary file. Just to concretize things.)
Yeah for a newbie it may not be clear that all these assembler specific expressions and macros are not instructions for the NES CPU but for the assembler at assemble time. I'd stay a way from macros in the beginning at least and focus on 6502.

The init code should be mentioned and probably explained very briefly why it's there (something Nerdy Nights missed). Then tell the reader that they don't need to know this yet and focus on what is to be studied in the current lesson instead. Same goes for all other things that might take up precious space in the newbie's head.

I agree about briefly introduce hex editors (I'd compare it to a normal text editor) and examine the binary.

tepples wrote:
Pokun wrote:
I just wish there was a good MML sound engine that's easy to plug in to a game, so you wouldn't have to resort to trackers. I'm no musician but I can read sheet music at least which makes MML more appealing.

Then perhaps I should get to work on designing an MML dialect for the music engine I used in Thwaite and RHDE, whose note duration table coincidentally matches the first eight lines of "The sound length" listed here. Is there an MML syntax standard that all MML processors are expected to follow?

All MMLs seems to be slightly different. I'd try to make it as compatible with PPMCK as possible to avoid inventing new standards. Or maybe even like Family Basic MML (page 80).
Memblers wrote:
A toolchain tutorial would be really great, but I think it should be kept far, far away from the introduction-level stuff. You can do a lot with just asm6.exe, one .asm file, one .CHR file and a .bat file to build it. And something like a PNG2CHR converter hopefully could be provided in exe format.

Then the tutorial would still need to cover installing Wine so that users of a machine with a competing operating system can run asm6.exe in Windows format, png2chr.exe in Windows format, and fceux.exe in Windows format. But then we have to include Wine in the tutorial anyway because the well-known debugging emulator uses the Win32 API. Either that or we'd have to include a tutorial on setting up VirtualBox, acquiring a copy of Windows, and installing it into that.

tokumaru wrote:
Unless you found a way to pack everything into a nice little installer that people can double-click and click "next" to install everything at once.

Because FCEUX is GPL, distributing FCEUX ourselves rather than relying on the official download site would require mirroring FCEUX's source code as well.

Pokun wrote:
I'd try to make it as compatible with PPMCK as possible to avoid inventing new standards.

I'm just afraid of the inefficiencies that I might have to introduce into the converter in order to abstract over differences between the data model of PPMCK and the data model of my music engine. Or are you instead recommending that new music engines be designed around the quirks of PPMCK?
tepples wrote:
Then the tutorial would still need to cover installing Wine so that users of a machine with a competing operating system can run asm6.exe in Windows format, png2chr.exe in Windows format, and fceux.exe in Windows format. But then we have to include Wine in the tutorial anyway because the well-known debugging emulator uses the Win32 API. Either that or we'd have to include a tutorial on setting up VirtualBox, acquiring a copy of Windows, and installing it into that.

Or just put "you need to be able to run Windows programs" in the prerequisites and let those people sort it out.

I think we can safely assume some minimum technical background. I mean, I'd also advice that anybody who doesn't have at least some minimum game programming knowledge to stay away from NES homebrew because otherwise they'll make way too many mistakes, first make some games on a modern platform and then come back. And somebody who can do that probably also knows how to install Wine if needed.
tepples wrote:
Because FCEUX is GPL, distributing FCEUX ourselves rather than relying on the official download site would require mirroring FCEUX's source code as well.

Ideally, everything would be included in a single install file (I, particularly, hate this approach, but I think the novice NES programmer would appreciate it), but if there's one thing you can leave out of the package, it's emulators. If someone is attempting to create an NES game, I think it's safe to assume they know how to install an use an emulator.
Sik wrote:
Or just put "you need to be able to run Windows programs" in the prerequisites and let those people sort it out.

That's probably the most sensible solution. No need to waste time rewriting instructions for a step that's probably already documented elsewhere. Linking to such instructions would be enough.

Quote:
I think we can safely assume some minimum technical background.

You'd be surprised at how many people don't know what a command line application is, and come here claiming that the assemblers they're trying don't work because they open a black window that instantly closes.

Quote:
I mean, I'd also advice that anybody who doesn't have at least some minimum game programming knowledge to stay away from NES homebrew because otherwise they'll make way too many mistakes

Learning game programming concepts at the same time you're learning assembly and computer architecture is indeed a tough task. It's not impossible, it's just harder. In general, I think people underestimate how long it takes to get good at this. I started in 1997 (with game programming, NES came a bit later) and I still learn new stuff all the time.
tokumaru wrote:
if there's one thing you can leave out of the package, it's emulators. If someone is attempting to create an NES game, I think it's safe to assume they know how to install an use an emulator.

Just because someone can install an emulator doesn't mean he can 1. install specifically a debugging emulator or 2. trigger the emulator to start after a successful build. How should we expect the user to provide the emulator's path to the batch file?

And in order not to sound too buddy-buddy with Microsoft, we're going to have to come up with some believable wording to explain exactly why we are relying on Windows executables. Besides, a particular build of asm6 or png2chr is itself "not commonly downloaded", and the Python installer signed by Python Software Foundation would probably score higher on SmartScreen's Application Reputation feature than an uncommon executable that is not signed.
tepples wrote:
Pokun wrote:
I'd try to make it as compatible with PPMCK as possible to avoid inventing new standards.

I'm just afraid of the inefficiencies that I might have to introduce into the converter in order to abstract over differences between the data model of PPMCK and the data model of my music engine. Or are you instead recommending that new music engines be designed around the quirks of PPMCK?

I guess format incompatibilities between different sound engines is unavoidable, and I don't think sacrificing efficiency for compatibility reasons is a good idea for a sound engine (PPMCK isn't designed to be small and fast unlike NSD.Lib). But you ask what kind of syntax to use, so I suggest to make it as compatible as possible to current popular formats in order to make it easier for people to convert their songs to your format.

tokumaru wrote:
tepples wrote:
Because FCEUX is GPL, distributing FCEUX ourselves rather than relying on the official download site would require mirroring FCEUX's source code as well.

Ideally, everything would be included in a single install file (I, particularly, hate this approach, but I think the novice NES programmer would appreciate it), but if there's one thing you can leave out of the package, it's emulators. If someone is attempting to create an NES game, I think it's safe to assume they know how to install an use an emulator.

I hate having to use installers for every little program that really doesn't benefit from them, and I avoid them whenever possible (that's why I preferred to not use Python at first).

Quote:
Quote:
I'd also advice that anybody who doesn't have at least some minimum game programming knowledge to stay away from NES homebrew because otherwise they'll make way too many mistakes
Learning game programming concepts at the same time you're learning assembly and computer architecture is indeed a tough task. It's not impossible, it's just harder. In general

Of course it's easier if you already know game programming, but the first time it's going to be hard anyway so they might as well learn it on a platform that interests them.
tokumaru wrote:
You'd be surprised at how many people don't know what a command line application is, and come here claiming that the assemblers they're trying don't work because they open a black window that instantly closes.

Which probably means they still have a lot to learn before they should start learning NES development.

tepples wrote:
And in order not to sound too buddy-buddy with Microsoft, we're going to have to come up with some believable wording to explain exactly why we are relying on Windows executables.

If you're so worried about that then shouldn't you also be worried about being too buddy-buddy to a particular emulator (something that tends to lead to "religious" wars as people tend to attempt imposing their preferences on everybody else), or too buddy-buddy to a particular tool? Seriously, I believe that you're overthinking this.

If you want to teach people how to use a tool and that tool happens to only be readily available on Windows, then that means you should tell the person to find a way to run those programs, and if you don't like this, then you should find tools that are readily available elsewhere to avoid the issue in the first place. It sounds like your problem is that you want to avoid coming out as being Microsoft friendly.

Also chances are that somebody developing on Linux or OSX is more likely to have a good technical background out of necessity because they're using less common (and thereby less supported) platforms.
Sik wrote:
tokumaru wrote:
You'd be surprised at how many people don't know what a command line application is, and come here claiming that the assemblers they're trying don't work because they open a black window that instantly closes.

Which probably means they still have a lot to learn before they should start learning NES development.

Which in turn is why I created a list of Wikipedia articles on general computer science topics that people ought to know first, so that I could cite it in a tutorial.

Quote:
If you're so worried about that then shouldn't you also be worried about being too buddy-buddy to a particular emulator (something that tends to lead to "religious" wars as people tend to attempt imposing their preferences on everybody else), or too buddy-buddy to a particular tool?

The emulators, scripting language interpreters, and the like are free software. Windows is not.

Quote:
It sounds like your problem is that you want to avoid coming out as being Microsoft friendly.

Correct. If I wanted to be Microsoft friendly, I'd skip the NES tutorial in favor of a DirectX tutorial and encourage people to develop games for the Windows Store in the hopes of applying for the ID@Xbox program.
Sik wrote:
Yeah, this. Or maybe for something more complex, a shmup that has player, bullets and enemies (no background or scoring or whatever, just a barebones one). In any case it would be way more useful in order to get started understanding how to make games on the NES.

I like this idea.
It might be good to provide a shell script to install dependencies, and even offer to curl/wget/whatever other necessary requisites are for the user. You would have to give the script some sensitivity towards the type of package manager being used, but if you support apt and yum you are already supporting a majority of the tiny Linux minority. A similar batch file for Windows users would be helpful. If you want to support Mac users, then yet another script can help.

I don't think this is an appropriate opportunity to care about how friendly you are appearing to Microsoft. Windows is not free software, but more or less everything involved in the tutorial is. Furthermore, people aren't going to go out and buy or pirate Windows because the tutorial told them to. Chances are most readers of the article already have Windows. It is difficult to find a computer that does not come with some license of Windows. You have to go out of your way to not own Windows with a store bought computer. If you want the tutorial to reach people, it is best to make it platform agnostic, or at least reach as many people as possible.

If you want a kitschy all in one solution, you could make a small ready-to-go VM image with a basic Debian install ready to go with everything set up. All you'd have to do is help people install VirtualBox at that point, which I'm hoping is free enough to scratch the FSF itch.
A "how to make a shmup" tutorial would work like this.

Part 1: Initiating the NES, and displaying a color.
Part 2: Objects and Sprites
Part 3: Moving Objects
Part 4: Collision
Part 5: Spawning and Killing Objects
That's actually the order I've found myself doing things, except I've been working on vram crap that you don't need to worry about on the NES.
A shmup would be easy because everything can be in screen coordinates, and the scrolling would be implied.
Don't forget the biggest advantage: the end result will resemble (even if barely) the kind of games you could expect to see on the system, and will teach you enough to get an idea of how things work in a "real" game. This helps build up confidence really quickly, which will mean more people will stick around instead of giving up early.
I remembered an idea I had a while back, that I haven't thought of for a while. For the Garage Cart series, one of the things I wanted to have on it was some kind of NES programming tutorial or reference docs that would actually be displayed on the NES itself. It's less about practicality, and more about introducing the topic to a different audience.
What would be really neat is an interactive prompt on the NES. It would be great if a user could just POKE things into OAM parameters or the tile map and watch it change on the NES to make it very clear what different registers do. A very clear annotated showcase on the NES, something like "this is what the screen looks like with red tint on" and then of course the red tint bit is set. There is a small example like this for the Genesis, showing some VDP features.
I've actually considered making an interactive rom like that to explain the restrictions to pixel artists.
You could have pixel artists try my background graphics editor to explore the limitations.
That's already suggested in this post.
Kasumi wrote:
I've actually considered making an interactive rom like that to explain the restrictions to pixel artists.

That kind of reminds me of a really cool Neo Geo rom, where you can alter the sprites by moving them around and shrinking them and liking them to other sprites and whatnot.

You know, one thing that would be really cool is if somebody did this on the SNES, but took it a step further buy allowing you to edit vram and change video modes and everything. There'd be like a screen for editing cgram, a screen for editing vram, a screen for editing the information regarding sprites and BGs, like where sprites and BGs start in vram and the video mode used, and a screen where the actual display is, where you can move the sprites and the BGs around. I think that would be kind of cool, and it would especially be cool if you could actually save the picture in SNES mode (it just saves all the information) and save the picture in a picture file that you view on your computer. (Off course, you'd need to be able to connect it in some way.) One thing that would be a bit of a problem is if you're editing every aspect of the video hardware, there'd be no more room left for saying what any of the controls or anything, (The Neo Geo demo uses the fix layer for this) but you could always have it to where there's another menu that just displays the controls.
Sik wrote:
tepples wrote:
And which text editor? I use gedit 2 on Xubuntu 14.04 (a Debian derivative), but gedit 3's "new face" without a menu bar scares me.

Yet this is what I have somehow (the only serious difference is that the preferences dialog is in the taskbar and not the menubar, and that's something you'd rarely touch anyway). gEdit 3.10.4 on Gnome in Classic mode.

Did it change between 3.10.4 and 3.11.92, when this screenshot was taken of the UI that people complain about? Or what is "classic mode"?
tepples wrote:
Or what is "classic mode"?

Gnome 3 has a mode where it gimmicks the UI from Gnome 2. It's not an exact replica, but for the most part it's similar. I haven't checked how gEdit looks outside classic mode so take that into account.
Some code examples for a SHMUP tutorial:

Moving an object:
Code:
lda x_position_lo,x
clc
sta x_position_lo,x

lda x_position_hi,x
sta x_position_hi,x

lda y_position_lo,x
clc
sta y_position_lo,x

lda y_position_hi,x
sta y_position_hi,x

Drawing a sprite
Code:
ldy oam_pointer

lda y_position_hi,x
sta oam,y

lda name,x
sta oam+1,y

lda attributes,x
sta oam+2,y

lda x_position_hi,x
sta oam+3,y

tya
clc
adc #$04 sta oam_pointer I would make sure to add comments to each portion (at the side, no need to be on their own lines) to make sure it's more readable to those who aren't that well versed in 6502 assembly yet. I like how tidy those snippets look though =P EDIT: how it'd look with comments (I know there's some redundancy but it's needed to counter assembly being harder to read): Code: lda x_position_lo,x ; Apply horizontal speed clc adc x_velocity_lo,x sta x_position_lo,x lda x_position_hi,x adc x_velocity_hi,x sta x_position_hi,x lda y_position_lo,x ; Apply vertical speed clc adc y_velocity_lo,x sta y_position_lo,x lda y_position_hi,x adc y_velocity_hi,x sta y_position_hi,x Code: ldy oam_pointer ; Where this sprite will go lda y_position_hi,x ; Store the sprite properties sta oam,y ; 1st byte = vertical position lda name,x ; 2nd byte = tile to use sta oam+1,y ; 3rd byte = palette and flip lda attributes,x ; 4th byte = horizontal position sta oam+2,y lda x_position_hi,x sta oam+3,y tya ; Calculate offset for next sprite clc adc #$04
sta oam_pointer
psycopathicteen wrote:
Drawing a sprite

Are objects represented by a single sprite?
tokumaru wrote:
psycopathicteen wrote:
Drawing a sprite

Are objects represented by a single sprite?

It could be a generic AddSprite subroutine =P (although I'd add a check to ensure it won't draw too many sprites... actually thinking on it, it'd just wrap around and overwrite the earliest sprites, right?)
Hey, here is a thread I forgot.

*Putting "even more n00b than I actually am" glasses on.*

I've been told that there are basically 2 different versions, where one is for "legacy" support, and one is for "teh futare" or something.
(Apart from that, there are different sub versions of the two different versions. I guessed highest numbers = newest and better.)

I got both packages just in case (I mean really, how should I know?), installed them and everything went fine.
If I double click that executable named python.exe a black box pops up and disappears quickly.
So this must be a command line driven compiler/interpreter.

Next, I tried to compile a piece of code from tepples Project template.

ImportError: No module named PIL

Um. So.. okay. I guess I go to that dev forum to see if someone can help me with that. (...)
Ah, there it is. I need to download some sort of library thing.
And so I did find some stuff to download, but it now says I don't have the right version of Python (...not installed... register...blah..)
Wait.. this is some old stuff from 2009.. that can't be right.

Alright, so now I need something named Pillow. Is it related to resting your head on something?
Hmm.. there are a lot of files to choose from. I finally ended up with Pillow-2.9.0.win32-py3.4.exe and it finally looks like it works! (*)

*Taking "even more n00b than I actually am" glasses off.*

Now.. excuse my TL;DR approach of this post, but you all kind of see the problem with all this? There are a lot of things to intimidate a n00b here without guidance
So yeah, a tutorial on this + all the rest of the tool chain would be nice and save a lot of grief. What to get, how to get, where to get and what to do.

@tepples : you can start writing tools and setup related stuff (if not already started?) so we at least get going somewhere.

Let's start here.

(*) For the record, working with command lines, installing packages, configuring my editor, and getting libraries are not something I am not familiar with, so for me it was pretty straight forward.
mikaelmoizt wrote:
I've been told that there are basically 2 different versions, where one is for "legacy" support, and one is for "teh futare" or something.

Right now, the scripts are designed for Python 2, which is the "legacy" version. (When I started writing them, there were serious practical problems with using Python 3 on Windows that weren't resolved until the release of Python 3.3.) But by the time I actually start the tutorial, I plan to port everything to Python 3.

Quote:
If I double click that executable named python.exe a black box pops up and disappears quickly.
So this must be a command line driven compiler/interpreter.

On your Start menu, there should be a program called IDLE. This is the Tk-based graphical front end to Python.

Quote:
Alright, so now I need something named Pillow. Is it related to resting your head on something?

Python Imaging Library changed its name to "Pillow" after a new maintainer took over. I'm not sure the "low" part stands for anything.
tepples wrote:
On your Start menu, there should be a program called IDLE. This is the Tk-based graphical front end to Python.

Ah. I see. Thanks.

I really like the help file. It contains a tutorial and covers a lot of other stuff as well. THAT part was really newbie friendly.
I was thinking... If Nerdy Nights was written in C rather than ASM, I would have had an easier time following it. Maybe more people would get into NES programming if the tutorials were in a more common language, like C.
C is not a great fit for the 6502, so you'll need to understand the 6502 a bit first, but such a guide has already been written: http://shiru.untergrund.net/articles/pr ... s_in_c.htm
How many people even know any language before starting NES dev? I didn't know anything before attempting to work on the SNES, which I constantly heard was "too hard" for a first platform. I'd say it's just better to get used to assembly, because it's the best option in terms of performance.
dougeff wrote:
I was thinking... If Nerdy Nights was written in C rather than ASM, I would have had an easier time following it. Maybe more people would get into NES programming if the tutorials were in a more common language, like C.

Maybe that would be a good idea for some people, just to 'get a feeling'. However, I really can't think of a more basic and easy way of doing load, store, compare, subtract and add things than by using three letter mnemonics.
C is easier once you want to see what the program is trying to do rather than how. It's just that it's way too slow and memory hungry to be usable on the 6502, at least for a NES game which is intended to perform well.
Re:cc65, coding NES in C

I downloaded Shiru and thefox's cc65 example files, and I noticed that thefox uses makefiles to compile the code. Does cc65 (or ca65) need an external program like 'make' to do a final compile compilation?
You can mostly just use "cl65", but given the effort that the cc65 suite put into looking like a "real" computer's C compiler suite, a lot of people end up using Makefiles for more complex projects.
In addition, correct use of a makefile avoids A. having to re-run the PNG to CHR converter on all graphics every time you build the program or B. forgetting to manually re-run the PNG to CHR converter when something has in fact changed.
I spent 4+ hours testing out cc65, and concluded that it's junk and nearly incompatible with NES architecture.

I downloaded 3 different versions of cc65, etc. Because I was getting all kinds of error messages, even with Shiru and thefoxs lib files, even editing cfg files. When I finally got it working... I wrote a simple test program that declares two variables, initializes them, adds them, and stores them to the name table...

Initializing them took up about 10 lines of ASM. Adding them over a dozen lines of ASM, and similar with storing to the name table. It doesn't seem to know how to use the registers. All math is 16 bit, even with 8 bit numbers (it just shoves a 0 in the upper byte for the math). New versions of cc65 are incompatible with older versions. Shirus runtime.lib wasn't working with 2 of 3. The standard NES.cfg is all wrong.

And, now I go back to using ASM6.

Edit, I redacted my statement, as using 'unsigned char' does use 8-bit math, and you can write optimized subroutines in ASM.
dougeff wrote:
I spent 4+ hours testing out cc65, and concluded that it's junk and nearly incompatible with NES architecture.

It's entirely compatible with NES architecture.

Quote:
I downloaded 3 different versions of cc65, etc. Because I was getting all kinds of error messages, even with Shiru and thefoxs lib files, even editing cfg files.

Use the version of CC65 it was built with, or rebuild the runtime lib with a newer version. It's not very productive to play a game of "is this still compatible?" with the libraries. (Though the problem here may just have been that shiru didn't document which version should be used, or how to rebuild the runtime? This is a problem with shiru's documentation though, not CC65.)

Quote:
I wrote a simple test program that declares two variables, initializes them, adds them, and stores them to the name table...
Initializing them took up about 10 lines of ASM. Adding them over a dozen lines of ASM, and similar with storing to the name table.

Variable initialization is just a block copy operation, it would be the same amount of code whether it was 2 variables or 200, so it's reasonably efficient for use at scale.

Quote:
It doesn't seem to know how to use the registers.

The C language shouldn't know how to use the registers. That's something a runtime library does, not a C language extension. Register manipulation needs to be done in assembly. Shiru's runtime library knows about the registers and has the appropriate functions for manipulating them via C calls.

Quote:
All math is 16 bit, even with 8 bit numbers (it just shoves a 0 in the upper byte for the math).

CC65 is capable of doing 8 bit math. If you're sure you haven't implicitly converted to int by accident, it's possible that you've run into an unlucky case that is doing it improperly. If it's an error in the compiler you might share the problem code to the mailing lists so that it can be improved. You might be able to get what you want by inserting some explicit casts to unsigned char to combat implicit conversion to int?

The advantage of C is not having to think about the underlying code, though. It's going to be inefficient, this is a given. In the cases where you need efficiency, you can always write that part of your program in assembly, too, it's not like that's been taken away from you.

Quote:
The standard NES.cfg is all wrong.

Yes, you should not use that, or the standard runtime libraries. They are designed for an entirely different purpose than NES game development. If you're using shiru's runtime library, you should use his supplied CFG file with it.

CC65 is very much usable for NES development. Maybe the existing tutorials have some documentation/usability problems, but that's its own issue. You've run into problems, but you can contact the people responsible for those issues to help get them fixed. Maybe you can help the next person who wants to try.
rainwarrior wrote:
CC65 is capable of doing 8 bit math. If you're sure you haven't implicitly converted to int by accident, it's possible that you've run into an unlucky case that is doing it improperly.

This implicit conversion is mandated by the standard, although admittedly add is one of those operations where you can just forget the higher bits so it should be optimizable. Are optimizations turned on? If so then probably CC65 isn't being clever enough. Also I bet that using += would work around the issue (but then again that's something you shouldn't have to rely on).
Yeah, it's easy to envision a string of arithmetic operations producing some implicit casts to int that the optimizer just can't keep up with. It's a very weak optimizer.

Again, though, it's C, it's already expected to be inefficient. If the code is correct, what we're talking about is whether you have to do workarounds for some marginal gain. Most of the time there isn't much to gain with this kind of workaround.

My approach is to just code normally until an actual performance problem occurs (e.g. I get slowdown somewhere in my game) before I start looking for tricks to make the compiler more efficient, or rewriting parts in assembly. It doesn't really matter to me if there was some wasted calculation if I'm not exceeding my frame's timing budget yet.

If there's some use case that is common and intuitive, and should be easy to optimize but isn't, though, that kind of stuff is totally worth bringing up on the mailing list as a suggestion for future improvement to the compiler.
I was declaring them with 'int', because that's what I'm used to doing with small integers.
"int" is required by the C standard to be at least 16 bits.
My philosophy is "technology should just work". When you turn the key in your car, it should start. When you press the back button on a browser, it should go back. And when you create a C environment specifically to function on an 8-bit 6502 processor, it should just do that. I shouldn't have to spend 4 hours trying to configure this or get the runtime library to do that, or trick the compiler into forcing a variable into 8-bits. And software updates should be backwards compatible. Anyway, I'm done bitching.

I was just trying to see if it would be easier to learn NES programming in C. I think the answer is 'no'. You still need to work with ASM at some point...for your start up code...for optimization when updating the PPU...for debugging the game later in FCEUX...etc.

I think I'll try ca65 next (ie, entirely in ASM), but I'll spare you my frustrated commentary if I can't get it to work right away.
unsigned char -- and optimize -- seemed to produce much more efficient code.
For that I'd recommend a types.h with some typedefs to save time:

Code:
typedef unsigned char u8;
typedef signed char s8;

So on and so forth.
dougeff wrote:
I was declaring them with 'int', because that's what I'm used to doing with small integers.

But huh, int isn't the type meant for small integers, short int is (and indeed short int is 8-bit on many old systems, no idea if that's what happens here though).

EDIT: tt'd because why not
Sik wrote:
and indeed short int is 8-bit on many old systems

Do these systems predate the C standard? Because in the standard, short int is at least -32767 to 32767, which means at least 16-bit.
My understanding is that 'short int' is stored 16bit and uses math 16bit, but the upper 8bits are masked out (like I said "shoves a 0 in the upper byte"), and so 'short int' might actually be LESS efficient, since it has to take the additional step of masking the high byte at each step.
tepples wrote:
Sik wrote:
and indeed short int is 8-bit on many old systems

Do these systems predate the C standard? Because in the standard, short int is at least -32767 to 32767, which means at least 16-bit.

¯\(º_o)/¯

Started looking around but I can't find any references to short being 16-bit from earlier than C99 (though I didn't do that exhaustive of a search). What do the older standards say? I know that char being required to be 8-bit is a relatively recent addition (if you ignore POSIX, which is its own competing standard)
The official C89/90 standards have been withdrawn, and so it's harder to get a copy of it, but: C89 §2.2.4.2 indirectly states that short int must be at least 16 bit. A random other source implied that K&R C did not define a minimum size.

Similarly, C89 defined char must be at least 8 bits, but I believe weirder systems use 9-bit chars.
I came up with revised Python installation instructions. Steps 1 and 2 actually install it, and steps 3 through 5 test the installation.

1. First install Python from here: https://www.python.org/ftp/python/3.5.1/python-3.5.1.exe
2. Open a Command Prompt and do this:
Code:
C:\Python35\Scripts\pip.exe install Pillow
3. From the Start menu, inside All Programs, inside Python, choose IDLE (Python GUI).
or: From the Start menu or Windows 8 Start screen, type IDLE and then choose IDLE (Python GUI).
4. From IDLE's Run menu, choose Python Shell. This should open a new window titled "Python Shell".
5. Paste in each of the two following lines, pressing Enter after each one:
Code:
from PIL import Image
Image.new('RGB', (100, 100), (0, 191, 0)).show()

This should cause a small green box to appear on the screen. If it does not, or you see a bunch of red text in the IDLE window, let me know.

Could you put on your newb hat and try these steps?

EDIT: updated Python (Windows 32-bit) link to 3.5.1
Quote:
newb hat

From C:\Python34\Scripts>
I typed "pip install Pillow", btw.

And, I have windows 8.1. I just slid from right to left (opens the right menu), and hit "search", typed in "IDLE", chose the first option, and "Python 3.4.3 Shell" Opened.
dougeff wrote:
From C:\Python34\Scripts>
I typed "pip install Pillow", btw.

That'll work too. I just wanted something that would work even for Command Prompt newcomers who can't yet tell a cd from a Compact Disc.

Quote:
And, I have windows 8.1. I just slid from right to left (opens the right menu)

That works on touch laptops, not on desktops or non-touch laptops. I'm trying to come up with a single set of instructions with as few variations as possible.

Quote:
and hit "search", typed in "IDLE", chose the first option, and "Python 3.4.3 Shell" Opened.

So it mostly worked; thanks. One thing I learned is that some Python installations are configured to open a shell by default instead of a new Python script by default. I'll add this to the instructions:

4. (If IDLE's window is titled "Python 3.x.x Shell", skip this step.) From the Run menu, choose Python Shell.
tepples wrote:
I've put the outline on a wiki page.

Speaking as someone making an attempt at my own game (although very slowly), I like this outline. It starts with first learning how to display something on screen, how to make them move, how to make them interact, and then how to make something more complex.

This is my thought process on how I would like to learn how to program from scratch, in case this is helpful in any way.
1) Give me the tools I need to create a .nes file that can run on a powerpak/emulator. Use these tools, as instructed, to create .nes files for the following "stages".
2) Display "Hello World" text.
3) Display tiles that I have created or found online.
4) Combine tiles and turn them into a sprite.
5) Animate my sprite.
6) Use inputs from a control pad to force animation of my sprite.

Of course I would essentially want someone to spoon feed me everything I need up through this point. From there, I would want to learn how to create backgrounds, introduce more sprites, have the sprites interact. Although I would still love to be spoon fed all this, I would think it could become a little more advanced in teachings at this point.