Alright, I've compiled the emulator in a zip that should correctly sync this without a problem. This is the latest stable release (Dolphin v3.0, 64bit) configured exactly as mine. All you need the submission input file, the DLC .wad, and the actual game. Change the ISO directory (Config->Paths) to point to those, install the .wad (by double clicking it in Dolphin), then highlight MM10 and play this recording!

Fyi, that contains copyrighted files (the dsp dumps).

-_- I was aware, and it's neccesary to sync correctly. I've reuploaded the zip without the offending files since my heinous crime has been highlighted. Please dump the DSP files yourself. Message me for more info.

I was able to get both 1812M and this run to sync using the build diggidoyo posted above.

Thanks for uploading the saves and verifying the run.

I've added a YT encode to the submission text. A few notes... I used the Dolphin version 3.0 build which diggidoyo posted above. Note that this is the 64 bit version. I was unable to get the 32 bit to sync. Here are the settings I used to dump: http://imageshack.us/photo/my-images/807/mm10dolphinsettings2.png/ http://imageshack.us/photo/my-images/810/mm10dolphinsettings1.png/ I allowed Dolphin to open a new window and choose the AR. It came out as 640x360. There were/are issues with the audio file which Dolphin dumps separately. The wav file was longer than the video file. As a result, I used .AssumeSampleRate in AVISynth to get it to sync up correctly. This is probably not the optimal way to do this. Due to using a non-standard sample rate, I ended up using the HD/Streaming Media encoding techniques to do the encode rather than treating it like a 512kb as I had planned. It should work fine as a temporary encode during judging. I'm not sure I should be the one to do the primary, etc. other encodes since I really am not a "pro" encoder and don't know what to do to make sure the result is up to quality standards. I think it would be wiser for me to stick to encodes which are more standard. I hope this is helpful info for future Dolphin encodes. ;) Diggidoyo did a great job with this run. I hope he continues his work on Mega Man 9. I would also love to see additional runs of the challenges in both games. I think there are plenty of branches these games could see published.

I've added a YT encode to the submission text.

The audio seems to be out of sync.

Finally got around to seeing this, not as entertaining as the Mega Man run but still excellent execution and a great watch. Yes vote.

Wow, I must admit that this is just as good, if not better, than the Megaman run you posted. I would give a YES vote if I could.

I would give a YES vote if I could.

You're a newbie, so I think you can vote. Only nobodies (people who haven't posted on the forum) and lurkers can't vote. I've always liked the Mega Man runs, and this one is great. edit: I just realized you're the guy who wanted to vote yes on the Kirby 64 run but needed to post more to do it. Sorry for telling you twice. :)

I like this movie.

Actually took the time to watch this whole thing. Awesome. Yes vote.

Even though you don't need the extra yes vote, I'll throw it in anyway. I've always enjoyed the Mega Man TAS's that use dashing much more than the static running; it adds to the excitement and seemingly-reckless nature of the run and makes it far more entertaining.

Archive.org collection http://www.archive.org/details/WiiMegaMan10usabassIn2818.25ByDiggidoyo Normal encode http://www.archive.org/download/WiiMegaMan10usabassIn2818.25ByDiggidoyo/megaman10-tas-bass-diggidoyo.mkv hi10 encode http://www.archive.org/download/WiiMegaMan10usabassIn2818.25ByDiggidoyo/megaman10-tas-bass-diggidoyo_10bit444.mkv Aspect ratio is entirely a guess. Not much to go on, but it does make "circular looking things" in the movie look circular. Video quality is generally atrocious; you can't get good video quality on a dump from this game without using hacked builds that don't sync this movie. A/V sync was hand corrected. Youtube encode blew up. Not sure why, never seen youtube fail so horribly to transcode something. Perhaps I'll try another youtube, but honestly, the one that already exists is about as good as whatever blurry mess I'd be uploading. Still, this has been on the workbench for months, so apparently no one else has been able to produce better looking encodes.[/s]

Youtube http://www.youtube.com/watch?v=hnfenkfyiTA Every direct youtube I tried to do failed to process entirely. No idea why, was just the usual avc+flac in mkv. So this is a pile of junk.

Possible screenshots (lossless from framedump, not cropped or optimized) http://www.mediafire.com/?s3v9hicqappbgqn

Hi there, at the request of natt, I was trying another dump of the movie to get better quality before publication. But the revision that you stated doesn't seem to work. Natt mentioned that you gave him a binary to use, but is there anyway that I can get the source for that binary diggidoyo?

Thanks to rog, we have some more sync information on this. It does sync with the 3.0 official release build (and the "mystery build" is in fact 3.0 release 64 bit). The main two issues are: a) it was possibly recorded with idle skipping on, which can cause desyncing. b) it was recorded with wiimote, which was not well supported at the time, so it won't sync on new revisions. The main reason why I'm trying to collect this information is for future preservation; don't want someone to come back to this run in 3 years, try to dump it, and be left scratching his head.

a) Negative b) Negative I used the same settings that I did with Mega Man 10. I used r7571 and I checked v3.0-367 and the official 3.0 release. I can check the newest revision (v3.0-458) tomorrow if that would help. I could also upload a screenshot of my entire settings.

b) Negative

This is false, mm10 does not even let you use the gc controller.

It's also necessary to disable any extension on the wiimote (nunchuck is connected by default).

Archive.org collection http://www.archive.org/details/WiiMegaMan10usabassIn2818.25ByDiggidoyo Normal encode http://www.archive.org/download/WiiMegaMan10usabassIn2818.25ByDiggidoyo/megaman10-tas-bass-diggidoyo.mkv hi10 encode http://www.archive.org/download/WiiMegaMan10usabassIn2818.25ByDiggidoyo/megaman10-tas-bass-diggidoyo_10bit444.mkv

New encodes, look much better (and WAY smaller). (URL same as old ones, as archive.org collection was updated). New youtube, full HD process: http://www.youtube.com/watch?v=poxUFFOeZl4 Technical info: No filtering: I haphazardly patched the GL renderer, stamping out every instance of GL_LINEAR I could find and replacing it with GL_NEAREST. That didn't seem to cover the final conversion for framebuffer to screen, so in addition I uncommented a code block that causes the framebuffer to be output 1:1 on the display. With that done, you get a crisp (all pointresize) image, but it's not quite right. 492 wide by 448 high, where 512 wide x 448 high is expected. So you pointresize up to 512 wide. I used trial and error to position the resize parameters exactly so that all of the single columns got doubled and none of the double columns got tripled. Then you can downsize to 256x224 easily:

PointResize (512, 448, 0.31, 0.0, 492.33, 448).PointResize (256, 224)

A/V Sync: I used a build that outputs timecodes for each frame to a text file. Scanning that revealed minimal jitter, no lag frames, and a framerate of 60750000/1014391 The audio dump was damaged however (audio dumping in Dolphin is currently a mess). After using the correct framerate and matching up the track beginnings with a delay offset, I noticed that there was still occasional drift through the course of the movie. The DMA is stopped occasionally during loading screens, causing small portions of audio silence to be missing. It was a simple, but slightly tedious matter to match it up by hand using a particular sync point (I found the sound where a boss's HP bar starts to fill up to be pretty easy to read):

az1 = DelayAudio (1.43 - 4.0/60.0).Trim (0, 13839)
az2 = DelayAudio (1.43 + 0.0/60.0).Trim (13840, 35494)
az3 = DelayAudio (1.43 + 4.0/60.0).Trim (35495, 43694)
az4 = DelayAudio (1.43 + 7.0/60.0).Trim (43695, 50104)
az5 = DelayAudio (1.43 +13.0/60.0).Trim (50105, 0)
az1 + az2 + az3 + az4 + az5

Here are the patches (off of 3.0 release, known to work on 32 bit and 64 bit) that I used: http://pastebin.com/C03cn9XB

The 10 Bit encode is choppy in a few places in VLC. With ffdshow + mpc hc it runs smooth, however. So if anybody has problems, switch players.

This movie has been published. The posts before this message apply to the submission, and posts after this message apply to the published movie. ---- [2005] Wii Mega Man 10 "Bass, Hard Mode" by diggidoyo in 28:18.25

In the normal encode, there are a few places where Bass disappears from a frame or two in Commando Man's stage. All instances seem to be after landing from a jump and immediately dashing on quicksand. The youtube encode doesn't seem to show this, probably becuase it encodes at 30fps. I'm using mpc; is anyone else seeing (or not seeing) the same thing?

In the normal encode, there are a few places where Bass disappears from a frame or two in Commando Man's stage. All instances seem to be after landing from a jump and immediately dashing on quicksand. The youtube encode doesn't seem to show this, probably becuase it encodes at 30fps. I'm using mpc; is anyone else seeing (or not seeing) the same thing?

Yeah, about that... I did get a dump at one point that didn't have that graphical glitch, but it had other problems. When I finally got stuff working to the point that I was able to create the dump that you see, that bug somehow cropped up. And I tried a bunch of Dolphin's infinity video settings and couldn't remember which one fixed it. After months of not being published and trying revision after revision to sync and source code modifications and bisecting config files (thanks for the help on that, rog!) and god knows how many hours... I just threw in the towel and hoped no one would notice. It's only a few frames anyway. Edit: The old youtube (not on the publication) http://www.youtube.com/watch?v=hnfenkfyiTA does not have that bug, because it's off a different dump. The one attached to the publication does though.

Come on natt, just redo it. This encode clearly does not meet the tasvideos standard.