Markfrizb wondered why. I think some of the reasons areIn [url=http://forums.nesdev.com/viewtopic.php?p=124696#p124696]this post[/url], byuu wrote:There's always been an extreme dearth in homebrew on the SNES. For being arguably the most popular retro gaming system ever, it sure doesn't get much programming love. And of course I know all too well many of the reasons why.
- Needing to learn two assembly language syntaxes, one for audio and one for everything else. Toward fixing this, byuu developed bass with 6502 syntax for the SPC700, but bass is really more for ROM hacks than for original homebrew. I developed a proof-of-concept reimplementation of 6502 mnemonics in ca65 macro language, which led to blargg's macro packs for SPC700 (both syntaxes) and GBZ80.
- Needing to find a good set of WAVs to turn into BRRs.
- It can be harder for your artists to make use of all 15 colors you get in a sprite or tile.
- It can be harder for your artists to make use of 3 layers.
- It can be harder for your whole team to make use of 2 Mbit, the smallest size of a well-formed SFC image.
- It took a lot longer for emulators to get to the point where testing something on an emulator produces some level of confidence that it'll work on a console; Snes9x and ZSNES were even more deceptively permissive than NESticle at times. I'm guessing this is what byuu was referring to.
- Less known working demo source code, even to the level of hello world. It takes more code to get something visible because of CHR RAM; the program has to DMA in some CHR data.
- No widely accepted freeware 65816 C compiler; even the Apple IIGS-era compilers are hard to get. This rules out rapidly developed minigames like Alter Ego, Zooming Secretary, and MineShaft.
EDIT: See also status of solutions as of December 2015.