1 2
9 10 11
15 16
Joined: 8/23/2008
Posts: 417
I think he means "palate".
I will not use self-reference in my signature.
Post subject: some nico vids
Active player (497)
Joined: 11/19/2007
Posts: 128
I was searching for some yoshi's island runs on nicovideo and found a 100% test run from 4-3 to 4-8 that somebody made. It doesn't look optimised at all, but it's pretty fun to watch. For anybody who's interested. http://www.nicovideo.jp/watch/sm12154271 http://www.nicozon.net/watch/sm12154271 Also, I found a room-by-room comparison video of our world 1 against spezzafer's. http://www.nicovideo.jp/watch/sm12331641 http://www.nicozon.net/watch/sm12331641
Post subject: Walljump! it's possible
Experienced player (618)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
I managed to do a wall jump on the U version of the game. It works exactly the same way as in SMW and SMB3, except with 16 times more precision. You need a speed of at least 3 pixels per frame +1 subpixel. (769) I did it in this video with 818. how it works? lodge yourself at least 3 pixels into the wall, and approximately at the 16 pixel vertical boundary (it doesn't really matter, you don't need to be too precise vertically) If you would hit the wall normally at frame x, slow dow JUST enough so that you'll hit the wall at frame X+1. The higher the speed, the more likely you are to snag the wall. don't even think about trying a walljump with a speed of 769, because you only have a 1/769 chance of it happening. Fast forward to frame 17100. My TAS keyboard setup doesn't lend itself nicely to real-time playing. everything before 17100 is major fail. http://dehacked.2y.net/microstorage.php/info/622110559/walljump.smv EDIT: BTW, If I learned anything here, it's that this game is shit hard to TAS. I think these guys deserve a big hand.
Measure once. Cut twice.
Experienced player (618)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
I managed to walljump twice on the same wall, and elevate about 5(?) blocks: http://dehacked.2y.net/microstorage.php/info/309207451/walljump2.smv Does not use <><or><>< that I'm aware of. fast forward to 10500 EDIT: a bit of a tutorial for Baxter, who asked for it. Forgive me if I covered stuff everyone already knew or takes for granted. I tried to write it so that n00bs with a little background knowledge can understand. (best case scenario) Technical details and conditions for a walljump. Basically, to do a walljump, you must lodge yourself at least 4 pixels into the wall, and approximately at a 16 pixel boundary. Vertical positioning is the easiest part of a walljump, so I'll tackle that first. You don't need to be precise at all, in fact, if you don't have the right vertical position first try, you are extremely unlucky! Try jumping slightly higher or lower, an you will get it soon enough with maybe one or two more tries. Yoshi will warp automatically to the nearest 16 pixel boundary above his feet when he snags a wall, so sometimes, you can gain a little bit extra height, this can be useful when you jump twice on the same wall, because then you might be able to elevate an extra block for each jump. Horizontal positioning is much more difficult, you should try optimising your horizontal position before your vertical. You have to move 4 pixels into the wall. There is no 2D Mario or Yoshi game in existence (maybe New SMB or Yoshi's story) that detects collisions more accurately than single pixels. You might have a low subpixel value and your enemy might have a high one, but you will still collide if the pixels in your hitbox do, even though you might be a good 200 subpixels away. What does this have to do with walljumping? For a walljump, you must go into the wall at least 4 pixels, but isn't 4 pixels a speed of 1024, and the highest we can achieve is low 800s? This is true, but because the game doesn't care about collisions more precise than a pixel, we can trick the game into thinking we have a higher speed for one frame. Of course, in the long run, all the gains and losses cancel out, but if we were to put all our fish in one basket, we can achieve a speed of 4 pixels for one frame only, which is all we really need. let's say out x pixel position is 0, but we have a high subpixel position, say the best case scenario of 0xFF. let's say that on this frame we also have the highest speed which (correct me if I'm wrong) is 765 + 56 = 821 = 0x335. This is good. It means we have a speed of 3 pixels, and 0x35 subpixels. The next frame we shall have a subpixel position of 0x34 and a pixel position of 4. Great! we have just traveled 4 pixels in one frame. In summary: in order to do a walljump: you must have a reasonable vertical position, and must travel at least 4 pixels into the wall, to do this, on the frame before you snag the wall, you must have a high subpixel value (or low subpixel if you're traveling to the left) and a speed of more than 3 pixels per frame. Some ways to do this: There is no trial and error involved in walljumping. You don't just jump at a wall until you get a result. There is a process involved to get you closer and closer to the snag. In general, if you TAS something and you don't have a process to get to the final outcome, then you are doing it wrong. (I thought I might mention this because the guy who found it on the E version basically did just this, also it's conforting to know that if you follow some steps, there is a guarantee of an outcome at the end.) I won't go into any detail about vertical positioning, since it's just too easy. Jump higher and lower until you get a result. Horizontal positioning is difficult. If you know how to be precise, then this should be really easy, and you should be able to find your own methods that work. let's say we have an average speed of 760, and we're in the air, so it stays at that value. Just before the wall press <>>, so that your x velocity goes 760, 704, 760, 0. If it goes 760, 704, 760, 816, 0, then you pressed <>> too early If it goes 760, 704, 0, you pressed it too late. Remember the frame that you started to press <>> on (call it X), also remeber the frame that your x velocity turned to 0. Turn back time a good 30 or so frames. and lose just enough subpixels so that your velocity now goes 760, 704, 760, 816, 0 when you press <>> on frame X. You should now snag the wall. If you didn't snag the wall, you probably need to be more precise. Doing a double walljump. So you know how to be precise? Well then this is basically the same as a single walljump. Accelerate away from the wall after the first jump, and then start a flutter back. Turn around so that after you accelerate from the flutter, you hit the wall so that you *just* hit it with a velocity of 816 or 821 or whatever. Walljumping a second time is easy, making it optimal is hard. Here are some considerations: Try to make the shortest flutter possible, because you can't accelerate past 375 or whatever it is during a flutter. Don't go further away from the wall than you need to, because you will waste time coming back to the wall. Try to optimise your position during acceleration/decelleration (generally through the use of null input), as this usually the fastest way to get a precise enough position. Try to elevate as many blocks as possible in a single jump, so that you can elevate higher walls with less jumps, or shorter walls quicker. In my video I managed 4. 5 should definitely be possible. 6 is impossible, because you can't jump that high anyway. If this wall of text wasn't enough to explain walljumping, PM me, and I'll make a video tutorial.
Measure once. Cut twice.
Skilled player (1402)
Joined: 5/31/2004
Posts: 1821
Thanks a lot for this very detailed writeup, I was able to walljump in no time :)
P.JBoy
Any
Editor
Joined: 3/25/2006
Posts: 850
Location: stuck in Pandora's box HELLPP!!!
Why is it Yoshi has to be 4 pixels in the wall? Is that the ejection velocity or something?
Experienced player (618)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
The ejection velocity is one pixel per frame. Asking that question is like asking why is water wet? The reason that it is 4 pixels is due to the fact that the programmers made it so, when they made the collision system for blocks. I know 4 games with a similar collision detection systems and all of them have different walljumping velocities. Super mario bros. 3 and Super mario world need 3 pixels, Tiny toon adventures requires 4, Super mario bros. requires 2. apart from that, all of these games have the same walljumping requirements, but it seems that the speed required is arbitrary. That reminds me, Tiny toon adventures had a "jump through blocks" velocity of 4, and a walljumping velocity of 4 too. Maybe yoshi's island has the same system. I think it would be worth a try to see if you can jump through a block in SMW2.
Measure once. Cut twice.
Player (172)
Joined: 12/28/2007
Posts: 235
Location: Japan, Sapporo
I forgot to post this sample movie: http://dehacked.2y.net/microstorage.php/info/64769252/yi-walljump.smv One thing to be noted is that, when you try a walljump, it seems better to watch s000B4 (next x speed) than s000A8.
x speed = (current x position) - (previous x position)
next x speed = (next x position) - (current x position)
The x speed gets reset to 0 at the same time yoshi touches the wall, so it won't correctly tell us what we need, while the next x speed will do. For example, in the above movie, the second walljump looks to be at a speed of 728, but actually is at 784.
Retired because of that deletion event. Projects (WIP RIP): VIP3 all-exits "almost capeless yoshiless", VIP2 all-exits, TSRP2 "normal run"
Experienced player (618)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
I was just wondering how this TAS is going. I hope I didn't ruin it too much by executing a walljump. Baxter has been giving me some previews of some of the later levels (thanks Baxter), up to 2-5, so I was just wondering how this TAS is going. This is my no.1 anticipated TAS at the moment.
Measure once. Cut twice.
Skilled player (1402)
Joined: 5/31/2004
Posts: 1821
Right, the current status of this run. So using the walljump saves time in several places. This is a very crude summary of some important places where time can be saved using the walljump. 1-1 ~10 frames 1-6 ~50 frames 1-8 ~100 frames 2-4 and 2-5 lots 3-1 and 3-2 a bit Our wip when the walljump was discovered played up to about half of 3-3. Now the question is, should we redo and from where? Some opinions on this would be nice, but I might as well mention what we had in mind. We spent lots of time optimizing everything, and wouldn't like it if people felt like they were watching something very improvable. We were thinking about redoing from 1-6. The walljump in 1-1 only saves 10 frames, and redoing 5 entire levels for this seems to cost way too many hours of work. The 1-6 improvement is bigger, and the 1-8 improvement is 'only' 2 levels away. Redoing from 1-6 does mean that the run will take even longer than it's already taking. We're also not quite sure yet if we should release (some more of) the now obsolete current wip if we redo.
Editor, Experienced player (730)
Joined: 6/13/2006
Posts: 3300
Location: Massachussetts, USA
if you expect that redoing the entire run will yield new things, than perhaps a WIP would be nice. if it's going to look like nothing new except for the walljumps, I'd keep it secret for now. Good call on redoing after 1-5. 10 frames isn't worth redoing 4 stages.
Homepage ☣ Retired
Senior Moderator
Joined: 8/4/2005
Posts: 5770
Location: Away
Likewise, I think 1-6 would be the sanest place to redo from (I take it the game isn't hexable?), and a WIP would be nice to have just in case as an appetizer for the future walljump awesomeness.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
darkszero
He/Him
Joined: 7/12/2009
Posts: 181
Location: São Paulo, Brazil
From what I know this game isn't hexable, right? Depending on how much work it is to redo the levels: Not Much: redo starting from 1-8 A Lot: redo starting from 2-4 As much as some improvements are nice, I find that starting parts of a 100% not being as optmized as the latter parts is acceptable.
Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Do not redo at all. Just use the trick from now on. It is not uncommon for new tricks to be discovered during the making of long runs like this, and if one had to redo every time this happens, one would just get stuck redoing all the time. Instead, finish the run, and then leave the improvements of the early parts to a v2 run later.
Patashu
He/Him
Joined: 10/2/2005
Posts: 4017
I second not redoing. Leave it as an incentive to improve the run in the future.
My Chiptune music, made in Famitracker: http://soundcloud.com/patashu My twitch. I stream mostly shmups & rhythm games http://twitch.tv/patashu My youtube, again shmups and rhythm games and misc stuff: http://youtube.com/user/patashu
Joined: 5/12/2009
Posts: 748
Location: Brazil
Keep it the way it is now and just use the new trick from now on. Also, after the run is submited, you guys can point the improvements with some smvs showing the places where and how the run can be optimized.
BigBoct
He/Him
Editor, Former player
Joined: 8/9/2007
Posts: 1692
Location: Tiffin/Republic, OH
I'll add my hat to the "save it for a v2" camp.
Previous Name: boct1584
Editor, Skilled player (1405)
Joined: 3/31/2010
Posts: 2086
Ideally, I'd like you to redo from 1-1, but I realize that this would put months of work at waste. So, either do it the whole way or just continue like this and save it for v2.
Skilled player (1402)
Joined: 5/31/2004
Posts: 1821
There won't be a V2, at least not from NxCy or me. If, after many years, we manage to finish the TAS, we are certainly not gonna spend another few years to include a few improvements. (That time could be spend better doing something new.)
darkszero wrote:
From what I know this game isn't hexable, right?
Tiny parts at most. Everything that involves enemies or stars is random, and will cause desyncs.
Joined: 7/2/2007
Posts: 3960
I'd say that if the improvements would gain you more than 1% of the length of movie that you'd have to redo, then it's worth redoing; otherwise, just carry on from where you are.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Joined: 6/4/2009
Posts: 570
Location: 33°07'41"S, 160°42'04"W
I think you should, at least, try, to redo everything.
Joined: 7/2/2007
Posts: 3960
That kind of attitude will break down quickly if they continue to find more improvements in earlier levels, though. Is it worth redoing a one-hour movie for a 10-frame improvement? Probably not. For a 100-frame improvement? 1000-frame? You have to make the cutoff somewhere, and it depends largely on how big the improvement is compared to how much of the movie you've completed, and how willing you are to redo segments.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Joined: 9/12/2009
Posts: 42
Comicalflop wrote:
if you expect that redoing the entire run will yield new things, than perhaps a WIP would be nice. if it's going to look like nothing new except for the walljumps, I'd keep it secret for now. Good call on redoing after 1-5. 10 frames isn't worth redoing 4 stages.
I agree with this. I don't mind waiting if there's major improvements to be had especially for probably going to be one of the best runs on this site. 10 frame improvement for 5 stages would be hell to do so from 1-6 sounds fairly reasonable. The "easier" part now is that you know what you are supposed to do so route planning isn't going ot take any time. It's just grinding through the levels
Joined: 5/12/2009
Posts: 748
Location: Brazil
Hello guys, i'm just curious about the run. Are you guys still working on it? Well, i really hope so! The wips are amazing.
Joined: 4/29/2005
Posts: 1212
I bet they're still working it it. That or the run drove them both completely insane so they threw themselves off a bridge or something.
1 2
9 10 11
15 16