Active player (419)
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).
RachelB
She/Her
Player (127)
Joined: 12/3/2011
Posts: 1579
sonicpacker wrote:
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.
So, i use that second number? :( Good to know there's an easy way to do it though.
Active player (419)
Joined: 9/21/2009
Posts: 1047
Location: California
RachelB
She/Her
Player (127)
Joined: 12/3/2011
Posts: 1579
No idea, it's always been that way for muramasa.
Editor, Experienced player (607)
Joined: 11/8/2010
Posts: 4012
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.
RachelB
She/Her
Player (127)
Joined: 12/3/2011
Posts: 1579
No, it's just this specific one. And probably some others too, but i've never seen it before.
Editor, Expert player (2310)
Joined: 5/15/2007
Posts: 3854
Location: Germany
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.
RachelB
She/Her
Player (127)
Joined: 12/3/2011
Posts: 1579
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.
Editor, Expert player (2310)
Joined: 5/15/2007
Posts: 3854
Location: Germany
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?
RachelB
She/Her
Player (127)
Joined: 12/3/2011
Posts: 1579
Nope, they have not been merged to the main branch yet. 32 bit - http://www.mediafire.com/?xjm5zmuwqqush1z 64 bit - http://www.mediafire.com/?b25pr1fcaxoqtms
Editor, Expert player (2310)
Joined: 5/15/2007
Posts: 3854
Location: Germany
rog wrote:
Nope, they have not been merged to the main branch yet. 32 bit - http://www.mediafire.com/?xjm5zmuwqqush1z 64 bit - http://www.mediafire.com/?b25pr1fcaxoqtms
When I try to open the 32 bit version, nothing happens at all. exceptioninfo.txt:
Unhandled Exception
  Code: 0xC0000005
Call stack info: 
     tasinputdlg.cpp(591) : TASInputDlg::UpdateFromText
     appbase.cpp(323) : wxAppConsole::HandleEvent
     event.cpp(1233) : wxEvtHandler::ProcessEventIfMatches
     event.cpp(907) : wxEventHashTable::HandleEvent
     event.cpp(1293) : wxEvtHandler::ProcessEvent
     wincmn.cpp(2661) : wxWindowBase::TryParent
     event.cpp(1306) : wxEvtHandler::ProcessEvent
     textctrl.cpp(2098) : wxTextCtrl::SendUpdateEvent
     textctrl.cpp(2137) : wxTextCtrl::MSWCommand
     window.cpp(4992) : wxWindow::HandleCommand
     window.cpp(2926) : wxWindow::MSWWindowProc
     dialog.cpp(494) : wxDialog::MSWWindowProc
     window.cpp(2618) : wxWndProc

Unhandled Exception
  Code: 0xC0000005
Call stack info: 
     0x006F0079 : ?
     wincmn.cpp(411) : wxWindowBase::SendDestroyEvent
     window.cpp(3854) : wxWindow::HandleDestroy
     window.cpp(2661) : wxWindow::MSWWindowProc
     window.cpp(2618) : wxWndProc
Additionally, WerFault.exe shows up in taskmanager with a description that would translate to "windows problem report".
RachelB
She/Her
Player (127)
Joined: 12/3/2011
Posts: 1579
Joined: 10/25/2009
Posts: 59
MUGG wrote:
rog wrote:
Nope, they have not been merged to the main branch yet. 32 bit - http://www.mediafire.com/?xjm5zmuwqqush1z 64 bit - http://www.mediafire.com/?b25pr1fcaxoqtms
When I try to open the 32 bit version, nothing happens at all. exceptioninfo.txt:
Unhandled Exception
  Code: 0xC0000005
Call stack info: 
     tasinputdlg.cpp(591) : TASInputDlg::UpdateFromText
     appbase.cpp(323) : wxAppConsole::HandleEvent
     event.cpp(1233) : wxEvtHandler::ProcessEventIfMatches
     event.cpp(907) : wxEventHashTable::HandleEvent
     event.cpp(1293) : wxEvtHandler::ProcessEvent
     wincmn.cpp(2661) : wxWindowBase::TryParent
     event.cpp(1306) : wxEvtHandler::ProcessEvent
     textctrl.cpp(2098) : wxTextCtrl::SendUpdateEvent
     textctrl.cpp(2137) : wxTextCtrl::MSWCommand
     window.cpp(4992) : wxWindow::HandleCommand
     window.cpp(2926) : wxWindow::MSWWindowProc
     dialog.cpp(494) : wxDialog::MSWWindowProc
     window.cpp(2618) : wxWndProc

Unhandled Exception
  Code: 0xC0000005
Call stack info: 
     0x006F0079 : ?
     wincmn.cpp(411) : wxWindowBase::SendDestroyEvent
     window.cpp(3854) : wxWindow::HandleDestroy
     window.cpp(2661) : wxWindow::MSWWindowProc
     window.cpp(2618) : wxWndProc
Additionally, WerFault.exe shows up in taskmanager with a description that would translate to "windows problem report".
Will you try this build and let me know if it works? http://www.mediafire.com/?qy9p7tecbyywfr6
Editor, Expert player (2310)
Joined: 5/15/2007
Posts: 3854
Location: Germany
bzb95 wrote:
Will you try this build and let me know if it works? http://www.mediafire.com/?qy9p7tecbyywfr6
exceptioninfo.txt:

Unhandled Exception
  Code: 0xC0000005
Call stack info: 
     tasinputdlg.cpp(646) : TASInputDlg::UpdateFromText
     appbase.cpp(323) : wxAppConsole::HandleEvent
     event.cpp(1233) : wxEvtHandler::ProcessEventIfMatches
     event.cpp(907) : wxEventHashTable::HandleEvent
     event.cpp(1293) : wxEvtHandler::ProcessEvent
     wincmn.cpp(2661) : wxWindowBase::TryParent
     event.cpp(1306) : wxEvtHandler::ProcessEvent
     textctrl.cpp(2098) : wxTextCtrl::SendUpdateEvent
     textctrl.cpp(2137) : wxTextCtrl::MSWCommand
     window.cpp(4992) : wxWindow::HandleCommand
     window.cpp(2926) : wxWindow::MSWWindowProc
     dialog.cpp(494) : wxDialog::MSWWindowProc
     window.cpp(2618) : wxWndProc
Joined: 10/25/2009
Posts: 59
MUGG wrote:
bzb95 wrote:
Will you try this build and let me know if it works? http://www.mediafire.com/?qy9p7tecbyywfr6
exceptioninfo.txt:

Unhandled Exception
  Code: 0xC0000005
Call stack info: 
     tasinputdlg.cpp(646) : TASInputDlg::UpdateFromText
     appbase.cpp(323) : wxAppConsole::HandleEvent
     event.cpp(1233) : wxEvtHandler::ProcessEventIfMatches
     event.cpp(907) : wxEventHashTable::HandleEvent
     event.cpp(1293) : wxEvtHandler::ProcessEvent
     wincmn.cpp(2661) : wxWindowBase::TryParent
     event.cpp(1306) : wxEvtHandler::ProcessEvent
     textctrl.cpp(2098) : wxTextCtrl::SendUpdateEvent
     textctrl.cpp(2137) : wxTextCtrl::MSWCommand
     window.cpp(4992) : wxWindow::HandleCommand
     window.cpp(2926) : wxWindow::MSWWindowProc
     dialog.cpp(494) : wxDialog::MSWWindowProc
     window.cpp(2618) : wxWndProc
well this should fix that problem but if it still crashes please post the code again mugg. http://www.mediafire.com/?9u5kyfui66nzd9k
Editor, Expert player (2310)
Joined: 5/15/2007
Posts: 3854
Location: Germany
Got the same exception info like in the previous build.
Joined: 10/25/2009
Posts: 59
64 bit - http://www.mediafire.com/?q30id4iv6kpmfj9 32 bit - http://www.mediafire.com/download.php?pl3ycrvljnnnvf4 fixes crashes from
Unhandled Exception 
  Code: 0xC0000005 
Call stack info: 
     tasinputdlg.cpp(646) : TASInputDlg::UpdateFromText 
and
Unhandled Exception 
  Code: 0xC0000005 
Call stack info: 
     tasinputdlg.cpp(591) : TASInputDlg::UpdateFromText 
[\code]
Editor, Expert player (2310)
Joined: 5/15/2007
Posts: 3854
Location: Germany
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 all Fixed 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.
Active player (432)
Joined: 4/21/2004
Posts: 3516
Location: Stockholm, Sweden
This is a very interesting branch which apparently fixes hangs and whatnot in some games. http://code.google.com/p/dolphin-emu/source/detail?r=9e398fd418027e4932a1539f7d382b70e8acc408&name=FifoBusy
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
Active player (432)
Joined: 4/21/2004
Posts: 3516
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
Editor, Experienced player (607)
Joined: 11/8/2010
Posts: 4012
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.
RachelB
She/Her
Player (127)
Joined: 12/3/2011
Posts: 1579
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.
Editor, Experienced player (607)
Joined: 11/8/2010
Posts: 4012
rog wrote:
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?
RachelB
She/Her
Player (127)
Joined: 12/3/2011
Posts: 1579
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.