I've been reading through the featureset of libsnes recently (a good in-depth is at http://gitorious.org/bsnes/bsnes/blobs/51c1d242eae7271b55e61d488e00359c154bf180/bsnes/ui-libsnes/libsnes.hpp), and it seems to have all of the basic requirements for tool assisted recording, as well as features its competitors lack (subframe input and best-in-class emulation accuracy). Google and forum searches of tasvideos don't seem to bring up much discussion about it though; a few hits for bsnes but they all seem to be outdated. I'm wondering what the scoop is currently and if there are any plans to move to libsnes TASing.
I've been reading through the featureset of libsnes recently (a good in-depth is at http://gitorious.org/bsnes/bsnes/blobs/51c1d242eae7271b55e61d488e00359c154bf180/bsnes/ui-libsnes/libsnes.hpp), and it seems to have all of the basic requirements for tool assisted recording, as well as features its competitors lack (subframe input and best-in-class emulation accuracy). Google and forum searches of tasvideos don't seem to bring up much discussion about it though; a few hits for bsnes but they all seem to be outdated. I'm wondering what the scoop is currently and if there are any plans to move to libsnes TASing.
I have looked at libsnes...
Note that libsnes.hpp is only a fraction of functionality of the library. There are also the following problems (that I have identified so far):
From needs pretty much rerecording emulator just to test category:
* Nobody has actually tried, so no idea about how sync-stable it is.
* Savestates can be only made on certain spots, no idea how frequent.
From known sync instability category:
* RTC emulation uses real time (fortunately, games using RTC are rare).
From annoying category:
* Firmware files (for the DSP chips) are accessed internally, so one must load them from the filesystem (one can set path, but not provide the firmware image).
* Sub-frame input may be possible (apart from problems it causes with emulator movie code), but what looks to be the most useful such input (sub-frame reset to corrupt SRAM in specific way) doesn't look to be so.
* Oh, and it is somewhat slow: You need pretty fast computer to run compatibility accuracy core (really the only core that matters with rerecording) at full speed. Forget actually fast "fast forward" on any current computer.
On positive note, libsnes doesn't just emulate SNES, it emulates SGB too.
* Savestates can be only made on certain spots, no idea how frequent.
* Sub-frame input may be possible (apart from problems it causes with emulator movie code), but what looks to be the most useful such input (sub-frame reset to corrupt SRAM in specific way) doesn't look to be so.
I can't find the source offhand, but I believe byuu said that snes_serialize () runs at most a handful of extra cycles before reaching a "saveable state" This would make frame-level advance easy and while cycle-level advance isn't possible, you'd still have an improvement over snes9x with that.
Other than the sync-stable issue, which as you say, no one knows either way, the other points seem rather minor.
I can't find the source offhand, but I believe byuu said that snes_serialize () runs at most a handful of extra cycles before reaching a "saveable state" This would make frame-level advance easy and while cycle-level advance isn't possible, you'd still have an improvement over snes9x with that.
Actually, looks like one would have to mess with debugger to get this to work (and If I'm reading correctly, one could implement cycle-accurate resets using that). Unfortunately, I'm not sure of performance impact of just including the debugging infrastructure (I guess I would need to compile bsnes with debugging enabled to find out; EDIT: Looks like building debugging isn't very great performance hit)
I don'ẗ think it is going to work without that, as System::run() very likely steps a frame, and System::runtosave() doesn't look it will run anything if system is already at stable point.
