I know. But there are some issues with the current state of things about that.
To implement a taseditor that will be a client for multi-system emulation you will need to either
1) build a brand new rerecording emulator and import cores there, or
2) add taseditor to one of the existing multi-system emulators with rerecording, or even
3) add rerecording, and powerful TAS tools, and taseditor to existing multi-system emulators.
Issues:
1) Emulation scene is already full of
[just another amazing emulator that is supposed to replace the others! Or at least be an alternative...] Building
yet another one may be a waste of time by itself, also, there's a problem that you need people interested. "Emulator creep" will anyway be there.
2) There's only 1 multi-system emulator with really powerful TAS tools. And to hit the future where TASing becomes mainstream due to usability of tools, and to provide all needs of universal taseditor, it needs to be universal itself. So it needs the following, all at once:
- Work on all common systems (Windows, Mac, Linux, some others?) with no loss in how efficient is the process.
- Be as fast as possible. Loading hundreds of savestates just to navigate through the movie will only become slower and more memory consuming with adding newer system cores. How heavy is N64 RAM state? PSX's? Megabyte+. It must not be too compressed because there saving and loading states is even noticeable for an eye and harms the working flow. There's also autorestoring the playback position, which emulates on turbo to show the user the feedback as soon as possible, and don't distract too much from the TAS workflow.
- Be feature-rich. RAM watchers/editors, lua, debuggers.
- Be worked on, to keep it up-to-date with the needs of the new users.
- Be well written so that new developers don't have problems joining.
BizHawk checks a good amount of these, but:
- It won't be really compatible with Mac/Linux unless more people start actively working on it. And even where it can work by intend, it's not universal:
- Dotned makes it dependent on how well dotnet itself works on a given machine
- It is already REALLY slow once we start pushing it to the limits by adding real taseditor to it and moving to newer systems.
- Probably in the case of the newer systems, Win32 will just not handle. Either move to Win64 to use it, or buy a newer computer. I don't think many people that use neither option now will use any. They will likely just pick another emulator.
3) Developing existing widely compatible and stable, but
non-rerecording emulators up to TASing needs with taseditor and all cookies is just nonsense.
