The NES PPU conversion seems to be game to game specific.
There are two builds of the PPU simulation cores, 8x16 sprite and 8x8 sprite. I didn't consolidate them only because I hadn't run into a game that required both.. yet. APU simulation cores are the same between games (unless they're just old an not updated).
They're not game specific. The cores get upgrades as I encounter new features that games need, but other than than - the cores recompile just fine from one rom to the next (within capability). For instance, I don't have 4 screen support (rarely used) or single screen mirroring simply because I hadn't had a need for them yet. I was working on switchable H/V mirroring, but I didn't finish it (it'll probably be the last thing I do). Features to the core get added as they're needed, but they're not game specific. Game specific stuff is more like the hacking the gamepad i/o code instead of directly emulating it, and replacing LDA/STA port opcodes with JSRs to backend core support.
Not to mention the fact that the NES has hundreds of different mappers, which also affect the Nes2Pce conversion process.
If I was dedicated enough to this, I would support more mappers. There comes a point that, not if it can or can't be done, but is it worth the time to do it? And from what I've experienced so far, everything leans towards the latter.
In my mind, I've already proven it can be done. I don't need to take it further, as a proof of concept. And the challenge no longer has the luster and allure that it once did. New challenges are just on the horizon.
PS: I use the term
simulation, which is realtime in this context, to refer to the PPU/APU/MAPPER/etc
emulation. I think emulation is a valid term in relation to the ppu/apu/etc cores, minus the cpu part, but in the context of what emulation means nowadays - I've avoided it to keep the anal crowd at bay. Having this argument once was enough for me.
