Player (71)
Joined: 8/24/2004
Posts: 2562
Location: Sweden
Would it be possible to add something like savestates and recording+re-recording in wine perhaps? If so then we could be making TAS:es for many games I suppose? I know that wine is not an emulator, but maby it could be possible?
Editor, Active player (297)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Wine doesn't emulate. It's just a mechanism that allows the Windows programs to run (by loading the EXE and providing libraries on which the Windows programs depend). Therefore, it's highly dependent on the CPU it's running on, as well as the conditions of the operating system. A re-recording system must be self-sustained that doesn't rely on outside aspects.
Emulator Coder, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
Another possible problem is that the kernel interface would need to be more seriously altered. Besides saving the state of a multi-megabyte running application, any files changed may need to be restored. The prorgam will need to be denied internet access, and the system clock will need to be simulated and corrected for. And as Bisqwit said, Wine doesn't emulate a whole CPU. It's just a re-implementation of Windows and an EXE loader. To save the state of a running program, you'll need external help, either through a ptrace or kernel assistance. Wine alone can't easily do it. So, uh, not happening any time soon. Doing rerecording (and slowdown?) in Wine would be months of work.
Editor, Active player (297)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
DeHackEd wrote:
Besides saving the state of a multi-megabyte running application, any files changed may need to be restored.
And, things like the X11 windows, which have portability issues, like the used colourspaces, display resolution, font sizes etc etc, and possible pending error situations, which Wine really has no control over. A re-recording windows-program-runner would need to be completely sandboxed, including its own CPU emulation, own window manager, own graphics driver, own network, own filesystem, own clock, etc. It's best done by the means of PC emulation such as vmware, Bochs or QEMU. Such environment could theoretically be rerecorded. But even if using a such emulator, you'd still need to define exactly what is the system you're running (the complete filesystem contents, including the Windows installation, file modification dates etc). Porting the movies would be next to impossible unless you accept the fact that the movies would be >= 600 MB in size regardless of their duration. (Not to mention the fact that they'd distribute proprietary software, which is illegal.)
Player (71)
Joined: 8/24/2004
Posts: 2562
Location: Sweden
Ok. So no good idea I guess. Perhaps easier to implant the recording/re-recording in ScummVM and DosBOX then?
Former player
Joined: 11/13/2005
Posts: 1587
Highness wrote:
Perhaps easier to implant the recording/re-recording in ScummVM and DosBOX then?
It would be great if ScummVM could get recording.
Player (71)
Joined: 8/24/2004
Posts: 2562
Location: Sweden
Yeah. That would be cool indeed! I'm currently planning to do a regular speed run for Monkey Island 3, the curse of.... All I will need is practice and a screen capture utility.
Former player
Joined: 11/13/2005
Posts: 1587
Tell me what your time was and then I'm gonna beat it ;)
Player (71)
Joined: 8/24/2004
Posts: 2562
Location: Sweden
Well.. This is not in any way a record. I haven't played it since I switched to win2k I think, which is WAY back in time now. :D From the date I installed it, it took 9 days to complete. But of course it was not active playing time. Two major factors included: 1. I work ALOT now days. So more or less I only logon my computer to check emails and recent posts on a couple of forums before going to bed and away to work again. 2. As I had not played the game in a long time I had forgotten most of it, which is of course, part of the fun. 3. My computer crashed one or two days after installing. So I was without a working computer for about 7 days or so. I know that I'm able to beat this game in a couple of hours. Or even less. I don't even know what would be a good time to beat this game in. I will start to work on a minimalist to-do guide for this game soon.
Player (71)
Joined: 8/24/2004
Posts: 2562
Location: Sweden
I made another test. Beat the game in exactly two hours. But thats because I was writing stuff down all the time as well. So it should be fairly easy to do it sub-two hours. One annoying part in the game could be the sword fights. They are rather boring if it goes bad. :( There is a command to skip it. But I think it's cheating.
Player (68)
Joined: 3/11/2004
Posts: 1058
Location: Reykjaví­k, Ísland
Did someone say re-recording in DOSBox? I agree, that would be amazingly amazing...
Joined: 7/28/2005
Posts: 13
Location: UNCA, North Carolina, US
DeHackEd wrote:
the system clock will need to be simulated and corrected for.
This is actually pretty easy. I've written two small programs that do DLL interception to screw with the clock. One simply multiplied it by a value stored in a config file (so 0.5 would run it at half speed, 2.0 would double the speed), and the other let me hit a hotkey and switch between a bunch of preset speeds (from 1/16th speed to 32X speed). The problem is that it's not very simple to do this genericly, so I had to write each one to the program I was modifying (3D Movie Maker and Cave Story) The other problem (from a recording standpoint, which I wasn't doing) is that PCs aren't consoles: You don't really have "frames" of output. If you were getting 60 FPS originally, you'll probably get 60 FPS when running at half speed. So you can't just record all the frames produced and resync them. (Also the multiple-speed recording would play plenty of havoc with recording resyncing) Another problem would be sound: In both apps, sound played at 100% speed no matter the setting (MIDI music was slowed/sped up), but sound effects were the same (I assume because DirectX has its own timing systems). So your sound synchronization goes right out the window, even after you find a way to fix the above problems. This can't be used for re-recording, sadly (Both programs would freak out if you tried to make the clock go backwards). But doing slo-mo recording is certainly possible, if the above problems can be corrected. Recording could be done by simply making the speed-adjuster do the recording. It knows the speed-multiplier, so it can adjust how fast it takes pictures inversely. Sound is still a problem though. (Although I usually played Cave Story with the mutepatch, heh)
Player (71)
Joined: 8/24/2004
Posts: 2562
Location: Sweden
How about outputting the material to some sort of video format directly then? If the program can rerecord to an avi or something and then change the speed in the avi so it looks real-time? Perhaps this is generally a bad idea. But I'm hungover so I don't feel too bright right now. :D Allthough this would probably be against the rules since we can't check the button-presses.
Joined: 7/28/2005
Posts: 13
Location: UNCA, North Carolina, US
It work fine for video, but sound would be nuts. DirectX (and the win32api sound playing functions that a few games use) maintain their own timers, so sound effects play at full speed.
Player (71)
Joined: 8/24/2004
Posts: 2562
Location: Sweden
Ah. That sucks.
Banned User
Joined: 5/2/2009
Posts: 121
Travis Wells wrote:
DeHackEd wrote:
the system clock will need to be simulated and corrected for.
This is actually pretty easy. I've written two small programs that do DLL interception to screw with the clock. One simply multiplied it by a value stored in a config file (so 0.5 would run it at half speed, 2.0 would double the speed), and the other let me hit a hotkey and switch between a bunch of preset speeds (from 1/16th speed to 32X speed). The problem is that it's not very simple to do this genericly, so I had to write each one to the program I was modifying (3D Movie Maker and Cave Story) The other problem (from a recording standpoint, which I wasn't doing) is that PCs aren't consoles: You don't really have "frames" of output. If you were getting 60 FPS originally, you'll probably get 60 FPS when running at half speed. So you can't just record all the frames produced and resync them. (Also the multiple-speed recording would play plenty of havoc with recording resyncing) Another problem would be sound: In both apps, sound played at 100% speed no matter the setting (MIDI music was slowed/sped up), but sound effects were the same (I assume because DirectX has its own timing systems). So your sound synchronization goes right out the window, even after you find a way to fix the above problems. This can't be used for re-recording, sadly (Both programs would freak out if you tried to make the clock go backwards). But doing slo-mo recording is certainly possible, if the above problems can be corrected. Recording could be done by simply making the speed-adjuster do the recording. It knows the speed-multiplier, so it can adjust how fast it takes pictures inversely. Sound is still a problem though. (Although I usually played Cave Story with the mutepatch, heh)
The audio in most of those apps would have to be resizes and rencoded to play at a different speed, or would require a module of sorts that resizes the audio. Midis are not recorded audio, they are note files the computer plays on the sound card. So if you were to change speeds several times a minute...you would need a monster of a machine [like 16GB or something mad] to reprocess those sounds every single time. In short the sound will have to be either muted or sound odd.
[00:31:12] <stickie> by the way, thanks for the sig sixofour [00:31:23] <sixofour> dejavu [00:31:25] <sixofour> what sig? [00:31:55] <stickie> you will just have to find out *insert mystical music*