nesdev.org

How about an old tutorial for how to use Famitracker? https://www.youtube.com/watch?v=bwNElW5IEo0

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.