Since Psx Tas is now possible and Arcade, Wii, Gamecube will be soon possible, will the Pc (dos) Tas become a reality some days?
What does the emulator need to be Tas Functionnal?
will the Pc (dos) Tas will become a reality some days?
That would be splendid indeed. However, the problems with DOSBox are still the same as they were one page ago. Unless someone radically rewrites it, or devises a yet another DOS emulator alltogether, it's not becoming feasible yet.
On the topic of writing a new DOS emulator from scratch: The problem with DOS emulation is not with the CPU; there are plenty of very good x86 emulators; even virtual machines could be used (those are fast but very likely non-deterministic). The problem is with implementing all the details, such as the VGA chip, the soundcard chips, and the IRQ and DMA controllers. Writing them from scratch is beyond my resources.
The problems with DOSBox are:
― Recursive function calls (CPU emulator, which elapses time, can call DOS functions, which call the CPU emulator, which elapses more time). If a savestate is made in the midst of a DOS function (such as DOS "wait for a key press"), restoring the savestate becomes impossible to the need to restore the function call stack within the emulator itself.
― Pointer data embedded within the component emulators ― pointers to objects those components themselves know nothing about. Saving that data, and restoring it, is very tricky. Saving a raw pointer means that the value is only valid as long as that particular memory region is allocated. It may be already invalid when the state is loaded, especially if the emulator was restarted in the meantime.
― Bad abstraction of host resources ― DOS I/O on DOSBox depends on the exact state of the host system's state. This makes it very bad for replayable movie files. Especially if you add the requirement that playing back a movie file should not mess up your system. (You don't want to playback a movie that types in the commands "mount y c:\", "cd y:\windows" and "del *.*" if you're a Windows user).
My patch mitigated most of these problems by the minimal measure necessary to make a TAS of Star Control II, but taking it any further would have meant rewriting significant portions of the entire emulator ― an undertaking which I haven't got resources for. I rewrote the filesystem abstraction (for only the parts that were required by SC2) and the keyboard abstraction (the same) and changed the CPU emulation loop such that it does not have the recursion problem (savestate making was simply prohibited in the nested levels, which means that savestates could not be made when the program is waiting for DOS input) and works in a predictable manner (but it turned out to be non-predictable regardless, as proven by the fact that I could not playback FractalFusion Keen TAS).
When talking about virtual machines then.
What happens when you save a state in VMWare for example?
Is this something virtually near what you (Bisqwit) are describing for states of memory regions and pointers?
Could this be done through a virtual RAM-memory that is recorded to a file of some sort to simulate the states of the memory etc?
I'm just throwing words a bit here to get a better understandment, because to me it doesn't seem all clear to why this could not work on an easier level, even though I understand that it takes a lot of skills and efforts to put this together.
I really find this interesting, but I don't understand the in-depth of it at all. :)
Cheers
If you're looking for the Windows version, here it is:
FractalFusion wrote:
Here is Windows rr-v0.5:
http://www.mediafire.com/download.php?jnydy5nrgno
As Bisqwit already stated, there is no way to record AVI (unless it syncs on a Linux version, which it won't). So you are on your own. Or you can get me to see if I can play it, just to check its compatibility, which is quite unknown.
Inspired by this new DOSBox savestate project started by this Korean fellow, I took my own rerecording project out from the naphthaline.
To my surprise, suddenly the rerecording version of DOSBox (alpha3) seems to work for me again without any problem. It have successfully played back the SC2 TAS on a 64-bit Windows7 laptop on Cygwin, and on the same Linux AthlonXP that I created the TAS with in the first place. It desyncs _if_ there is some lag on the host computer, such as the DOSBox window frame being moved around on the desktop, or nesvideos_piece recording raw video through LAN, but leave both alone and it plays just fine. And I found that a differing version of SDL.dll can also cause desyncs.
I'm making a HQ encoding of the Star Control II TAS finally :)
Alas, I still can't make FractalFusion's Keen6 movie sync.
Okay, this is the fifth time I try to encode SC2 and the second time on another computer, and what happens, every time, is the SIS ship flies right through Sa-Matra without activating the final battle, as if the Sa-Matra was not even there even though it clearly is. Movie syncs properly, game just acts buggy. I think this is some kind of copy protection measure; the game has detected itself as pirate or something. Which is weird, I don't think I have changed anything since I made the movie...
I have to do research.
It's a shame that this project got abandoned and that nobody else (at least that I know of) isn't making a DosBox patch which would support movie re-recording. Anybody knows about any other Dos emulator that supports re-recording? Except for JPC-RR, I can't get that working correctly.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
