A couple of general questions:

1. Regarding compilers, what type of differences exist between each of them. Are they essential differences, or "merely" matters of how one goes about writing code? The reason that I ask is that I read somewhere a while back (cannot recall where) some rather negative remarks about NESASM3 and did not know if learning another compiler would be necessary in the near future. Will NESASM3 get the job done when it comes to making games? I have a feeling that it will, and if it did not have some critics I would be worried (like fifty glowing Amazon reviews for the next piece of exercise equipment), but I thought that I would check. If anyone has continued to use NESASM3 beyond the Nerdy Nights tutorials I would be interested to know. I saw some discussion on NESdev, but it was geared more toward "name your favorite compiler," and it did not seem to address general or generally specific differences between the different options.

2. In terms of graphics, what purpose do programs like Tile Layer Pro serve for the homebrewer? Most of the information that I have been able to find about this type of program relates to ROM hacking so even a broad overview would be helpful (or a link to a broad overview). Is this somewhat similar to the map editor that Sivak wrote for his games, or that Maiu posted a while back for Project P (

)? It would appear that at least the latter programs would alleviate some of the need for coding each individual tile of the background (not trying to bypass that essential skill, but just looking ahead).

Thanks in advance!

I still use NESASM3 exclusively, and as far as I know the only differences are how you write things.  Of course I am not an expert in this area, so I'll let someone more knowledgeable chime in.  Bunnyboy still updates NESASM3 when bugs are discovered, but as far as I know everything major has been worked out at this point.  I've never had any problems with it, anyway.
I only use Tile Layer Pro for drawing tiles, creating the .chr file that I .include in my assembly files.  I don't know of its potential to actually create map data (and honestly, I had no idea that Project P existed until you just posted that.  It looks amazing!)  I've personally use (and I know a few other homebrewers that also use) nesst for my games, which doesn't have the drag and drop feature that Project P has, but it still works very well for what I need.

Hopefully some more developers will jump in here and answer from their perspectives.  They may know of features/tools that I haven't used.

1. It's not so much HOW you write things, but more of what features are available to ease how you code, I guess you could say. From what I can tell, the assemblers that people generally find the most easy to set up and get started for NES programs are ASM6 and NESASM. I believe Sivak also uses NESASM, so it seems to work fine for bigger projects.

2. Tile Layer Pro is pretty much exclusively for making the 8x8 tiles for the graphics. It doesn't do anything like help you arrange background tiles into readable data for games. People usually make their own programs to ease the process of making backgrounds. If your backgrounds aren't too complicated, you can just enter the data into an ASM file. I had no problems using this method for NES Virus Cleaner, because the backgrounds were pretty much 5 or so different 16x16 tiles, and it was single-screen gaming. It all depends on how big your game is going to be, or if you need any compression at all for your backgrounds. 8name from the Pin Eight tools or the aforementioned NESST can be used to make nametables without compression, and used directly in your game. You just have to remember that each uncompressed nametable is 1k worth of data. It's all pretty much game specific.

That about covers what I needed to know, thanks guys. As far as compilers go, if it is good enough to make the Battle Kid games and your various games Khan (anxiously awaiting Study Hall and Unicorn, not to mention The Great Gatsby), it is good enough for me. As for the second question, I was beginning to guess that they were two different things, thanks Roth for helping to clarify and explain both types of programs. The power of the unicorn protects!

NESST (short for NES Screen Tool, BTW) can also export RLE-compressed data, and 6502 source of a RLE-decompressor is included in the package. Shiru himself (author of NESST) has used the program to create the levels in some of his games.

Ah, thanks for the clarification Kalle! I opened NESST real quick to look for something like that but didn't see anything right away.

I personally really like CA65 for large projects. My favorite thing about it is the ability to use segments. So if you have to spread things across different banks, it is easy to do it all in one source file and have related code and data together. The only way to do this with simpler assemblers such as nesasm or asm6, as far as I know (someone please step in and correct me if I am wrong), is to cleverly use a lot of split-up files as .includes in a higher level master file that has all the .org's and .pad's you'll need to lay out your code and data in banks. I can see that working alright----I just like the convenience and "pro feeling" of CA65. Other than the .segments feature....I know I like to use .scope and .endscope a lot, so when I use local labels I can give them nice names but be able to re-use them later without causing too much trouble. None of these considerations should be important for anybody starting out, though.

As for editors, I wrote my own graphics editor and level editor in C#. I've previously shared these for others to use, and I know at least one guy who used them to help him develop a game.

I'm sorry if you have already heard this question, and I have already asked it, but I am a Mac user and have absolutely NO idea how to program for NES games. I don't even know how to program, period. I have Xcode, but I need some help with that. What would I write first if I were to start programming an NES game in Xcode? And when it's all done, how would I convert it into an .NES file, put it onto an NES motherboard and into an NES cart? If none of this can be done in Xcode, what sort of Mac-compatible programming software can be used to do this?

XCode is just for Mac stuff, it doesn't and never will assemble NES program. Best bet, outside of virtual boxing all the programs available online, is to go buy a Windows machine. An old XP/7 tower or something.

Hmm. Well darn. Oh well. Thanks for the input anyway. I guess I should start saving my money.

But just to be clear, is most or all of the NES programming software out there Windows based?

99.99999% is windows based. There's some assemblers and such which should compile on Linux and Mac. I run Linux and have gotten ASM6 to compile quick. But most of the tools with GUI's (Namtable and graphics editors) are basically Windows only. There's one IDE, NESICIDE, that has Linux and Windows versions, but I dunno about Mac.

The NESASM and ASM6 assemblers are easily compiled for MacOS so you can make games, but right now the best greaphics tools and debuggers are Windows only. Hopefully NESICIDE will get more stable because it really is meant to be cross platform. I primarily use Xcode->NESASM->Nestopia, then drop into Parallels/XP to use FCEUX for debugging when needed. A separate box would be too much hassle.

What would be the best NES programming software for Windows? Or at least the best one that you have used? Or what you have heard other people say nice things about?

It's ALL different. On windows, NESst and YY-chr 0.99 beta 2 (?) are the best tools for nametables and graphics editing. Compilers, there's tons to chose from. Nerdy nights use NESASM3. There's ASM6, most people use that. NESICIDE's stuff...so many more. I'd worry about going over the basics and trying to understand the nerdy nights for. This stuff is so difficult, you have to do this for a while before you're qualified to know what tools to use to do anything, really.

Ok I have a vague question that is more an intellectual one, rather than an immediate programming issue. (If I were in process of programming something, I would be nowhere near as advanced as this issue in my endeavor).

Basically I am just wondering how the scrolling in BURAI FIGHTER is conceived of, especially in the Game Boy version. (I have only baaarely played the NES version and the scrolling changes direction much less than the Game Boy version, at least in the beginning of the game).

It just seems like such an unusual mechanic and I am wondering if it would be difficult to repeat.

(At least on the Game Boy version) The screen scrolls in at least 4 different directions, (perhaps 8) and at times the scrolling is not strictly imposed by the level, but rather scrolls according to the direction that the player chooses to move in. VERY STRANGE.

... So it is my understanding that SCROLLING is a very essential part of NES programming, something that the console was optimized for and one of the main things that sets it apart from its predecessors. (I assume that the Game Boy was set up in a similar way in this respect and I also assume that the NES Burai Fighter at least had SOME of the weird multi-directional scrolling of the Game Boy version). I know that the design/concept of scrolling in this game is quite unique - and I am wondering if the PROGRAMMING of this scrolling would be as obscure as it appears????

The burai fighters scrolling wouldn't bee too hard at all. Although, the main thing is, you need to develop the skills of problem solving stuff with arrays and logic as you learn. Looking at that with my experience, it's not bad at all if you plan it out right the first time. If I saw that when I was starting out, there'd be no way in hell I'd be able to write it in 100 times.

Now I have gotten ahold of NES Burai Fighter on cart, and confirmed that the scrolling definitely is much less complicated than on the Game Boy version. ... Do the differences between the two factor in at all to your answer? Is the Game Boy one still basically as simple of a programming task as the NES one?

In my dirty readings of Nerdy Nights etc, I thought I read that scrolling involved drawing the background graphics off screen, a full screen area in advance. Can this be done for a diagonal scroll???? Is diagonal scrolling more complicated than horizontal or vertical?

Yeah, diagonal scroll is kinda hard to do right, but it's still easily possible, even if it has some glitches, even the GBC game isn't too hard to do.

You don't need to draw a full screen in advance. You will draw new stuff when required. For example, if you limit the "camera" to move 8 pixels/frame in a single direction, you will need to draw at most one 8 pixel row/column per frame.

Diagonal scrolling is significantly harder to implement than simple horizontal/vertical scrolling. But it also depends on where you cap the scroll speed and other limitations you set. For example, if you never scroll more than 1-2 pixels per frame in a direction and force the scrolling to end on a 8x8 grid (could be usable in an RPG style game, or an overworld map in general), it's easier to implement than allowing the screen to scroll 16 pixels in either direction on each frame.

Interesting. Thank you for this answer.

... Even though space shooters are a totally pervasive genre of games, I actually feel that the NES is lacking in them, and it seems like a very ripe area for homebrew to me. I know that there are plenty of them on NES, but honestly almost every one of them irritates me. (Lifeforce gives me nightmares.) A lot of them feel very samey and others have colors and imagery that stress me out. ... Generally the DMG Game Boy versions are much more entertaining for me.

Burai Fighter really stands out for me as a true original, though it also has many of the colors and graphics that bother me. ... The bizarre scrolling concept seems like a technique that could be elaborated on in a new game with really interesting results.

So I've been stumped by the Nerdy Nights example below for about a year now and I think I finally understand it. Is my example underneath the original accurate?

Bump for help.

Your example seems to be correct except for a small thing: the NES will not actually render the black color from color #4 of the palette, it will always use color #0 for the background color (i.e. when the 2 bits of the pattern table tile data are %00). In other words, if the final color index is 0, 4, 8 or 12, NES will always render with color #0.

Hi, I had just wondering about debugging support... or debugging symbols more specifically...

Can nesasm produce debugging symbols? And is there a way to load them into the fceuxdsp debugger (or maybe nintendulator)?

I see nesasm generates a .fls file, which looks like a map for the labels. I also see an option for the listing output level, but as I far as I can tell it has no effect(?). Also, is there a way to dump the global variables to the .fls?

I've seen nlgen which generates fceuxdsp readable symbol maps from ca65 generated code... I assume I could write something similar that converts a .fls into a format that fceuxdsp can read(?) (or maybe it can already read a .fls?).

I am trying to make a block grab a key (nothing like a "simple" port as a first post-Pong project). I have my block, and I have a two sprite key, and I have been able to get the block to push the key successfully. However, upon contact I would like to have the key move with the block in all eight directions. I have tried several things, but either A) I cannot get the key to maintain its position relative to the block on contact, or B) I cannot get the key to both push and pull with the block. I have also tried to map the location of the key to the block sprite, but understandably it does not maintain its position relative to the block.

Looking ahead, where do sprites go when they need to be gotten rid of, say a castle gate that has been opened (and no, there is not an opened door sprite to take its place)? Are they simply turned off, moved off screen, or other things?

Any help on these questions would be great. I will be away from the internet for a couple of days, so thanks in advance!