All the secrets are public in the chat room, including who isnt wearing pants....

I'm not intimidated by the programming, but by the graphics and music. I am thinking of programming a euchre or hearts game, but don't know from square 1 on how to create any sort of pictures, in terms of having the artistic temperament for it. It seems like it would take me forever, so I just haven't started.

I'm in the same boat, so I hired out the music and took forever to do the graphics. Best way is to setup paint to be the number of pixels you want and build everything there first. With the portraits of characters in my game, I just took a picture of a person and then pixeled it out with 4 colors until I was semi happy with the result. Then I copied it into YY-CHR, made some edits on what messes up on the paste, and then save. I've done that with most of my graphics actually, and I am terrible at art.

 

Honestly? Lack of time.

I did assembly programming in my undergrad days. The low-level control is crucial with limited resources like this, but honestly, the effort-reward is exhausting and the readability isn't exactly there. Once you get used to newer engines, the amount you can get done for the work required makes them way more useful if I just want to sandbox an idea.

As it is, I'm writing papers for the graduate and post-graduate study, doing some teaching, working a full-time job, and trying to create and edit content for WGS videos. I barely have time to stop in the gym once in a while, let alone sit down and devote time to developing NES ASM acumen.

Thanks for this advice I think that is what has kept me from attempting my own game.  I am a pretty decent programmer as I have been doing it professionally for 16 years and have released my own mobile apps on ios and android.  The art aspect is what I thought was a barrier for me.  I may have to look into this again because assembly and C is not foriegn to me at all.

Is there a tool that can take an image and render it as best as possible into NES-appropriate pixels? Talk about something that would get me motivated to start...

Al Bailey made a tool many years ago that did this. You need to first resize the image to 256x240 pixels and then convert it to a png. Then you can import it into the tool and it does its best to convert it, but if there are way too many tiles or colors it messes up.

 

In Photoshop or GIMP...
-reduce the pixel size, 256x240 might even be too big for the effect you want
-increase the contast
-create a custom 4 color palette, using NES colors
-for faces...black, brown, pink, and off-white work good
-image mode -> indexed, choose the 4 color palette to define the indexing, slight dithering
-touch up with the pencil tool.

Even doodling in something like YY-CHR is pretty straightforward, since it won't let you use more than four colors at a time. The grid/tile lines would also make something like drawing cards for Euchre pretty easy, since you wouldn't stray outside the given bounds too much. It would just be somewhat difficult to "see" what could be re-used and what could not. Probably the easiest way would be to have two windows open at once, and copy only the unique tiles into one of the files. There are a couple of tutorials here on NA about using YY-CHR.

Assets are definitely intimidating, and I've fallen into that trap as well at times. It is even worse since I know roughly how many hours it takes to do one pose that I like (about eight), or all of the poses for a whole character (a whole month!). It always seems like time could be better spent elsewhere, even though I am sure that drawing would get quicker the more that I did it. Until then, everything uses filler graphics taken from other games. Not the worst solution, but a project doesn't really come alive for me until it has unique art in it.

KHAN / SoloGoose,

I'm really trying to get into this in earnest. The amount of development tools is actually pretty overwhelming. The nesdev guys seem to crap all over NESASM, for instance, but it's not clear why from this layperson.

Can you guys give us a rundown of all the programs you prefer in creating games, from the text editor to assembler / IDE and graphics and sound tools? I just want to pick a set of tools and go with it, if that makes sense.

I wasn't asked, but I'll reply anyway  

- normal text editor
- make / command line, normal cc65 installation
- famitracker for sound and music
- mtpaint and gimp for graphics (I work with normal PNGs, then use my own converters to get them to CHR)

No need for anything fancy really. I rarely write asm unless there's low performance, most of what I do is plain C. Oh, and I'm a Linux user, in case it wasn't obvious from the toolset.

The main reasons people dislike NESASM.

Historically, it has been kinda crappy. It wouldn't do things, usually because something in the code wasn't right. But it'd just assemble the code anyway without warning. I believe most of these things were eventually fixed by bunnyboy, but some stil exist I think.

Second reason, it forces you to use 8kb banks (unless this was fixed?). Which is annoying if you have a mapper that uses say 16kb banks, or 4kb etc etc

Third, it doesn't follow the same syntax as other 6502 assemblers. So it might use [ ] where other assemblers will use ( ). Not a HUGE deal, but stil pretty annoying.
 

Hi Daniel. Great questions.  

I've used NESASM for 7 straight years and released a number of games and have never had any issue with it compiling when it isn't supposed to. I've read lots of "issues" people have had with it, but I certainly haven't. Everytime I hear someone talk it down, like Jero tried to do, they mention "vague problems they've heard it does" but I've never seen any concrete examples.

So here are the programs I use:

Text Editing: SciTE - I used the regular notepad that comes with Windows for a number of years and it works fine, but SciTE is a little bit more customizable. On top of customizing the colors, which is nice, you can add scripts to it, so you can compile new ROMs directly in the text editor (which alleviates the need for batch files). I have mine set up to where I can launch all my other programs from inside it also, which I will mention now.

Graphics: NES Screen Tool - This is the program I use for full screen background graphics. It's nice because it automatically forces the NES' palette and attribute restrictions so you won't wind up with any surprises.

Graphics: Tile Layer Pro - This is the program I use for sprite graphics. Pretty basic, but it does what I need it to.

Music: Famitracker - Probably the most common music tracker for the NES. It has a bit of a learning curve, but I guess all of these tools do. I put music in one file and then sound effects in another and when I export the files, the sound engine I use has programs that will convert the files to the ASM format my code needs to understand it.

Hex Editing: Frhed - There's nothing special about this program, and I can't give you any specific instances when you'll need it, but whenever I need to edit one of my binary files, this is the program I use. Probably the program I use the least, but when I need it I need it.

Sound Engine: Famitone/Famitone 2 - I never took the time to really learn how to code a sound engine on my own, but thankfully people like Shiru developed tools for idiots like me who were too lazy to go through the tutorials. There are some drawbacks here, like not being able to use effects in the effects tab, but you can code these sounds directly into your instruments and still do what you want to do. The biggest thing I think it's missing is the ability to support NTCS and PAL mode. It can still use NTCS/PAL but it won't adjust the key/speed of the song, so it will sound completely different on a PAL system. But it's designed to be a small sound engine as far as space it takes up in your code, and it does its job very well.

Emulator: FCEUX - This is the go-to emulator for developers, as it has lots of built-in tools that will help your progress of coding a game. Nametable Viewers, Hex Editors, Debug tools, etc. Some of the versions have the ability to do slow motion, which is great if you want to slow everything down to 1% and see what the heck your crappy code is doing with the graphics.

Anyway, hope this helps. Keep the questions coming.
 

It's not just "I heard". I actually ran into these issues back in the day. One issue I recall is that it wouldn't alert you if a branch was too far away, so your code would just be running ..somewhere. As I mentioned I think most of these issues were fixed by bunnyboy at some point, but a lot of nesdevvers have a bad taste in their mouth because of it.

You also don't adress the 8kb bank thing or the differing syntax.

PAL/NTSC pitch and speed adjustment was in FamiTone since dawn of times, so music and effects DO sound the same on both systems.

If that is all that you've used, and all that you know, then there's not much to address.

Glad to see that you're still at it! There are a ton of dev tools out there, but you really only need a few to make a game. Any level or type of game I would think can be done with five tools, maybe less.

As for the NESASM thing, I have no clue why people hate on it. I asked the same question at some point, but never did get a real answer. I've even heard people say that real games cannot be made using it, despite many homebrews using it. Some of the best have used it. In the end, it pretty much boils down to "to each their own." If you've learned using bunnyboy's Nerdy Nights, then it makes sense to just stick with NESASM. Why complicate things further; learning is hard enough  . A lot of the folks who have been around longer, especially if they started prior to the NN, will use CA65. I hear good things about that one too, but again, don't let it complicate things any further.

I have a very minimal set of tools that I use, and do a lot of things the hard way. NES 6502 is the only programming that I know, so I still really enjoy the process of doing things long hand. No fancy tools for me! Even if I had a level editor or a screen tool, I think that I would still do things by hand. Something about being close to the code.

And since my choices are all different from KHan's, here they are:

Text Editor: Notepad++. Simple, easy, and it has two key features over regular old Notepad (which I used for six months I think?). One is that it gives you line numbers, so when the compiler spits back an error, it is easy to find. The other is that it allows for tabs, and I usually have tons open at once, so that is helpful. It also saves them, so you can restart and return to a project quickly.

Graphics: YYCHR. It is simple, light, and has a lot of features for what it is. I wrote a small guide on using it a while back. The one drawback is that it only allows you to see four colors at once, so I mainly use it for putting together my final CHR files. For actual drawing I use...

Graphics: Paint. Kevin can poke fun at me all he wants, but Paint gets the job done  . There are some relatively easy ways to import drawings from it back into YYCHR. I could go out and learn PhotoSHop or things like that, but again, why complicate things. Use what least gets in the way.

Music: ???? I still need to do music, but I'd guess Famitracker at the moment, and either Shiru's or Gradual Games' sound engine.

Hex Editor: HXD I think is the name of it. It works fine, though I do not use it a lot except when numbering ROMs.

Emulator: FCEUX is great! However, it never hurts to test in a more accurate emulator, particularly if you know that your code is right. I have spent two weeks at least chasing fictional bugs due to FCEUX. Nestopia is the other one that I use, I believe. It also has more accurate colors. FCEUX sometimes makes them too pretty/bright.

Ask as many questions as you want! We are here to help.

Use whatever the tutorials do, then once you know more you can decide what features you actually want. ASM6 and CA65 are both good options but you may also find you never change.

Text editor: XCode (mac)
Assembler: NESASM (mac)
Graphics: TLP, NESST (winxp)
Music: never!
Hex editor: HexEdit (mac)
Data tables: Excel (mac)
Emulator: Nestopia (mac) for general use, FCEUX (winxp) for debugging
Hardware: USB CopyNES + flashable carts

I apologize. Either my implementation is wrong or my emulator isn't returning accurate information. Thank you for clarifying.
 

You just need to detect PAL/NTSC first, and pass it to the library at init, so it can utilize the adjustment logic. As the detection requires interaction with the video hardware, it shouldn't be a part of a sound library.

( *** means "I like it a lot";  ** means "good enough, but could be better" )

OS: Win Xp

- Assembler
*** AlieNES (my own assembler)

- Text editor
** Notepad++ (any autocorrecting disabled, my own language style set up)

- Hex editor
*** HxD (wonderful tool)

- Emulator
*** FcEux 2.2.2 (wonderful tool)
** Nestopia (used to double check)

- Graphics
** MsPaint (limited, but good enough for NES art, one color each mause button)
** Pixel Former (better zoom, layers help design animated stuff)
** Tile Layer Pro (little bug: when scrolling it chops a tile and shifts by one all the others)

- Music (compose in midi):
** Piano Roll Composer (a nice minimal midi editor, but unfortunately the last version fails lo run on my PC)
** Aria Maestosa (crashes often, commands and display not handy, but I can't find anything better that works)
If someone can advice a better free light-weight midi editor, please do.  
 
NESASM Limits
(from my point of view)

LDX #$00
LOOP:
  TXA
  STA $FF,x
  INX
  BNE LOOP

will output: A2 00 8A 9D 00 00 E8 D0 F9

rather than: A2 00 8A 95 00 E8 D0 FA

wasting one Byte in the ROM, and 256 processor cycles when executed.

It sets an absolute,x addressing opcode, instead of a zeropage,x addressing. When trying to update stuff in the V-Blank time, cycle wasting can potentially be an issue. Moreover, since a zeropage,x addressing is expected to wrap around in the zeropage, while an absolute,x addressing does not, the program will behave differently.

***

Just my random 2 cents.

Cheers all!  
 

^devil's advocate (since everyone seems to think I was trying to shit on NESASM)

There is something to be said for an assembler not auto optimizing things, while that's probably what you want 99% of the time, there might be a scenario where you don't.

This is probably due to NESASM's origins as a PC Engine/TurboGrafx-16 assembler; all zero page addresses must be prefixed with '<' for whatever reason. While it makes more sense on a platform where "zero page" isn't actually located at $0000 (e.g. PCE/TG16, where it's in the $2000 area), it makes programming for systems where zero page is at $0000 (e.g. NES, C64) a little annoying.

I feel like I wouldn't be able to "get it" and easily learn and adapt to the new knowledge.

Wow, thanks guys. Since I'm on Windows 7, I'll start with Notepad++ / NESASM / FCEUX while playing around with the NN tutorials, then take it one step at a time from there.

The tutorials are pretty easy to understand so far. I'm still cringing at the thought of having to develop my own graphics eventually, though