Experienced Forum User, Published Author, Experienced player
(626)
Joined: 4/5/2014
Posts: 459
feos wrote:
Okay, I got avsync to build and run. But it doesn't look possible to properly merge it with master, at least under tortoisegit that I'm using. It only can Switch/Checkout master to a given revision, add avsnc submodule, and "commit" it to master. I can't seem to merge avsync submodule with master though. And when I choose "commit submodule to master", it waits forever while figuring out changes.
There's a solution for command line, but I don't understand how it can be translated to tortoisegit:
If you have two projects, proj1 and proj2 and want to merge changes of proj1 into proj2, you would do it like this:
# in proj2:
git remote add proj1 path/to/proj1
git fetch proj1
git merge proj1/master # or whichever branch you want to merge
Choosing "Merge" from avsync tells everything is updated, but doesn't touch master. Choosing it from master wants to merge my local state to the main tree it seems. There's an option to merge a branch to master, but I can't add a separate repo by URL as a branch...
EDIT:
Phew! I think I got it. Rightclick on master -> TortoiseGit -> Pull. ("The difference between pull and fetch is: Pull will merge remote branch change to local branch which tracked with remote branch. Fetch just get change from remote branch and never merge.")
Then simply use an avsync repo as a remote URL and pick a needed remote branch from that repo. Compiling the result of that right now...
Can you guys confirm it's how it should be done? TortoiseGit steps:
1. Git Clone -> google.code or github URL.
2. Switch/Checkput -> desired Commit.
3. Pull -> Arbitrary URL to avsync repo, desired Remote Branch from it.
4. Build Dolphin_2010.sln!
If so, then before building, one needs to go to VideoCommon -> Util -> AVIDump.cpp, cut
Language: c
if (timecodes)
{
std::fclose (timecodes);
timecodes = 0;
}
out of AVIDump::CloseFile() and put it to AVIDump::Stop(), right?
EDIT:
I noticed one more thing. Whenever I dump on x86 XP, overlapping windows break Dolphin capture by freezing it where the window is, and it doesn't happen to the same build on x64 7. What could be the reason for that? Dumping method doesn't affect it.
Could be a bug with that particular version of Dolphin you're using
Experienced Forum User, Published Author, Experienced player
(626)
Joined: 4/5/2014
Posts: 459
feos wrote:
I have a question. How does one actually patch a given revision of Dolphin to add avsync to it? Say I checked out some old 3.0-dirty crap. What do I do next? Force some automatic merge with something? 2 year gap must break everything. Or is it some known set of files/functions that you add again and again? Or a patch that always is tweaked by hand?
I usually merge by hand for stuff with a lot of conflicts, but I do use a diff tool for revisions not that far apart
Experienced Forum User, Published Author, Experienced player
(626)
Joined: 4/5/2014
Posts: 459
keylie wrote:
I may know what is going on, I think the dump feature is skipping frames.
Here is the screenshot of VI 635, 636 and 637 in the ikaruga WIP (http://tasvideos.org/userfiles/info/18954596001392115)
And from the video dump, frames 1132 and 1133:
revision?
EDIT: nevermind, found out the revision.
EDIT 2: This is a bug with Windows video dumping (VFW). This issue is not present in linux (libav).
Experienced Forum User, Published Author, Experienced player
(626)
Joined: 4/5/2014
Posts: 459
hegyak wrote:
All multi-byte integers are little-endian.
That answers that about Tick. Go figure. It goes crazy high fast.
0x0E5 N/A 12 Reserved
0x0ED Integer 8 Tick Count
I think something is wrong here. Why write 12 bytes of reserved data over the Tick Count's value? Or should that have been written as 0xF5 N/A 12 Reserved?
Typo, forgot to change that when working on the file format stuff.
The error was unrelated to that.
Experienced Forum User, Published Author, Experienced player
(626)
Joined: 4/5/2014
Posts: 459
Apologies about that, I've been extremely busy and have been having issues with dumping the run.
I noticed that a better run was produced, but I'll be holding off on encoding that one
Experienced Forum User, Published Author, Experienced player
(626)
Joined: 4/5/2014
Posts: 459
CoolKirby wrote:
Also, I believe the calculated time is incorrect. According to my A/V synced encode, the final input occurs at 2:17.504, or 2:17.50. Could someone please correct it?
Turns out there was a bug in the implementation of the tick count. I've fixed this in a newer version of Dolphin, I just need to backport the fix into 2235 (and/or make a special build which fixes the time)
EDIT: fixed http://tasvideos.org/userfiles/info/16612016375629578
Experienced Forum User, Published Author, Experienced player
(626)
Joined: 4/5/2014
Posts: 459
jlun2 wrote:
RachelB wrote:
(posting in English because i'm tired and don't feel like thinking right now)
We can't merge natt's a/v sync hack because there are a few problems with it, and it's not very clean code. Someone is planning to rewrite the video dumping feature from scratch, but it's going to take a while. In the mean time, we unfortunately, just have to keep doing what we have been.
I know this is kinda late, but is there an issue report on this so I can follow the progress?
phire is apparently looking into the video dumping side of things, but the current code is a bit convoluted.
Experienced Forum User, Published Author, Experienced player
(626)
Joined: 4/5/2014
Posts: 459
Just got confirmation from JMC47 that the physics in F-Zero GX are currently wrong on the latest version of Dolphin.
There is currently a PR in progress that will fix this issue (and a bunch of other games who have their replays desync)
Experienced Forum User, Published Author, Experienced player
(626)
Joined: 4/5/2014
Posts: 459
jlun2 wrote:
jlun2 wrote:
1. Regarding CPU cycles, isn't that what Dolphin now does? How difficult would it be to implement something like that in BizHawk as well?
Uh....now that this is published, has this been addressed yet? :o
Edit: Also why is this a new branch as of posting?
Dolphin now adds the total tick count to the movie file (this was necessary for wii runs that used the wiimote), and the parser divides that tick count by the CPU MHz to get the time in seconds.
Experienced Forum User, Published Author, Experienced player
(626)
Joined: 4/5/2014
Posts: 459
Zzyzzyxx wrote:
If the game is as bad as you're saying maybe you could choose a more entertaining game for demonstrating the zapper support, unless there isn't other viable option.
Experienced Forum User, Published Author, Experienced player
(626)
Joined: 4/5/2014
Posts: 459
It is possible for me to back port these changes to an earlier version of Dolphin.
However, if you're working on a Gamecube run on an earlier version of Dolphin, you shouldn't run into any issues with incorrect times (the warning is a catch-all for previous versions of the file format)
And from the video dump, frames 1132 and 1133:
