I don't supose you can use the jump at a different walking animation frame technique to change this, or chain together the temporarily lower technique, that is, through some combination of jumping become temporarily lower then temporarily lower from the already temporarily lower posistion?
(The script created for creating this mosaic animation can be found here.)
Using 1 beam in the pit (instead of 0 or 2) is a mistake - it merely slows down falling, which is why it's slowest. 2 is fastest. I estimate it would have been about 943 frames long (990 after weapon switch compensation).
However, I think the total gain of this technique is too small to justify the big number of beams used. The gain is approximately equivalent to the gain of a 3 block wide zipping.
EDIT: I also tested the 1-beam way, former "S" route. It would be 997 frames (1044 after weapons switch compensation). It's the slowest of all, because the zipping is so minimal and it prevents doing weapon switching in the tunnel while dropping (the beam is still active).
I was thinking of doing something similar at end of the bombman's level after passing through that second wall, could you use the jump in a wall and be temporarily lower technique to pull this off?
(FCM)
Almost, but not quite. The beam goes 1 pixel too low.
It doesn't allow any fancy techniques except suicide by jumping.
Had an idea for a new zipping technique, I don't think I've seen it before
About how many frames does a jump save opposed to climbing that distance?
what about Perfection Achieved Through Savestates And Slowdown? PATSAS or Perfectly Recorded Using Special Tools PRUST wow these are really cool new words i invented, we should use it
Sonic 2 got a star without retracting Sonic 3's star to boot. Did Bisqwit just decide that two more stars was ok, or what?
I suggest everone dont modify or cut the metadata.
Here I was thinking jump off that ledge under the MB before you place the first MB, maybe you can change the nature of the pause so you only go the required height to get on the ledge.
Then I was wondering if you considered not doing the 3 MB in a row part to zip a short distance, and instead using these MBs elsewhere.
when I compared to quietust video for example, there appears to be a dramatic difference in quality
It's input accepted by the console (which is being emulated), so for that reason alone, I don't see a problem. Tool-assisted speedruns are all about injecting console-accepted input in order to get a certain result
AVI is being re-encoded once. It will be downloadable within a few moments.
What's wrong with the movie, why can't we download the avi?
But yeah like I said its a Bi-cubic nearest sample codec like Full Screen Anti-Aliasing
Also I remind you that they update the H.264 codec daily
Remember that you shouldn't resize the input. If you are recording a NES video (NES always outputs at 256x224 (NTSC) or 256x240 (PAL)), you should _not_ resize it to any other size prior to encoding. If you resize it, you'll lose quality. But, you _are_ encouraged to specify the aspect ratio (such as 4:3) to the AVI file. The player can resize the movie to any size it wants (and if the aspect ratio is given, it'll take it into account) and it usually is done using the acceleration features of the display card, so it doesn't add any encoding/decoding overhead. But I understand if you are encoding a movie of a 3D game which should be rendered at as high resolution as possible. But only if the original (the game) is indeed as high resolution.
Two-pass x264 (5.4 MB) http://stud.cmd.hro.nl/0766400/zooi/x264_500KBS_2PASS.avi Two-pass DivX (5.4 MB) http://stud.cmd.hro.nl/0766400/zooi/DivX_500KBS_2PASS.avi
