Generally speaking, writing your own games for retro consoles starts with C code. You’ll need to feed that through a console-specific tool-chain, and there’s certainly going to be some hoops to jump through, but if everything goes as expected, you should end up with a ROM file that can be run in an emulator or played on real hardware if you’ve got the necessary gadgetry to load it.
But NESFab takes things in a slightly different direction. While the code might look like C, it’s actually a language specifically tailored for developing games on the Nintendo Entertainment System (NES). The documentation claims that this targeted language not only compiles into considerably faster 6502 assembly than plain C on GCC or LLVM, but is designed to work around the strengths (and weaknesses) of the NES hardware.
Looking deeper into the example programs and documentation, NESFab offers quite a few quality of life features that should make developing NES games easier. For one thing, there’s integrated asset loading which automatically converts your image files into something the console can understand. One just needs to drop the image file into the source directory, open it in the code with the file function, and the build system will take care of converting it on the fly as the ROM is built. The nuances of bank switching — the organization of code and assets so they fit onto the physical ROM chips on the NES cartridge — are similarly abstracted away.
The obvious downside of NESFab is that, as with something like GB Studio, you’re going to end up putting effort into learning a programming environment that works for just one system. So before you get started, you really need to decide what your goals are. If you’re a diehard NES fan that has no interest in working on other systems, learning a language and build environment specifically geared to that console might make a certain degree of sense. But if you’d like to see your masterpiece running on more than just one system, working in straight C is still going to be your best bet.
I love to see the effort folks are still putting into the older hardware, it really shows just how far you can get with pretty basic silicon and decent optimisations.
To me this doesn’t sound like anything very different to the usual ‘Straight C’ programming methods really – you learn all you need to know about the many library you are using* to provide all those functions you didn’t have to program yourself but that are not core. Not looked into this enough to spot any real differences to C in synatax etc, but if it looks like C odds are it is so C like in use you are not really wasting time – a very transferable skill.
*At least one hopes you do, as it is perfectly possible to have no idea how the functions you are calling actually work or why it is a good/bad/secure/(etc) method for task at hand just copying the default examples, web search results or worse the ‘AI’s’ likely awful output…
True enough. A good programmer becomes a polyglot eventually. Learning additional languages becomes a matter of applying new syntax to already know patterns.
Why do people keep saying NESFab looks like C. It looks nothing like C. It is NOT a C-like language. It has more in common with python than C.