strat wrote:While some of the best games we'll ever play are on the 16-bit consoles (including MD/Gen and PCE/TG-16), I think they're the worst targets for homebrew dev because for all the complexity they're quite middling in what can be accomplished.
This sounds rather defeationist to me, and Unholy Night as an example is rather disingenuous. I don't think that game's issues are strictly tied to the SNES. The quality of the art and music pales in comparison to releases from the 16-bit era. And heck, pretty much every other piece of SNES homebrew I've played was better programmed than this. It's almost like you picked this game specifically to discourage people from making homebrew.
I guess I'm just getting increasingly tired of the endless pessimism I'm seeing out of a thing that I actually think is Pretty Freaking Cool and deserves more attention than it's got.
Still, if anyone insists, I can't see a SNES tutorial being effective without demanding prior knowledge of NES (likewise 65816 from 6502).
I have basically zero working knowledge of the NES and I'm doing fine. I also don't understand why 6502 knowledge would be a prerequisite to learning the 65816. In fact, I'm having a hard time imagining even programming an 8-bit processor. It just seems like something that would constantly get in your way.
Out of curiosity I've been browsing the NES section of these forums as well as some other NES resources. I know this isn't first-hand experience with NES development but it's still to me an eye-opener. Here is what I discovered:
- No native 16-bit arithmetic (obviously). There's so much game-related infrastructure I can think of that's, say, just barely outside the 8-bit range but is easily represented via 16-bit values. Timers, score, object positions, pointers, etc. etc. Yes, you can use the carry flag for addition and subtraction, but for comparisons it becomes more complex.
- You can't just follow a function pointer on the 6502. You have to do a song and dance with the stack to get it to work, and this costs significant CPU time compared to the 65816 which can do this natively. And function pointers are (IMHO) rather important to making code that's flexible and reusable.
- No hardware multiply/divide.
- To initialize RAM you have to use a tight loop in software. You can't just tell DMA to fill a region with zeroes.
- You can't use DMA to do nametable transfers.
- You have to resort to positional interrupt tricks just to get two large objects moving independently, and even then you're severely limited.
I'm sure there's more that I've forgotten. I've had a NES programmer pop in once while I was streaming SNES homebrew programming. They were in awe that I had 8kB of readily accessible RAM to play with. We take a lot for granted in SNES land.
As for past experience and working knowledge, I remember when I was looking into C/C++ programming and came upon the following advice: Essentially, don't learn all of C if you intend to be working mainly in C++, because you're going to be spending a lot of time unlearning old C habits that are counter-productive in C++, because C++ does some things differently. I suspect the same applies here. Yes, there is some transferable knowledge, but it'd be advisable that folks only train themselves in what is transferable, as anything else may just be an unproductive use of time.