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.