Joined: 9/21/2009
Posts: 1047
Location: California
Found an easy (but sometimes lengthy) way to do this:
I usually use Sony Vegas to edit videos. The big timer that tells you where you are in the video/audio track(s) is a very nice tool. Right click the numbers, then go to "Time Format," and click "Absolute Frames." Now you can open your .dtm in Dolphin and use the frame counter (NOT VIs) to take note of which visual cues match up with real time frames. Edit the capture to line up the .dtm frames with the Vegas frame timer, and voilà, you have yourself an accurate encode. However, don't forget to, in Vegas, go to File > Properties, and change the project to "Double NTSC" (60 FPS).
It was that way for a while for all games in Dolphin, but it was fixed, at least for GameCube games. Maybe it's just Wii games that have that problem now.
I tried to TAS Bianco Hills 5 in Mario sunshine today, on Dolphin 3.0-415, and came across an emulation bug. When saving a savestate, all the goop that had been previously cleaned away will return. I'm using the recommended settings:
direct3d9
no dual core
no idle skipping
lle dsp compiler
enable dtk music
-------
Also, when playing back the dtm now, it desyncs due to Petey going a completely different direction than he's supposed to. I only tried playing back two times though... Still it goes to show Dolphin isn't robust yet, many others also reported desyncs in other games.
Use the tasinput and/or more-save-fixes branch. You should not ever get any desyncs using either of those branches for recording gc controllers on either gc or wii games.
We should probably have a warning somewhere telling people not to ever, ever use any version other than these for tasing.
edit: and now we have one.
I never heard about any of those branches...
I thought nitsuja's savestate fixes were implemented in the main branch. Care to link to a download for the 'more state fixes' version?
This 32bit(fix3) version seems to work fine now. I put together a collection of emulation problems in this build:
Sirena 6
Walking on goop doesn't affect Mario at allFixed by changing GraphicSettings->Hacks->EFB Copies from 'texture' to 'RAM'
When loading a savestate, any goop that's on the map has moved a bit.
Longer loading screens. See this TAS by renebalow for an example.
I don't know if these problems are present in the 64 bit version - or if changing from direct3d9 to something else could fix stuff.. At least I think people shouldn't start on an any% TAS with these flaws present in the emulator.
Guys I come from the DidyKnogRacist communite, and you are all wrong, tihs is the run of the mileniun and everyone who says otherwise dosnt know any bater! I found this run vary ease to masturbate too!!!! Don't fuck with me, I know this game so that mean I'm always right!StupedfackincommunityTASVideoz!!!!!!
Arc wrote:
I enjoyed this movie in which hands firmly gripping a shaft lead to balls deep in multiple holes.
natt wrote:
I don't want to get involved in this discussion, but as a point of fact C# is literally the first goddamn thing on that fucking page you linked did you even fucking read it
Cooljay wrote:
Mayor Haggar and Cody are such nice people for the community. Metro City's hospitals reached an all time new record of incoming patients due to their great efforts :P
Joined: 4/21/2004
Posts: 3517
Location: Stockholm, Sweden
MUGG wrote:
[*]When loading a savestate, any goop that's on the map has moved a bit.
[*]Longer loading screens. See this TAS by renebalow for an example.
[/list]
I think nitsuja indirectly knows the issue with the goop. He said he can find and/or knows a few more variables to save.
I don't think you can do much about the loading screen for now. Metroid Prime has almost no loading period. But a developer can obviously give a more thorough answer.
Nitrogenesis wrote:
Guys I come from the DidyKnogRacist communite, and you are all wrong, tihs is the run of the mileniun and everyone who says otherwise dosnt know any bater! I found this run vary ease to masturbate too!!!! Don't fuck with me, I know this game so that mean I'm always right!StupedfackincommunityTASVideoz!!!!!!
Arc wrote:
I enjoyed this movie in which hands firmly gripping a shaft lead to balls deep in multiple holes.
natt wrote:
I don't want to get involved in this discussion, but as a point of fact C# is literally the first goddamn thing on that fucking page you linked did you even fucking read it
Cooljay wrote:
Mayor Haggar and Cody are such nice people for the community. Metro City's hospitals reached an all time new record of incoming patients due to their great efforts :P
Nice job, rog! I haven't found any problems with it so far, and it's nice to be able to use the fixed savestates alongside the master branch's speed optimizations (so every game runs slightly faster whether TASing or not).
I know you said a 3.0-305 movie wouldn't sync on 3.0-378 "more-save-fixes" or later, but I decided to test my Paper Mario TTYD movie file from 3.0-305 on this new merged revision. Interestingly, the movie synced perfectly up to a very lag-dependent event (the X-Nauts encircling Mario), where 3 more lag frames were added by the game due to different timing and the movie was behind by a little bit. After that, the slightly behind movie synced fine until another lag-dependent event (the X-Nauts forming a circle again after Mario escapes) caused the buttons that clears Lord Crump's dialogue to be pressed too early to register, and then the movie wouldn't sync anymore. It could be easily fixed with hex editing if I wanted to switch revisions (which I don't), but I was just surprised that it synced that far.
365 is the exact revision that will cause desyncs (when the determinism fixes branch was merged). And i never said it would be difficult to fix, just that they won't sync as is. I never bothered to test how much the timing changed. My movie desynced on the second button press, and i saw no reason to upgrade, so that's all i know about it.
And i never said it would be difficult to fix, just that they won't sync as is.
I know you didn't say that, but I still expected it to be a big change in timing, like when I changed revisions from 7670 to 3.0-178.
Would it be a good idea to make my TAS on this new merged revision instead of 3.0-305? Are the changes from 3.0-365 onward so significant that I should switch to that revision, especially if there won't be any more sync changes in Dolphin and it could sync perfectly on a revision made a year from now?
Eh, there's really not much difference right now. The newer revisions are slightly faster, but it's not even really noticeable. If you can fix it easily enough (which it sounds like you can, and already did fix some of it) then it may be worth it, if only because it'll let you upgrade to the newest revisions as they are released. And of course for such a long game, even an extra .1 fps could make a big difference when running through 7 hours of gameplay.
edit: decided to test the speed difference. I ran my muramasa tas for two minutes in 378 and the 470 i posted above. In 378 it reached frame 3204, and in 470 it got to 3415, averaging 1.7 fps faster. Not the most conclusive test ever, but that's actually way more than i thought, and i'd definitely recommend upgrading for that reason alone.
So, i use that second number?
:(
Good to know there's an easy way to do it though.
