Posts for GWing_02

Experienced Forum User
Joined: 6/6/2005
Posts: 124
I had to resurrect this old account just to properly congratulate the team here. It's been really fun to watch it come together in slow trickles and sudden breakthroughs. After so many years of the 5 minute wall seeming so tantalizingly close and yet so insurmountable.. well done.
Experienced Forum User
Joined: 6/6/2005
Posts: 124
Slowking wrote:
Would have loved to skip through the run, even though now we know that it was probably spliced, just to see how the route looked back then.
...I've been out of it for a bit. Did not know that had happened. Just did some interesting reading. My mind is a little bit blown.
Experienced Forum User
Joined: 6/6/2005
Posts: 124
Since we're on a nostalgia/praise kick, I'll throw my cents in the bucket. I too remember when TSA's sub-5 had just come out, and we were still trying to figure out seamwalking. Now we have all these insane ways to break the game; forget the specific categories and finished submissions, the process has been the most exciting part of all this to behold. [now I go back to lurking]
Experienced Forum User
Joined: 6/6/2005
Posts: 124
I have not watched this but I look forward to it once the power comes back on here in Seattle. Which apparently won't be until Thursday. It's 28 degrees outside. It's the same temperature inside. I'm not looking forward to going home from work tonight.
Experienced Forum User
Joined: 6/6/2005
Posts: 124
The key with smashola is to drill down two-three blocks and aim for the middle of the gap between the two blocks below you after you make the one next to you blink.
Experienced Forum User
Joined: 6/6/2005
Posts: 124
...isn't it?
Experienced Forum User
Joined: 6/6/2005
Posts: 124
Time yourself on each level with a stopwatch. Some people get too engrossed with gameunits and come up with strategies that are "faster," but only in terms of gameunits. Going through pipes comes to mind.
Experienced Forum User
Joined: 6/6/2005
Posts: 124
http://dehacked.2y.net/microstorage.php/info/3056/smwrunmaybe.smv I got owned by lag in my wireless keyboard. You can see me overcompensating in the second time through... =P I'll go find a wired one... I'll be back.
Experienced Forum User
Joined: 6/6/2005
Posts: 124
I put the game in the console for the first time in years last month and got a 96 exit time of just under 2:30. Made me somewhat of a legend on my dorm floor, even though it's definitely improvable.
Experienced Forum User
Joined: 6/6/2005
Posts: 124
Yea, I was going to tackle the 15 exit (I've done one before so I know those levels pretty well; it was just a bit faster than the current at the time but I lost it with my flash drive) but since both are being done, I'll just wait.
Experienced Forum User
Joined: 6/6/2005
Posts: 124
Wheow. I stop following SMW for a couple months and everything explodes. I was thinking of picking up an SDW run, which was why I checked back here. I guess I get to be lazy for another while, or I could find tricks, which I'm not particularly good at.
Experienced Forum User
Joined: 6/6/2005
Posts: 124
Yes, yes, a thousand times yes. I intentionally eschewed reading the comments beforehand, wanting to be surprised, shocked, and awed at the improvement to this run (which I previously thought near impossible, or in the frames at most). I was surprised, shocked, and awed. Saw the glitch. Didn't register what just happened for a split second, then realized the exploit. Brilliant. I can't wait to see the new 96 with this (and presumably other) new one(s).
Experienced Forum User
Joined: 6/6/2005
Posts: 124
Fabian: it's a shame I didn't get to check in/help out with this run more (work and school kill me and leave me no time for nesvideos), because it is truly a masterpiece and a work of art. The ways you took existing ideas to new levels is amazing. Bravo.
Experienced Forum User
Joined: 6/6/2005
Posts: 124
Looks skyboxish. Like you went up and over the wall rather than through it.
Experienced Forum User
Joined: 6/6/2005
Posts: 124
Didn't know that. Hmm, so it's not as easy as I thought it was. Kind of strange why they would define any "boundary walls" if they all operate the same under normal conditions. Perhaps the defining factor for passthrough/nonpassthrough is whether or not it's a perfectly vertical wall?
Experienced Forum User
Joined: 6/6/2005
Posts: 124
Can you give me an example?
Experienced Forum User
Joined: 6/6/2005
Posts: 124
Might I point out that you simply added another post regarding calculus to a discussion that was pretty much done? Anyway, I don't think anybody read my entire post so let me restate one of the more important points in it: The environment will stop Mario. Animated sprites like the door and the gate will not, which is why it is possible to glitch past them. Read point number 1 on my long post from this morning. edit: @Fil: I know on the upwards rising platforms he simply hits A every other frame for maximum boost. I just played the movie again and it looks like for stairs he hits A every time Mario raises up to the next step until he really gets going and then he hits A every other frame.
Experienced Forum User
Joined: 6/6/2005
Posts: 124
An integral is a riemann sum which is set with limit h=0+ so that every possible infinitesimal value is calculated.
Experienced Forum User
Joined: 6/6/2005
Posts: 124
NrgSpoon wrote:
In one phrase: The programmers forgot to set a maximum reverse speed.
Well, that's letter a of number 2 in one phrase. =P
Experienced Forum User
Joined: 6/6/2005
Posts: 124
I find hopper's comment the most amusing. =P Anyway, my view of the BLJ and the physics model is this. Edit: after discussion in the chatrooms it's been determined that the movement system is most likely polar rather than cartesian (angle+velocity rather than x+y+z velocity) and so adjust everything following as necessary. The game engine (as is most game engines) is built on the principle of rendering textures in planes between vertices. The ground, for example. Everything. Well, enemies are a little different but they're irrelevant here. The point is that the game has models on the positions of planes within the game; it knows where the vertices are to render the graphics textures, and it can reuse that data for the physics engine. The physics engine, to keep it simple, probably works on one acceleration vector in terms of xaccel, yaccel, and zaccel for 3d space, and one velocity vector in terms of the three dimensions as well. The acceleration vector is quite simply, each frame, added to the velocity vector. There's presumably a detriment on the acceleration vector; friction, Asteron calls it. The velocity vector is also simple, it is simply added to the position value every frame. Before these additions occur, however, the game checks to see if the new position would violate any boundaries - if Mario's cylindrical bounding box would intersect any planes. If it does, it either allows the action by moving Mario vertically until he is in "valid" space (this would account for both stairs and slopes and as Asteron said, probably has a maximum amount) or disallows it by moving Mario as close as possible to the intended velocity vector solution without violating the boundary. Each set of vertices/each slope has an assigned friction value; this explains why you can walk up the really steep green slope or the cannon slope in BoB but not the pearly marble slope which is much flatter. I've said that much before. Issues: 1. Mario doesn't clip through the castle side walls, but he does clip through stuff like the door and the gate. After giving this issue some thought, I realized that the gate and door have one thing in common - they animate; they exist as programmable changeable objects. What I mean is that they are different in nature than walls; they must be programmable so that when Mario does the right things (gets X number of stars or sets the chain chomp free, for example), they must move out of the way or otherwise cease to exist. The walls do not. This means that they are likely handled by a different section of the engine or are handled by the physics engine differently. This is what allows Mario to pass through them but not the walls. The front of Tick Tock Clock, I guess, falls in the non-wall category. I have yet to explain this problem. Tell me if you know. edit: To clarify, I think that when the velocity vector intersects with a graphical plane, the game will test to see if moving Mario upwards up to the statically maximum allowed upwards shift (to allow for slopes and stairs) will relieve the boundary violation. When this doesn't happen, the game will simply put Mario as close as he will go before he would have clipped through the object which had intersected along the way of his next velocity-predicted position. In other words, all environmentally rendered objects (textures loaded as planes) will completely block Mario regardless of his speed. The only reason the gate and door does not is because they are handled differently, being animated and conditional; they are more sprites than environment or planes. 2. BLJ but not LJ? The biggest problem here of course is why BLJ works but not LJ because by knowing that we can explain the nature of the BLJ and use it better. There are I guess a few ways to explain the BLJ. a. There could be an artificial limit on how fast mario can accelerate which exactly equals his speed at the initial burst of a long jump, but the programmers could have limited this to a positive-only direction. This doesn't make that much sense, unless Mario works on a radial basis (angle and velocity in that angle) rather than a cartesian basis (x, y, z), but it could be. Who knows? edit: On further consideration and discussion, it's actually a given that the control scheme itself is radially based rather than cartesian. The only question left, then, is whether the physics engine itself is based on cartesian or polar coordinates. Zurreco proposes as well a hybrid system, wherein XY movement is determined radially and Z movement is an offset as it would be in cartesian systems. All three systems work in their own right, and Zurreco's hybrid system and the polar system would support this hypothesis. b. Asteron's hypothesis: the game artificially lifts you at the end of a jump. Unlikely though, you can still longjump in the single frame you have contact with the ground, and plus LJ would still boost on stairs if this were the case. c. When you BLJ, the angle of attack you come off of is different. When you LJ, you come off more horizontal, grinding you against the ground and causing ground friction before you hit the next step to longjump again. When you BLJ, you only hit the corner of the step and so friction does not occur and you can shoot right up. This would explain why some steps don't seem to work (stairs to basement, front steps), but it's kind of touch and go in that it would be pretty zany for the exact angle to have been programmed by accident to work. But hey, a glitch is a glitch, it wasn't supposed to happen anyway. d. Somehow, a BLJ isn't considered "finished" when you land. If the game considers that when you LJ again you're on the ground facing forward and it should jump again at the set velocity, then when you BLJ somehow it screws the system up. I haven't thought this one out. I think c is the most likely option here; because it seems to make the most logical sense and also it supports the only logical explanation for number 3: edit: of course, a is also likely now that we've decided that a radial system is the most logical. 3. Why BLJ doesn't work on slopes. BLJ must occur where Mario is allowed to jump again but he is not considered "on the ground" and thus a) there is no friction and b) the game doesn't jump with the same velocity but adds on to it. With a slope, Mario pushes into it differently and so he will always register as hitting the ground. So it's a combination of not being the right angle and containing contact to the ground. All that's the best I can think of right now. EDIT: For the lazy, this post could be considered long-winded and a pain to read. Heck, I had a headache rereading it. And thus, Zurreco has kindly offered this synopsis: therefore, the reason that mario can not work around static objects like walls and stairs is because they are not programmed with the ability to not exist. along with this, the BLJ has much more possibile applications than the LJ because the programmers put a velocity cap for mario only in a positive vector: when moving backwards mario is limitless
Experienced Forum User
Joined: 6/6/2005
Posts: 124
If you expected all TAS's regardless of circumstance to be frame advance and pixel perfect, I doubt even the 16-star mario 64 run would be up right now. As long as a TAS is of very high quality (which this one has been so far) and accomplishes things a normal runner obviously couldn't, I think it should be acceptable. GuanoBowl has come a VERY long way from his earliest submissions and I think this run is a very impressive TAS. As it is, since this testrun is being done with a very high quality, I vote keep.
Experienced Forum User
Joined: 6/6/2005
Posts: 124
Hey looks like this has been shaping up really nicely since I last checked. I like the reworks for entertainment, especially the penguin slide. Keep it up... (edit: entertainment, not improvement. doh)
Experienced Forum User
Joined: 6/6/2005
Posts: 124
No, hyperstroke jams him up. I've had the time vs entertainment argument before, and I think that it depends on the situation. If it's certainly entertaining, then it may merit some sacrifice. And I think the reason he does 6 then 1 on BOB is because 1 is more spectacular than 6. So 6 sets it up, and 1 takes it farther.
Experienced Forum User
Joined: 6/6/2005
Posts: 124
Hummm forgot about that. I'll go back and think some more.
Experienced Forum User
Joined: 6/6/2005
Posts: 124
Ohhh he can certainly use the same route and improve it very, very greatly. I remember watching the first versions of the chain chomp star, but this new one is the same idea, just way optimized. Same goes for the spiral, especially the point where he gets stuck halfway up and starts pressing the wrong way by accident before releasing himself... And I know this is a very, very old discussion we had, nitsuja and foda, and you may have already agrred upon something while I was on hiatus due to excessive schoolwork (9 classes and 10 hours a day at school is not healthy for you, kids!) but I finally came to a consensus in my head as the the exact workings of the hit detection/clipping engine. I remember we couldn't decide whether it operated by contact with planes or somat, but here's my final opinion: The game, like most simple physics engines, keeps a three variable record of Mario's velocity in three dimensions, a velocity vector if you will. Each computing cycle (usually per frame as in this game), the game hypothetically takes your current position and adds the velocity vector to it. Now here's where we really differed in opinion before. Programmatically speaking, here's what I think makes the most sense. Mario is programmed to consist of two bounding boxes, both of which are cylinders. The primary, outer one is compared first to not solids, but actually all planes in the level. Solids would be too expensive computationally. If no planes intersect Mario, then he's home free and the game will actually add the velocity vector for the next frame and update his position. If Mario is in collision with a plane, the game will go on to the next step, which is to compare the inner cylinder. This one is a certain amount smaller and doesn't encompass all of Mario, and is exactly as wide as the outer cylinder, just smaller height-wise. If the inner one is not colliding with the plane(s) the larger one was having issues with, this means it was probably a slope of some sort that Mario should be able to traverse (or nudge down with) and the game will calculate where Mario should be relative to that plane and his hypothetical/projected next position. If the inner cylinder has issues as well don't move Mario. The details about the inner cylinder may be slightly different, but this is the best I have. edit: post #100 yay