I've already looked at it - looks quite sophisticated. He has divided up the joystick code, file browser code and graphics code into separate classes - which is the way to go instead of one single 'cell.cpp' file IMO. He uses PSGL instead of Libgcm, and apparently PSGL can automatically initialize SPUs and use one or more (not sure if this is something that has to be done totally manually by Libgcm).
Perhaps implement two renderers - take the current one, create its own separate class for it, create a PSGL version, let them both derive from an interface.
You know what disappoints me though? I've looked at the PS3 SDK samples - none of them have working analog controls setup - this PS3 Pong example doesn't as well.
In the short term, though - I want to have Snes9x read from a .cfg file, so we can put all the settings in there instead of embedding them in the 'cell.cpp' file. This is a major drag, as it means that every time you want to change settings such as SoundInputFrequency, you have to recompile the entire thing - not good.
I'd love to see bsnes on the PS3, but not enough to buy the console, mod it, and do it myself. But I can at least offer some info in case you guys want to give it a go
Your main issue in using bsnes is going to be its use of C++0x. You will need GCC 4.4 or newer to build bsnes. If you can not get that, then you will need to use bsnes v060, which doesn't have the faster performance core but is C++98. Both are under the "all downloads" link on Google Code. Alternatively you could backport the v068 code to C++98.
Next, it's nicer to use the raw bsnes API directly, but there's also the libsnes API that is basically ten functions. Give it the ROM data, hook up callbacks for video, audio, input and run. Much simpler than Snes9X' interface code.
The sound input frequency thing: basically the output frequency of the SNES is 32040hz. That's easy enough to get on the PS3, use a hermite or cubic resampler to generate 48000 output samples for every 32040 input samples.
Where it gets tricky is getting a perfect video and audio sync at the same time. There are two ways to pull that off.
Every last system, every last TV, every last video card, every last sound card, they all have minor differences. Even the exact same models do. Even SNES units have this variance. So while the SNES uses 60.09hz video out, and 32040hz audio out, our PS3 will probably be 60.01hz and 48000hz. Resampling handles audio, but you can't resample video. That difference is why sound keeps breaking up. It is cumulative across frames.
The right way: trial and error. Keep adjusting the input sample frequency. That has the effect of speeding up or slowing down emulation to match the video frequencies. It's by less than .1% so you won't notice it. There's no way to detect it, each person will have to play with the input value until they find the one that works for them alone. It does not matter whether your audio driver is blocking or not, if you do this right. It would probably be easier to convert your users to another religion or switch political ideologies than get them to understand all this though
The lazy way: you add or drop video frames, like most desktop emulators do. Say your PS3 is running at 60hz, the SNES at 60.09hz. So every ~11 seconds, the SNES creates and extra frame. Since you can't resample video, skip it. It will cause a jerk in scrolling animation for one frame every 11 seconds. But the nice part here is nobody has to adjust any values. To skip the frame, you have to triple buffer. Every time a frame is ready from the SNES, queue it up in one of your two buffers, and make that your active buffer. Every time it's time to present a screen, show the most recently drawn one. If you run too fast, it overwrites a screen and you miss it. If it runs too slow, it draws the same old screen, duplicating it. You may have to implement your own TB system using areWeInVsync() calls, if you have a piece of shit API that blocks when you have two frames pending so as to stop you from ever dropping one. Better to use page flipping than blitting here if possible.
The sadistic way: the ZSNES and Snse9X v1.51 approach was to have two sound cores running in parallel, so that one could generate the extra audio to match your Vsync rate and keep the audio buffer full no matter what. This causes serious audio distortion. It ruins echo effects, it leads to hackers making games that don't run on real hardware, etc. The only way you can do that is to go back to v1.51.
> Snes9x v1.52 is pretty good - even byuu (bsnes creator) approves of it.
I highly recommend it for portable devices, and for anything running on battery power. For older desktops, I'd recommend SNESGT. For anything else, not so much.
> the latest one released on February 2010 is lightyears ahead of the previous versions. they replaced the sound APU in version 1.52 with the one from bSNES, so sound is far superior now compared to previous versions.
If anything, v1.52 is an overall regression. A super accurate DSP core that has a significant speed penalty, which has no real effect as the CPU and SMP cores are still opcode-based. Try Earthworm Jim 2, for instance. The v1.52 Windows and Linux GUIs are a major step forward, however.
Snes9X uses blargg's SMP and DSP cores. I also use blargg's DSP core because it is bit-perfect, but blargg's SMP core is opcode-based, relatively new, and has a lot of issues that need to be ironed out. So overall bsnes' APU is far more accurate. You can see this as there are still at least 50 APU timing hacks in Snes9X (i think they're in the memmap.cpp or something.)
Despite my best efforts, the Snes9X team has never considered using any of my cores directly, or I'd be working on their team instead of on my own :/
> 1) Snes9x is still by far faster
Snes9X v1.52 is 80% faster than bsnes v068.10/performance mode, yes. But bsnes is much more than 80% more accurate, so it's not an optimization issue.
> 2) Looking on byuu's forum, people with ppc systems are still having a lot of problems compiling bsnes for ppc.
Where did you read that? Richard Bannister has maintained a PowerPC port of bsnes for four and a half years now. I even have native assembly ports of the threading library I use for PPC32 and PPC64, as well as a C-based setjmp variant. If you do port bsnes, you should try all three to see which is the fastest. I'll get into more detail on this if you want.
> In any case, even though bSNES version 0.68.1 has countless speed improvements over the other versions, it's still doubtful that it's going to run SuperFX2 games at 60fps like SNES9x does on PS3 at the moment.
bsnes can run at 80fps on a 1.6GHz in-order Intel Atom, and it can run SFX/SA1 games at 45fps on said system. So as long as the 3.2GHz PS3 is at least 50% faster than a $4, 2W netbook processor (the PS3 isn't made by Nintendo, is it?), it should be perfectly fine. I'd bet you could even use the more accurate compatibility core at full speed on a PS3.
> So, it's pretty much a given that bSNES is going to be a hell of a lot slower than SNES9x
If there is one place in the world that people don't care about CPU utilization, it'd be on a console
> This patch apparently will implement bsnes' SA-1 core into Snes9x.
zones' patch was to add code I contributed that added two missing bitmap to bitplane conversion modes, used by two golf games and SD Gundam G-NEXT. It was about 40 lines of code. Snes9X still uses its own opcode-based CPU core for SA-1 emulation. I will say that Snes9X has good SA-1 emulation. Missing a few never-used features, but that doesn't hurt compatibility. The latest ZSNES locks up with all SA-1 games.