This topic is for the purpose of discussing #2549: zggzdydp's N64 Mystical Ninja Starring Goemon in 2:04:49.35

As mentioned in your submission, the first half of your run contains a lot of imprecisons. There is still imprecisions in the second half, but it's far less notcitable to the average viewer, it seemed like I was watching a run made by two different authors in a way. I was impressed with how you implemented some of the tricks at the end. I guess they'll need to be implemented at the start of a new run when an improvement comes along. The emulation lag in the impact stages were complete overkill, I just hope these encoders know some magic formula to eliminate it. Yes vote for the time being.

I know the game runs slow in most parts, I would like to see an encode when it's done.

I remember playing this on my N64, it was hard. Nice to finally see this finished. I enjoyed it. yes vote.

I enjoyed it. Nice job. Yes.

I'll attempt to watch this tonight, but given how slow Mupen64 ran for me in the second half Sami's Banjo-Kazooie run, I'm not optimistic.

have you watched http://speeddemosarchive.com/MysticalNinjaStarringGoemon.html ?

I liked your run, but I'm a big fan of this game so, I'm not sure if my vote is biased or not... anyway you get my Yes vote. But if it can be improved, and even the author recognizes it, I encourage him to redo his video, if this one don't get accepted.

:( Couldn't even watch five minutes of it before Mupen became unacceptably slow, so I'm waiting on an encode.

For those viewers who have noticed improvements, could you estimate how much time in total could be saved from improved technique, additional trick inclusion, etc? Redoing a 2 hour movie is no small task...

Alright, I'm editing this as I go, so bare with me. I'm no TAS guy, so these aren't going to be perfect times The text cancel I mentioned above with benkei saves roughly 4 seconds the Shogun battle is an error on my part, it didn't save time. I'd have to say "My bad" =[ The folkypoke village timesaver's gonna be a really rough estimate, just because I'm gonna try to account for lag as much as I can (timing all of this form Mupen). without lag, I'd say from when Koryuta walks away to grabbing the fire ryo and leaves folkypoke into Tosa is about 2:50 in total from the TAS. Entering and exiting folkypoke before ascending up the stairs takes roughly 6-7 seconds additional. Getting the Fire Ryo and exiting out of the text is about 1:27, so 1:33-34 up til now. From starting to switch to Yae til the first instance it takes to start moving after warping with the dragon, it's about 37 seconds. So that comes with a total of 2:10, which is 40 seconds savings. As I said, that's a really rough estimate so it could be more or less. But, it does save a fair amount of time.

The improvement isn't even a minute, though. Heck, he still wouldn't get under the 2:04 mark. Unless there are even more improvements, I say allow the submission to continue getting votes.

Epic robot punchout. Nobody has a chance against them rapid punches. Yes.

Well, I watched the first half hour, and I was thuroughly entertained, even though this isn't a 100% run. Anyway, yes vote.

I would also like to request an encode :-)

I finally got a couple hours to try and watch this run, but my laptop slows to a crawl when trying to watch it. I don't know if it's because the Glide video plugin was used. In either case, I unfortunately cannot watch it without an encode either. As for the improvements, thanks AniMeowzerz for pointing them out! However, unless these are very well-known glitches / exploits, I wouldn't see these being cause to reject this movie. It's cool to have a collection of tricks for a v2 though.

I was able to watch this TAS at full speed using Rice video with DirectX at 800x600 (OpenGL was causing some weird polygon issues when fast forwarding, but I think that's due to my ATI card being bad at OpenGL... or at least, that's what I heard). I didn't try using Glide, but Rice looked fine, minus some weird tearing effects on the trees at times and the sepia-tone applied to the game play images in the credits did not work (due to the lack of auto-detect framebuffer emulation in Rice). The music was being a bit choppy, but I think that's due to the plugin or Mupen64 itself. I do have to say that the emulation was very choppy when I attempted to run the game at a higher resolution... I think I was trying 1280x1024 (or a step down from that). But rendering at 800x600 plus zooming in with Windows Magnifier [full screen mode] filled my screen up nicely. :) Now that I think about it, Glide might have slowdowns because this game appears to use the framebuffer to do motion blur on 3-D objects. When I watched this TAS [using Rice], the final boss fight had no motion blur at all on the boss, but only on the 2-D sprites of the arms of the robot as they punched out the boss. However, when I saw a video of a speedrun of all the big robot bosses, I noticed that the final boss had motion blur as it moved around. Since I didn't see that myself, it must have been a framebuffer effect. Since Glide automatically detects when the game needs to use the framebuffer feedback [I think that's the default setting], things like that final boss fight must have caused the emulation to really slow down...

Thanks, blahmoomoo! I was able to passably watch the movie this way (though an encode would probably still be helpful). I can see what people mean in terms of optimization; the later portions of the run really do seem tighter in terms of making jumps better. Also, there's no use of the trick to throw coins to fall slower in the first portion of the run. However, the run is skillful and entertaining. There's room for improvement, but I think it's good enough for publication currently.

For some reason I can only encode the first 18 minutes before Mupen crashes with an error suggesting I'm out of memory. I didn't think 4GB was so small an amount, but apparently I was wrong. But I'll keep trying.

I used to encode long Mupen movies on 512mb of RAM. So that isn't the problem. But this is mupen, so who knows what the problem actually is.

I'm getting a video encode of it right now, but it's going to take a good while. Mupen's running at 1/3rd of the speed. Luckily though, the video doesn't record how slow it is :P Anyways as for how well known the improvements are, that's my bad: I found those tricks out about 2 months ago for my speedrun. I had only posted about them on the SDA topic and didn't think any about TASvideos (I didn't even know a tas was being made D: ) Other than those improvements and maybe like Mitjitsu said about the maneuvering to save frames, this TAS is top-notch. I'm hoping to have this recorded and uploaded by tomorrow :) Edit: goddamnit, it crashed on me. :/

Aktan and I are actively working on this, so don't worry too much. (Do continue experimenting if you already are; it might take a while for this to go anywhere before one of us has something worth uploading.)

Yup. 18 minutes, 39 seconds, CRASH. Now it won't even give me a proper error. I think I'ma refocus my efforts on making these emulators work in OS X instead. Would at least save me some trouble. Breath not held.

Yup. 18 minutes, 39 seconds, CRASH. Now it won't even give me a proper error.

Wow, it stopped working for me at that exact same time too. 18:39. :/ What the hell. Am I gonna have to use an older version of mupen? Edit: I came up with a theoretical solution, although that means that encoding is gonna take a massively long time. Theory is that it always freezes after 18:39 of recorded video. So I'll just write down the frame that it's frozen on, replay the emu movie with the pause set at the recorded frame by -1/1/+1 (depending on where the video stops and/or on which frame the movie starts recording) , and make another video. splice them together afterwards. Think it'd work?