Dear friends, I'm more than proud and excited to present you with my latest work of art - an 101 frame (1.68 second) improvement over the published SMB2J TASv2 of mine. This run is finished in a month, which is pretty short to me as the time in needed to make a TAS is increasing, while my spare time is decreasing. Thanks to the week missing school caused by my foot accident that has saved my TAS projects. It is my passion of TAS that conquers the pain, and without other mishaps, SMB warpless TASv4 will be finished by the end of the year.
Surprising improvements
This run is more than just an 101 frame improvement, it's also an attempt to challenge the speed limit of this game. This version of the run (TASv3) did not copy any inputs from TASv2, so there would be plenty of improvements too small to be mentioned here. A comparison video is needed, I think.
1-1: Shell glitch, 84 frames saved. It was all started a year ago, when andrewg told me about his fresh idea of getting the mushroom and going through the ground in 1-1Bouncing on a shell and going through the ground. It wasn't easy, but with the help of memory watching, I somehow achieved it. Including the 21 frames saved from 1-2 due to the advantage of big Mario, it could save 63 frames tops. With the improvement founded by andrewg, everything went well until 8-4, because the fireball (Podoboo) block the way so hard, that I couldn't decide what to do. So I started to find new improvements from the beginning, and there I found one just right, which makes very good use of the red Koopa Troopa in front of the hole. Stamp on the Koopa Troopa, kick its shell, bounce into applicable height, and there we go. At first this new trick that I've found could just save 63 frames. It needed 2 frames to beat the 21 frame rule, but no matter how I tried, no matter how further I tested, there were no chances to gain that 2 frames. Coincidently, one day when I felt bored testing the right Cheep-cheep for my SMB warpless TASv4, I did a casual test for the shell in 1-1, and then I came up with the idea that I could cut the shell from its left side instead of stamping on its head. Problem solved.
1-2: Different route, 21 frames saved. We used to go through the wall until Mario's deep enough to catch up with the final lift, but I was puzzled that few one had tried the more normal route that requires a wall jump at the high pipe. Due to higher bouncing in SMB2J, to skip the narrow wall without going through it, you have to loose speed after stamping on the Goomba and hitting the wall. What seems strange to me is that loosing speed 2 times is still about 10 minutes faster than loosing speed just once in the wall, so I guess the lesson is, don't always follow the usual path. It beats the 21 frame rule far enough, and adds a lot of entertainment to this run.
8-4: Bad luck on the Podoboo, 5 frames lost; better job in the water stage, 1 frame saved. Still because of bad luck, 5 frames have to go to avoid the annoying fireball on the way. But I did a good job calculating the perfect position to dodge the last firebar, and saved 1 frame.
In total, 84 + 21 - 5 + 1 = 101 frames.
Tricks used for entertainment
Entertainment is also of importance in this run, so I not only did the following tricks, but also manipulated luck several times to change the conditions.
1x2-powered fireball for browser It was used in order to kill the browser faster in 4-4. It took only 4 fireballs to end up the battle (the one aiming at the wall is just to show Mario's anger, which doesn't count), actually, it can also be done with 3 fireballs. Please visit my personal page for more information about this trick.
Stamping on 2 enemies at the same moment; killing 2 enemies using 1 fireball A nice way to improve the entertainment. There are lots of enemies in SMB2J, so I often did it in this run.
Rolling shell clearing the way I found the beginning of 5-1 a good place for performing this trick, so I slowed the speed a little and used a beetle's shell to clear the way. Nice effect, by the way.
Mario, the music playing musician I managed to play the music using the sound effects of Mario 2 times. One at the beginning of 8-2 and one in the 4th stage in 8-4. The one in 8-2 was copied from 4-1 of my SMB warpless TASv4, I was unable to do the first notes more accurate due to the delay of level start.
I tried really hard to improve the entertainment this time, and I hope you love this run. Thanks for andrewg for giving me the first idea of the improvement in 1-1, and Mars and GAP for supporting me all the time.
Nach: Very nice run, I loved the shenanigans. The killing two enemies with one fireball, or in other surprising manners was very entertaining. Accepting as improvement to existing run.
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
I don't have ready access to a Windows machine to be able to exhaustively test configurations, but perhaps the following suggestions will help:
I don't believe VLC has been built recently enough to have a new enough version of ffmpeg to decode the videos properly, and it's not going to depend on the rest of your system codecs, so it will probably not be usable to play this back until another release of it comes out.
I do not know if ffdshow(-tryout) implements YUV444 playback. Consider grabbing the latest SVN version from here (32-bit) or here (64-bit) and seeing if that works.
I have just been reading that LAVFilters seems to support all of the requisite codec features, so that may be worth trying as well.
I've been using mplayer2 to play back the video, but that's probably more relevant for non-Windows users.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Hi sgrunt, thanks for the publish.
I compared your video files. Only MPlayer2 is able to play your 10bit444. Visually, I did not really notice a difference between the two.
There is however another difference which was rather noticeable.
The regular encode in MPlayer uses 5-10% CPU. In MPlayer2, 10-15%. The 10bit444 encode in MPlayer2 uses 35-40% CPU.
The large overhead makes it unfeasible to play back these files with older hardware. Not until they optimize it more, if possible.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
Nach wrote:
There is however another difference which was rather noticeable.
The regular encode in MPlayer uses 5-10% CPU. In MPlayer2, 10-15%. The 10bit444 encode in MPlayer2 uses 35-40% CPU.
The large overhead makes it unfeasible to play back these files with older hardware. Not until they optimize it more, if possible.
Interesting - thanks for the feedback.
I suspect the difference in visual quality is not going to be noticeable for older platforms such as the NES/FDS, but encodes for more advanced consoles will show more of a difference.
Visually, I did not really notice a difference between the two.
In the end of 1-1 there are two differences:
* The flagpole slightly flickers in the primary but not in the secondary.
* The fortress doesn't have color bleeding in the secondary but has in the primary.
(The secondary is the 10bit 444 encode).
Nach wrote:
There is however another difference which was rather noticeable.
The regular encode in MPlayer uses 5-10% CPU. In MPlayer2, 10-15%. The 10bit444 encode in MPlayer2 uses 35-40% CPU.
I see that too. For me, the figures are about 3%, 4% and 12% (in order mplayer, mplayer2 primary, mplayer2 secondary).
sgrunt wrote:
I suspect the difference in visual quality is not going to be noticeable for older platforms such as the NES/FDS, but encodes for more advanced consoles will show more of a difference.
I say it is not so much about platform but about the game. I have seen PC game that barely reacts to chroma subsampling (of course without pixeldoubling/doublescanning, because those would likely hide most of the artifacts anyway). And I have seen PC game that is really ruined by chroma subsampling.
After all, one-pixel-thick red lines on blue background (something really unfriendly to 4:2:0) can be done on the NES.
The 10-bit encode works as expected. IIRC mplayer2 with >=ffmpeg-0.8.3 should play these files just fine. I'm not sure if the quality was noticeably better, but I have understood that with 10-bit encodes you can achieve the same quality with smaller file size, i.e. usually better quality with the same file size. So I'm all for a codec change, couldn't care less about people who can't install the latest software properly.
As previously mentioned, it works like a charm with LAVFilters (using it with MPC-HC x64), but I haven't noticed the CPU usage issue mentioned earlier. I'm at 7-9% with my CPU auto-clocked (SpeedStep) down to minimum. The quality looked superb to me, and I see no problem at all with this going prime time as soon as a couple popular players are updated to support it (such as MPC-HC's internal H264 and VLC). Though, to be honest, that might not even be necessary as most people who can't be bothered to install 1 piece of software to support it would probably be content with the streaming options.
I tried playing the new encode.
Here's what I found.
I updated my machine to have the latest version of mplayer, ffmpeg, and mplayer2 as provided by my OS (Gentoo).
mplayer SVN-r32624-4.4.5: Played sound, but video was gray with noise on top
ffmpeg 0.7.5: Worked perfectly
mplayer2 2.0: Died immediately with "Unsupported PixelFormat 78"
(Off topic)
Also, I tested out mplayer2's other claims.
It says it better handles high FPS movies on nVidia cards. That's exactly the problem I have on my machine watching videos on this site. I am using the proprietary nvidia driver.
So, I put a video, let it fall behind on mplayer and reproduced it on mplayer2. Unfortunately, it behaved identically. It can't handle high FPS movies any better. (Or there's something else wrong with my machine. Or the fix is in a newer version of mplayer2.) Looks like it is still going to be watching movies in slow motion for me when it would be a problem.
It also says it has multithreading. I'm on a dual core machine. I found a movie that my computer was too slow to play at full speed.
mplayer: it wasn't able to keep up and the audio fell out of sync. It used 50% CPU (1 of the 2 cores)
ffmpeg: Seemed to use less CPU overall (38%) but once it got to a busier scene, it stopped rendering altogether.
mplayer2: CPU was at 94% and the movie played faster.
For comparison, I also tried a regular movie to see how much CPU it used. mplayer2 used slightly move CPU than mplayer for playing the movie identically. Though, for trying to use both cores when you don't need it and the extra cost of synchronizing, this is probably fair.
So, as far as I can see:
mplayer2:
Can watch this movie: No
Handles high FPS: No
Is multithreaded: Yes
