Had an idea for a new zipping technique, I don't think I've seen it before
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.
(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 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?
Is it somehow possible to zip through the wall at the first ladder you are supposed to climb upwards? That would be awesome since the boss room is on the other side of the wall.
Why is two refils with only two switches unlikely?
nice if you could place the first 16block MB such that you could place the other 2 with only 1 jump, maybe adjust the placement of the very first MB.
This algorithm looks really promising for future runs. Perhaps you can compile this into some sort of program to make available for time-attackers. It look extremely helpful for comparing various routes.
Whenever a pixel changes, it's given a set number of frames to live, and when it expires, it's changed to the original image's equalent pixel. If it is changed again before it expires, the "frames to live" is reset. Seems to work like that to me...
For fun, I've been trying to create a version of the above-shown animation where the magnet beams are contiguous instead of flashing. Among many algorithms I tried, here's the most promising so far: http://bisqwit.iki.fi/kala/snap/rm1bombdemo2b.gif Now, who can guess how exactly the algorithm works? Hint: The animation generator has no access to the emulator's knowledge of sprites. It operates only on images. Hint 2: Except for the background (array of most commonly appeared pixels during the movie clip), the animation generator has no knowledge of future. Can someone suggest a better algorithm?
It apears that you're just OR'ing the last X frames together.
