nesdev.org

quexxon wrote:

• -- Chapter 09 - Beyond the Basics (Less common 6502 instructions, More Economic Programming Techniques)
  -- Chapter 10 - Beyond NROM (Mappers in depth - When is a mapper necessary? Which mapper should you use and how do you use it?)

I see these as more appendix-like material rather than thrown in the middle, but that's counter to your guiding principle, so I'm just stating it as my opinion. The first game you strive to create should be basic enough that it doesn't need too many cycle-counting tricks [as you laid out in your general principles], and certainly shouldn't be bigger than 16 or 32KB.

quexxon wrote: Sidebar: How to set up the work environment required for this book on Linux, Mac, and Windows systems.

Would such work environment perhaps include an IDE?

In Chapter 8, are you planning on covering background collision detection, as well? Or just sprite to sprite collision? I'm guessing the latter. It would probably be best to cover just basic collision in Chapter 8 assuming a non-scrolling game and then come back and re-cover it in Chapter 0D when you talk about scrolling. (BTW, I LOVE that you're using hex values for the chapter numbers!)

Scrolling does add some more complication to sprite and background collision. And the things you'll probably cover in Chapter 9 will be useful in scrolling collision. (e.g. using 16 bit numbers, high byte for screen number, low byte for xScroll, carry flag to inc or dec which screen the camera/objects are on once xScroll or their x coords wrap from 255 to 0 or vice versa.)

Also, are you planning on covering background compression and de-compression in your Scrolling chapter? That may be confusing to beginners, but it's essential to building a scrolling game -- unless it's a two-screen sports game or the shortest scrolling platformer you've ever played. There are also infinite methods to handle background compression, so we'd probably better discuss which would be the easiest to understand for a newb who's read up through Chapter 0D, even if it's not the most efficient. We can always explain that the reader is free to explore more efficient yet harder to understand compression methods once they are done with the book.

cpow wrote:

quexxon wrote: Sidebar: How to set up the work environment required for this book on Linux, Mac, and Windows systems.

Would such work environment perhaps include an IDE?

You whore. Just playing, Chris. Your project well deserves some whoring because it's coo', so whore away!

bigjt_2 wrote: You whore. Just playing, Chris. Your project well deserves some whoring because it's coo', so whore away!

Caught, pants down.


Seriously, though, tepples' example projects [and a few others like Shiru's full-blown Alter Ego written in C] make for wonderful tutorial projects. I'm hoping to include parts of them as template projects for starting users. Specifically, the parts such as linker configuration that everyone [myself included, sometimes] whines about as being the roadblock-to-entry for using the CC65 toolchain.

Not sure if you will find use in adding little bubble hints or tips; but it might be useful to cater to more advanced coders who may want to include some DPCM samples and reference the DPCM and controller glitch or other glitches that the hardware has.

Also not sure your intentions or your potential readers' intentions for testing environments, but if a lot of illegal opcodes are used in your main loop in Nintendulator -- even if the message menu is closed -- your emulation will significantly degrade in speed.

Just some food for thought.

tokumaru wrote:Personally, I wouldn't write much about mappers. When a person comes to the point of needing mappers, they should already be fairly experienced. Trying to introduce the concept of bankswitching too early will just confuse the hell out of people. IMO you should mention mappers and tell your readers what they are for, but not much more than that.

Thanks for the feedback everyone! Perhaps a more extensive coverage of mappers and bankswitching is best reserved for an appendix? I would like to include them because I want the appendix to be a reasonably "complete" go to reference.

cpow wrote:I see these as more appendix-like material rather than thrown in the middle, but that's counter to your guiding principle, so I'm just stating it as my opinion. The first game you strive to create should be basic enough that it doesn't need too many cycle-counting tricks [as you laid out in your general principles], and certainly shouldn't be bigger than 16 or 32KB.

The first game will certainly be at or under 16KiB and will definitely not require that the reader think too much about cycle counting. However, cutting costs will be taught as a core principle of good coding rather than an advanced programmer's trick. I've heard far too many gray-haired hackers complain that the younger generation has no conception of the cost an instruction. They're correct. Counting cycles is an essential skill that reflects a practical knowledge of the targeted hardware.

Would such work environment perhaps include an IDE?

At first, the only tools will be a text editor, an assembler, and a brain. I don't want the reader to use a time saving tool at the expense of a clear understanding of the concept being learned. I think that this is particularly the case will tile editors. However, once core concepts have been covered then other tools will certainly be introduced to save time and ease development. And, if the time is right, then a certain IDE might be a likely candidate for inclusion . All tools will need to be stable, accurate, and platform agnostic. In the appendix on tools I will include platform specific tools so that no worthy contenders get neglected, but I won't be able to recommend a tool in the main body of the text that not everyone can use (of course, this poses no problem for nesicide!).

bigjt_2 wrote:In Chapter 8, are you planning on covering background collision detection, as well? Or just sprite to sprite collision? I'm guessing the latter. It would probably be best to cover just basic collision in Chapter 8 assuming a non-scrolling game and then come back and re-cover it in Chapter 0D when you talk about scrolling.

You are correct, chapter 08 will most likely include only sprite-to-sprite collision. Background collision will be reserved for the actual game, and a more dynamic background. Like tepples' NROM template, chapter 08 will probably just use a horizontal plane and two boundary blocks for collision detection.

Also, are you planning on covering background compression and de-compression in your Scrolling chapter?

Yes, compression is too ubiquitous, and too useful, to be ignored.

cpow wrote:Specifically, the parts such as linker configuration that everyone [myself included, sometimes] whines about as being the roadblock-to-entry for using the CC65 toolchain.

CC65 linker configuration will be covered at length in some chapter; this is a very handy tool!

B00daW wrote:Not sure if you will find use in adding little bubble hints or tips; but it might be useful to cater to more advanced coders who may want to include some DPCM samples and reference the DPCM and controller glitch or other glitches that the hardware has.

As far as advanced tips go, I will probably mimic the style of old Osborne microcomputer guides, i.e. heavily-weighted text for essential topics and regular weight for deeper discussion of those topics. I will cover every every hardware "glitch" that I'm aware of (or that any kind person makes me aware of!) in the NES hardware appendix, and probably the main text as well.

Even for beginners, if its a complete guide you should cover the "beginner" mappers like UNROM. I think much more emphasis should go into game structure and design too. How to arrange a board game, platformer, scrolling shooter, etc. Could have a chapter at the end of the book for each of those with the general game concepts used?

Will also need lots more about the other apps besides assemblers like debugger/graphics/hex editors.

bunnyboy wrote:Even for beginners, if its a complete guide you should cover the "beginner" mappers like UNROM.

If you do, I'd start with CNROM, because the concept of CHR bankswitching is easier to understand (e.g. the program doesn't crash if you do something wrong). Once you have covered that, you can proceed to PRG bankswitching, but with a fixed bank (swapping the whole 32KB of PRG is a bit hardcore for beginners, IMO).

I think much more emphasis should go into game structure and design too. How to arrange a board game, platformer, scrolling shooter, etc. Could have a chapter at the end of the book for each of those with the general game concepts used?

Agreed. After introducing the basic concepts (sprites, maps, collision, physics, etc.) you could have sections for specific game types, detailing how those concepts would be applied in each case.

Speaking as an assembly illiterate beginner I'd really like to see this work start with C. I've seen many assembly based tutorials and, in the end, I still feel like the examples are blocks of arbitrary code. cpow has written an excellent IDE for NES cc65 development. Higher level languages should be the gateway drug to assembly.

If this could be steered towards NESICIDE and cc65 I'd gladly play guinea pig/baseline student for this.

quexxon wrote:-- Appendix C - Tools (Other assemblers, tile editors, NTRQ/Pulsar, etc.)

How NTRQ/Pulsar are related to homebrew development? Anyone managed to use them to make music for homebrews?

quexxon wrote:- Write daily, without exception and regardless of inclination.

Apr 13, 2012

Update README
5549e5278b Browse code
quexxon authored 5 days ago

Apr 11, 2012

first commit
7bc83b63df Browse code
quexxon authored 7 days ago

Fail.

I admit it would be mildly amusing if this were all an elaborate hoax.

He probably realized that, as the least experienced of all, my opinion to completely rewrite his tutorial for NESICIDE and cc65 was priority ONE.

As anyone who has worked with EDLIN knows it can take weeks to replace each instance of the word "assembly" with "C".

slobu wrote:He probably realized that, as the least experienced of all, my opinion to completely rewrite his tutorial for NESICIDE and cc65 was priority ONE.

The suggestion to use the CC65 toolchain was only partly slanted toward the *possibility* of adding C-language tutorial material to the work. Many have used the assembler/linker (ca65/ld65) alone without a hint of actual C code.

The suggestion to use NESICIDE was pretty selfish.

slobu wrote:As anyone who has worked with EDLIN knows it can take weeks to replace each instance of the word "assembly" with "C".

Just use "source code" then it doesn't matter.

cpow wrote:

slobu wrote:He probably realized that, as the least experienced of all, my opinion to completely rewrite his tutorial for NESICIDE and cc65 was priority ONE.

The suggestion to use the CC65 toolchain was only partly slanted toward the *possibility* of adding C-language tutorial material to the work. Many have used the assembler/linker (ca65/ld65) alone without a hint of actual C code.

The suggestion to use NESICIDE was pretty selfish.

slobu wrote:As anyone who has worked with EDLIN knows it can take weeks to replace each instance of the word "assembly" with "C".

Just use "source code" then it doesn't matter.

Sorry, was being facetious. Sometimes joking around doesn't translate well via text.

I was being serious about starting with a higher level language to ease the beginner in. I've seen enough ASM programming tutorials for ASM programmers written by ASM programmers. While people may have some familiarity with ASM when the NES came out C and other higher level languages are now the norm.

It sounds like he's too far along to change gears. Regardless, the more tutorials on NES development the better I say.

slobu wrote:It sounds like he's too far along to change gears.

Too far along? There's nothing but the README on github.

I too was being facetious and poking fun at the broken promise [daily updates]. I am very much looking forward to reading/helping--hell, I'd even volunteer to take over the project if it has truly been abandoned [though, taking over isn't the right term since I'd be inheriting a set of principles, not a partially completed product]. So part of my facetiousness was jumping in only five days after the promise was made to point out that it had already been broken. I know perfectly well from my own experience that we all have busy lives...so it was meant as a joke/prod.