On the NES (or other 6502 machines), use assembly. That CPU just isn't a good target for C - pointers are awkward, you can't really do stack frames, and the addressing modes don't even support 'structs' very well. Fun to program assembly on, though. For your purpose the NES makes it double hard because it hardly has any ram (2 KB, and typically an additional 8 KB inside each cartridge except in the oldest games), and a character-mode graphics architecture rather than a framebuffer. If you do really want to do an 8-bit flight sim, the Atari 400/800 machines are an okay target. The Atari ST would be a better target.
Speaking of those machines, I'd love to see someone deeply reverse engineer the pseudo-voxel/fractal landscape engine that Lucasfilm Games invented for Rescue on Fractalus, Koronis Rift, etc. It still seems completely magical that they could pull that off on a machine with those specs.
Starting from zero, you might start at a high level and work your way down. Do a simple polygon flight engine using OpenGL and your favorite high level language of choice. Then write your own polygon rasterizer that you can overlay versus the OpenGL rendering as a reference. Then maybe rework it in pseudo 8-bit code (C constrained to only unsigned char variables, or similar), which should translate directly to assembly language on the target of choice. On a real 8-bit machine, unless you want low single digit frame rates, you probably have to pull a lot of dirty tricks. Maybe a 16-bit platform would be a better choice. This is speculative - I learned 3D (to a novice degree..) on a 486 PC under 16-bit DOS using C and assembly for inner loops (bitblts, texture mapping).
There's something about the aesthetic of late 80s PC flight sims (F-19 Stealth Fighter, LHX Attack Chopper, etc.) and their flat shaded polygon graphics that feels in vogue right now. Check out Thunder Helix on Steam.
Anyway there's definitely a magical feeling writing graphics code when you get your first feeling of realistic movement and rotation in 3D space working. Hopefully the ubiquity of ultra-realistic doesn't diminish that sensation too much.
Speaking of those machines, I'd love to see someone deeply reverse engineer the pseudo-voxel/fractal landscape engine that Lucasfilm Games invented for Rescue on Fractalus, Koronis Rift, etc. It still seems completely magical that they could pull that off on a machine with those specs.
Starting from zero, you might start at a high level and work your way down. Do a simple polygon flight engine using OpenGL and your favorite high level language of choice. Then write your own polygon rasterizer that you can overlay versus the OpenGL rendering as a reference. Then maybe rework it in pseudo 8-bit code (C constrained to only unsigned char variables, or similar), which should translate directly to assembly language on the target of choice. On a real 8-bit machine, unless you want low single digit frame rates, you probably have to pull a lot of dirty tricks. Maybe a 16-bit platform would be a better choice. This is speculative - I learned 3D (to a novice degree..) on a 486 PC under 16-bit DOS using C and assembly for inner loops (bitblts, texture mapping).
There's something about the aesthetic of late 80s PC flight sims (F-19 Stealth Fighter, LHX Attack Chopper, etc.) and their flat shaded polygon graphics that feels in vogue right now. Check out Thunder Helix on Steam.
Anyway there's definitely a magical feeling writing graphics code when you get your first feeling of realistic movement and rotation in 3D space working. Hopefully the ubiquity of ultra-realistic doesn't diminish that sensation too much.