byuu - Dec 25, 2006
Hmm, so I've brought this up for discussion at least ten times already, but it's a very serious point. So I'll bring it up again for more input.
As everyone who follows this thread knows, there are three serious bugs in bsnes, and two line flickering bugs. Three require a cycle-based PPU renderer, two require S-DSP knowledge and testing equipment that I lack.
Now, I could also work on things that quite literally no game relies on, like half-calculated math results and such ... and indeed I intend to eventually, but it won't make any difference in any games, so releasing new versions with these fixes would have no merit outside of the five people writing new SNES code nowadays. These issues require months of time to throw at them, and for zero gain. It would be better to focus on the visible bugs first, especially considering I cannot go on forever working on this project.
So then, that only leaves me with rewriting the S-PPU. I've analyzed my code again, and I can think of no way to allow both the scanline and cycle based renderers to coexist as selectable options. The way the cycle based renderer would have to work would make the scanline one inoperable, and vice versa.
And the bigger problem being, a cycle-based PPU renderer would be too slow. If my recent modifications to S-CPU IRQs is any indication, I'm expecting a loss of 200-500% speed. If we were lucky, only a high-end Core 2 Duo would be fast enough to run bsnes at fullspeed. Probably not even then. We would be increasing the workload of what is already the most CPU intensive part of the emulator from ~225 complex operations a frame to ~76,500 less complex operations per frame. Multithreading (to take advantage of multiple cores) won't work at all, nor will super optimizations over time, and I think we can expect even less emphasis on raw processing speed as Intel and AMD both move toward "multiple cores, minimum power consumption" models. A cycle-based renderer will also completely destroy all benefits of frameskipping.
So my basic problem is: either I settle for a scanline renderer as a necessary evil, let my work stagnate, and eventually forget all that I currently know regarding SNES internals long before PCs are fast enough; or I completely destroy everyone's ability to ever enjoy any future releases of bsnes because they will, quite simply, be far too slow to be usable. The idea behind perfect accuracy at any cost is nice, but I never expected bsnes to take as much CPU power as it already does. I still like the ideal behind all the accuracy, but I wanted something usable, too. Asking an end user to at least own a modern low-end $50 processor wasn't much. Asking them to own a $1,000 C2D Extreme, is. With only one actual game benefitting to a degree anyone will ever notice, and my ever-fleeting time, I can't see a strong reason to try and write a cycle-based renderer. And yet, if I don't, then bsnes really won't get much better in regards to core accuracy. I can only add frivilous shit like special chips and add-on peripherals.
I've also been considering stripping away some features from bsnes that take away from its current accuracy. For example, I'd like to completely remove frameskipping so I can calculate RTO flags every frame. Frameskipping would just be stupid if it only offered a ~3% speedup at a frameskip of 9. Special features are nice, but they only serve to complicate my code and make it less maintainable. I'm at a point that I don't expect the underlying architecture to change much, so I want to start simplifying and streamlining it all to something I can reasonably call "finished" one day.
So once again, I'd like some opinions. This time, before just saying "yeah, go with accuracy!", realize what you're saying. It will very well mean bsnes becoming completely irrelevent as an alternative to ZSNES and SNES9x for at least the next several years. It could also potentially mean that bsnes can become near-immortal in the sense that no future emulator could really do any better, even when the hardware to run it is finally available and mainstream. It's also very likely that we'll never convince end users of the advantages of accuracy, and they'll stick with ZSNES9x forever anyway. Even if their computers can run bsnes without breaking a sweat, if ZSNES is quite literally 100x faster, it could be enough for people to avoid using bsnes anyway (there's also power consumption / battery life, game consoles, handhelds and cell phones to worry about in the future).
I would essentially be turning bsnes into a reference emulator that serves only to document hardware, rather than something people can use and enjoy, and I would for all intents and purposes, be doing it to fix only one game that's arguably already broken to begin with.
© 2006 ZSNES board - www.emusource.net/bsnes/index.html