LogFAQs > #979545626

I just made the repo public since it's getting some actual progress done
https://github.com/jamieyello/MNES

Sahuagin posted...

I know what you mean yes. I usually follow the rule of thumb "premature optimization is the root of all evil". once something works, then profile it and optimize it (if necessary).

Idk if it's because C# is a higher level language but I generally write keeper code off the bat so I don't have to do it again. For the NES, I really don't have to worry about optimizations outside of obvious mistakes like looking through a big list every frame, since it's not demanding anyway.

Here's an example of not optimizing that's just bad practice, 3 years ago I attempted an NES emulator. It's much sloppier and worse written. Instead of indexing all opcodes and their methods in an array to be called directly, I just created a giant switch statement with all opcodes. This is surprisingly very common practice for NES emulators.

Old;
https://github.com/jamieyello/JNES/blob/master/NES/Machine.cs#L415

New;
https://github.com/jamieyello/MNES/blob/master/MNES.Core/Machine/CPU/Cpu.cs#L151
(which then gets indexed here)
https://github.com/jamieyello/MNES/blob/master/MNES.Core/Machine/CPU/Cpu.cs#L792

Sahuagin posted...

I mean though that you would have to also implement the APU instructions, which would require playing 8-bit audio on a modern system, somehow. (or something, not sure). same with graphics, you will need to have a graphics library and render to a surface and present it to the screen, etc.

I'm pretty familiar with MonoGame/Godot, and graphically I think both of those will be adequate enough to use without even writing shader code. At worst I'll have to do a palette swap shader.

As for audio, I assume that base .NET will have something to manage waveforms and output those as soundwaves, or a nuget package will exist to do it for me. Or I'll just write it custom.