|« View previous topic | View next topic »|
|Index » F-Zero GX » Tool-Assisted Speedrun(s)||Goto page Previous 1, 2, 3, 4|
Here is the first TAS ever made of F-Zero GX: http://www.youtube.com/watch?v=I1AsNpV4c0U
The result isn't that amazing, and that's because I can't play perfectly with the board. There isn't any option to ''Frame Advance'' either, which is a huge loss for optimization.
To those of you who does not know what a TAS is, a TAS is a run made with an emulator where special tools are available, such as: frame-by-frame speed, and re-recording from save states, which are used constantly throughout the run in order to make it as optimal as possible.
Note: When Snaking is optimized, it looks quite different from what we have been used to see. Formerly, it was optimal to make wide Snaking patterns to gain as much speed as possible. However, in a TAS, by alternating between L+left & right+R every other frame,
-Tool-Assisted Snaking technique, discovered by Mugg1991. Alternate technique name would be Shaking.
YouTube playlist of most F-ZERO GX TASes made so far: http://www.youtube.com/playlist?list=PL9B347D67216AA868
2nd smaller TAS topic which was made later for whatever reason:
that's good to hear. can you record it from console?
i'm now tempted to order a 3rd party card for this. i could record in HD since my capture card is an HD card and i have GC component cables.
btw, Darkeye sent you a PM on twitch. he wants to ask you about GX emulation.
|"Patience is useful in any moment"|
Of course I can record it from console, but the replay file still refuses to work. (Although I'm not sure yet if the replay would work if the replay mode could just let the replay play).
It would be cool if you could get a 3rd party card, too. Then perhaps you could test this with my NTSC SOLS TAS? I'm pretty sure the ghost will work for SOLS, but not sure about the replay. It will probably end after the countdown, but I still think it would be nice to have someone to confirm it.
|"Patience is useful in any moment"|
Good to hear that. You will also need an SD card.
By the way, I have finally given up trying to get the file to work. It will not work unless you're really good at editing .GCI files, (which I'm not). Therefore, I'm wondering if I should upload the incomplete run like a ''CTT TAS demo''? If anyone's interested? I think it is a bad idea to waste even more time on this, so I'll rather try to redo the run instead if I find motivation to it maybe next year or so.
|"Patience is useful in any moment"|
|"Patience is useful in any moment"|
New TAS on Mute City - Sonic Oval in 0'11"245! - (05"851 + 02"770 + 02"624)
I made version 1 of this TAS back in April 2015, but due to dissatisfaction, I decided to redo the whole thing again. I couldn't find motivation to do so until last month, but at least it eventually happened. The final result of getting 11"245 is definitely a time I am content with. Version 1 of this TAS was basically on pace for 12"9 (06"397 + 03"500 + 03"0xx). With the 2nd iteration, I estimated the time to end up around 12"5, with the flaws from V1 fixed. This should give you an idea of how much ASB and BS techniques helped out for the final result. It's pretty interesting how lap 2 and lap 3 got their good and bad sections when compared against each other. The lap 2 strategy travels in higher average speed in the first half, but doesn't cut the corners as much as lap 3 does. The lap 3 strategy falls just barely behind until near the end, where it ultimately ends up being the fastest, because of how it's possible to align perfectly into the two last checkpoints required for the lap to count. I made a quick visual drawing below to give you a better idea of where I'm aiming to travel in the TAS for it to count. The machine needs to be positioned within the semi-transparent area for at least one frame in order for the two mandatory checkpoints to register. As seen in the TAS, lap 3 was definitely the most optimal in this regard, which was doable because of the early alignment from ground level with super high speed. This means that if I decided to redo this TAS yet again, I think I could potentially lower it down to 11"0, or maybe even 10"9? With that said, I certainly have no intentions of making another TAS of this course.
EDIT: Forgot to mention that below is an image made specifically for the checkpoints in the 2nd corner. The 1st corner does have a very similar placement of the required checkpoints, though. Also keep in mind that this is not considered as Space Flying. This is just pushing the limits of the path, similar to the jump from MCSG in Max Speed and Snaking records. Push the path too far, and the machine will explode upon collision.
Overall, I spent approximately 115 hours on this TAS with approximately 60000 re-records. Much of which was spent testing like... 10 different lap 3 paths that didn't end up working in the end, lol.
Explanation of TAS techniques which were utilized in this TAS:
There hasn't been a lot of talk about this technique, so worth to give it another reminder in this topic (considering that a lot of people still have no clue about what it is). Shaking is essentially frame-perfect Snaking, alternating L+Left and R+Right every other frame, without timing error. This allows the machine to exceed beyond the speed limitation of traditional Snaking strides, as well as having quicker acceleration. One last and more unknown addition from Shaking is what I prefer to call "Momentum Storage". This is an instant increase in speed that occurs as you cancel an extended Shaking line, or utilize a boost. In the MCSO TAS, Shaking was only utilized in the first few seconds, and is very detectable if you watch the video in reduced playback speed.
"Momentum Storage (MS)"
This is a technique which can be done in real-time in some occasions for both Max Speed and Snaking, but it's a much more saturated effect from cancelling an extended Shaking line. You might have noticed from some Shaking videos that long lines of Shaking suddenly bursts a few hundred km/h as the tech is cancelled, or interrupted by boosting. This is speed that builds up after drifting over extended time. In the MCSO TAS, this came in handy for getting just enough speed for the MTSISB to work near the start.
"Airborne Shift Boost (ASB)"
ASB (Airborne Shift Boost) was to great assistance in building greater speed when gliding above and beyond the railings of several sections. Without these Shift Boost, the average speed during airborne time would have been quite a bit lower, so this is really an excellent discovery that has much potential. The way it works to what I've noticed so far, is that:
EDIT: I forgot to mention that I have yet to confirm if this works with edges that have no railings.
Another thing that's worth to mention is that the gravity plane only affect the machine during frames that meet "most" of the above requirements. I say most, because you can get influence from the gravity plane without getting a Shift Boost. It's just that if you're misaligned too much, there won't be any influence on the machine at all.
"Broken Steering (BS)"
This technique allows the steering radius to break in airborne state. As far as real-time goes, this has only been an instant flight killer whenever it occurs on accident, since it's practically impossible to control, or even trigger on demand. This technique never really had a name, but after enough research, I would say "Broken Steering" is the most defining name. What I figured out is that the L&R buttons cannot trigger the glitch, and neither can the vertical axis of the control stick. What triggers the glitch ultimately is the horizontal axis of the control stick, with requirement of having high input towards either left or right. What position the machine needs to have as you move the control stick is still uncertain, and because of that, you need to test quite relentlessly before getting a favored outcome of this technique. So yeah... it's quite a BS tech in that regard.
This is pretty much all I have to share for now. Hopefully it will be easier to understand what's going on in detail with this TAS. Pretty groundbreaking knowledge that has built up after making this one. While many future TASes will be more complicated to create than ever, they will display further potential that we probably won't ever be able mimic in real-time.
Those are some very interesting physics exploits that seem to be insanely hard to trigger.
I'm definitely trying to implement them in the GPMR maxspeed TAS I'm planning to work on in the next few weeks.
However I guess it is harder to trigger those weird tricks in a maxspeed setting, because weird stuff like that seem to happen more likely in snaking runs from my experience (it's just a feeling).
Also do boostplates have any effect on those techniques (except for reducing the speedgain from shiftboosts), or do you go for the boostplates for the better speed maintainance via MT ?
Btw. I plan to use Gallant there to get a MTS into shiftboost quickly just like in OSMS if that matters.
I think it is a bit easier to pull off Broken Steering with max acceleration due to the more sensitive steering, and in most cases, higher speed. With that said, I do think GPMR can benefit from it. The checkpoints might even be similar to the corners of MCSO.
Booster doesn't do anything new to these techniques.
I haven't done enough TASing on Max Speed to say this with certainty, but Fat Shark might be a better option due to its much greater acceleration. Should be a better choice in general for short courses. In this case, though, the Gallant and Fat Shark should perform similarly.
Thinking about it Fat Shark really is probably the better option if one can get the a shiftboost chain quickly (about at the first turn, which Gallant can do).
However it loses more speed through turning, strafing and benefits less from sideattacks and has a weaker strafe+MTS which will make getting the first shiftboost harder, which is the reason why I considered Gallant in the first place.
The first boostplate may help it to get enough speed though and considering it gets more speed from shiftboosts then I think it should be doable.
Also it's turning is also sharper which will come in handy.
So I will test a little with Fat Shark first I guess.
Thank you, Mr. Mugg. I'm waiting with Story Mode stuff until Dolphin becomes reliable enough for a full-game TAS. From what I remember, there were two or three issues that were too severe for a full-game commitment.
2013 issues I wanted to test in 2015 with Dolphin V4.0-4480:
I only got around testing #1, which was still an issue. I didn't bother testing more beyond that, but if none of these issues exist (and nothing new is broken), then a full-game TAS can be started. I'll try to run my next Time Attack TAS off a .DTM file to see if issue #2 has improved.
EDIT: By "full-game" TAS, I mean Story Mode on Very Hard.
TAS of Port Town - Aero Dive in 0'21"363 - (09"745 + 06"260 + 05"358)
Total work = 150 Hours, 62000 re-records !
Lap 1: 79H, 33000 re-records
Lap 2: 37H, 17000 re-records
Lap 3: 34H , 12000 re-records
I started working on this back in December of last year. Took a lot longer than I expected, due to the amount of testing and new stuff I discovered along the way, but I'm happy with the level of research and optimization that I've decided to settle with.
First off, I wanted to TAS PTAD in particular, due to the amount of rails that can be hovered above here. I wanted to test my theory on Airborne Shift Boosts (ASB), however, as it turned out from a lot of testing, ASB is actually not possible. This suggests that only certain types of rails or track edges allow ASB to occur. This will obviously need further testing, but so far we can conclude that Sonic Oval (and probably other Mute City) types of rails allow ASB. Port Town Aero Dive does not.
Because ASB didn't work out, I decide to do the next best thing, which involves abusing the collisions from rails. Due to using a memory viewer for this TAS, I actually noticed a few things I had not realized before. At first, hitting rails at a pretty specific range of angles worked out pretty well, but during Lap 2, I noticed that you can cancel the deceleration caused by the collision, but only if the accelerator is activated on the frame after the collision. At really high speeds, it's even possible to take some advantage of this upon colliding with just the track surface, rather than the railing. The main purpose of doing this is that we can avoid sacrificing speed and time caused by high-decel actions, such as lifting the Y-axis of the machine prior to where we plan to make contact. The tech itself is not new, as I first discovered and demonstrated the use of it in my former MCTR Snaking WR of 30"661 (see the MTS which is intentionally cancelled with the wall hit). Back then I did not call this tech a specific name, but I have now decided on a better name for it, which I prefer to call "Collision Cancelled Deceleration", or CCD for short.
But that's not all. Another new tech discovered during the making was "Momentum Throttle Air Shaking", which is a slightly adjusted version of Shaking on the ground. The major deal here is that it reduces the decelrate to a minimal linear rate, which can be highly abused at the extreme speeds we're getting here.
Lastly, there's Space Shaking, which involves performing Shaking in the air while holding the accelerator. This is actually not included in the TAS, because this tech is arguably within the realms of Space Flying, due to the possibility of infinite height gain.
With that said, I did make a short video demo of it, which you can watch at: https://www.youtube.com/watch?v=2khDL-7FDVs
The effects of Momentum Storage (MS) became more apparent than ever with the new Shaking tech, and as a result, I will need to revise the description of it slightly. Technically speaking, you don't actually "gain" speed from Momentum Storage, the speed is simply stored if compared to neutral movement. It's actually the action of having an active drift (Shaking line) that's reducing the speed below the machine's true speed. This is similar to MTSes, where the speedometer during an MTS is actually the action of the machine + machine speed. Another example would be a BS turnaround, where the speed can go down by several thousand km/h, but still pop back up to 8000km/h+ when the turn is complete. In the case of the MTS, though, the speed of the action is above the true machine speed, so not considered as "storing" if compared to neutral travel.
* These are the "Key Checkpoints" where clusters of checkpoint planes basically meet. Visit the link further below to see more details on how checkpoints work, this is a simplified explaination of it.
* Also, the coordinate values above are not 100% accurate, but it's close enough for our purpose. The same applies for the map, because it was quickly edited by hand, but it should still provide a good idea about how the key checkpoints dictate the route involved here. Note that each square on the course map preview is 100m^2 (in-game units in "m" meters). The Key Checkpoint lines drawn on the map are actually vertical planes, but were left as lines, because it's not important for our visualization.
Check 8 (6.5) in the image is actually a conditional checkpoint that occurs because more than 9 checkpoints were taken out of order, which is the technical limit. We never passed Key Checkpoint 7, so progression gets stuck at the pink line / Conditional Key Checkpoint 6.5 (if attempting to make contact with Conditional Key Checkpoint 8.) The game sets a distance limit that can be accumulated from this point before the course distance will no longer progress upon track contact. Attempting to make contact with the track any further beyond this limit will cause the machine to explode upon contact. This limit is calculating the accumulated "intended track path" distance, colored pink in the image. This calculation includes backwards distance until a certain point, as if we're backtracking. That's why the section colored in pink is further behind the point where we did our BS turnaround in the air. Remember, the game will claim we're at Conditional Key Checkpoint 6.5 if attempting to make contact with the other side of the track section (Conditional Key Checkpoint 8.) The accumulated distance will be calculated upon contact according to this logic. According to memory, this distance limit appears to be ~1015m for PTAD, which was actually tested at another track portion of this course. I can almost swear this limit was a little higher than that with the Lap 2 route of this section, so I should probably look more into the memory of this before claiming that ~1015m is the universal conditional checkpoint limit for the entire course. With that said, the section of the map colored in pink is ~1000m, just to give you an idea of how far that actually is visually. This conditional shortcut was done on all 3 laps, with Lap 2 having the most extreme case of it. In Lap 2 you don't even see the machine land within the distance requirement. Now you may already be asking, "wouldn't the machine explode from landing beyond the 1015m limit?" It depends on how you define "land". I prefer to call it "contact", rather than landing, because the checkpoint system only requires you to make contact with the gravitational pull of the track surface. That's why the machine did not explode, even though it never landed on the surface of the upper-part of the track. It did make the required contact with the gravitational pull, which allows further progress.
The last part of the route is the red area near the finish. This is a range of successful broken down finishes. The accepted coordinates for a finish to complete from our initial broken down position are the following:
And again, slightly rough accuracy on the coordinates here. The Y-axis plane extends infinitely in negative direction of the axis, which means you can go as far to the left as you like and still complete the lap. Z-pos must be ~0 or above, while X-pos is the actual finish line plane.
In the TAS, an initial speed of 9989.95km/h was reached with the broken down finish. This is the theoretical speed limit, so not much to complain about in that regard. The traveling angle can be slighly more optimized with a different approach angle. The theoretically perfect position to aim for are the coordinates mentioned above. In this TAS, the coordinates were not far off (frame after crossing finish line):
Visual display of Y = ~400 and Z = ~0 :
A few years back when I made the Sonic Oval TAS, it wasn't obvious whether the shortcuts included in it fell within the Space Flying category or not. What you're seeing in this TAS is checkpoints taken to more extreme levels, similar to how we do real-time time attack on Mute City Serial Gaps in both Max Speed and Snaking. What's important to mention here is that we're not really "skipping" checkpoints, but rather taking them partially out of order within certain limits defined by the game. If a checkpoint portion is skipped, a conditional checkpoint occurs, which I have already explained a little bit about in the section above.
This whole checkpoint system is fairly complicated, so instead of me listing every detail about it here, check out the more in-depth research done on this topic by Mr. Yoshifan:
The same concept documented there can be applied to this TAS.
Average Speed Data
Here is a display of speed data that I quickly compiled:
* A-Speed = Average Speed (of the in-game speedometer)
* Fixed Speed is the average speed with 10k+ km/h frames reduced by 1/2. Every first-frame instance of a Shift Boost should have its value adjusted by 1/2. I did not adjust SB instances below 10k km/h, due to not paying attention to where those SB's were at while dumping the data.
Yes, as it turns out from viewing the memory more carefully, you don't actually travel at the broken speed above 10k km/h. Speeds above 10k km/h are actually physically traveling at 1/2 the speed displayed by the speedometer. What this also means is that 9989.99km/h is currently the highest known speed limit (in actual traveling distance, rather than raw speed value). Any higher than 9989.99km/h will cause the speed to overflow and reset back to ~0km/h, while any speed allowed above that (for 1 frame) is inaccurate and instead 1/2 of what the speedometer says. Finally, a few may have noticed that the speedometer during the race said 9989km/h at the peak-speed of the broken down finish, even though the speed was technically closer to 9990km/h. This is simply because the visual speedometer will always truncate the floating point value down to the nearest integer. This makes the visual speedometer a very slightly less accurate display of the speed compared to the raw internal value.
Update (03.03.2020) I finally got around to look through the rest of the data here, and as I had suspected, it's not only 10k km/h frames that are actually traveling at 1/2 of their displayed speed. It turns out that every first-frame instance of a Shift Boost behaves this way. So... does this mean the speedometer is a total hoax on the first frame of a Shift Boost? Depends on how you look at it. As far as using it as a display of our speed on that particular frame? Yes, it would be inaccurate. However, we know that the speed on the next frame is indeed effected, as well as accurate according to the speedometer. This is because the speed outcome of the Shift Boost (which is determined on the next frame), is mostly dependent on that hidden (yet-to-be utilized) ~x2 multiplied speed from the initial frame. In other words, the finalized speed outcome is updated to the internal machine speed 1 frame later than usual. This is important, because it explains a lot to why the game even allows this one exception where the speedometer can exceed 9989.99km/h for only that 1 frame, since it's still 1 frame behind the truly up-to-date speed. By the way, with this understanding it should also mean that the speedometer limit (for 1 frame) past 10k km/h, should "in theory" not be able to exceed: 9989.99km/h x 2 = ~19980km/h. This seems to be the case from my testing at this point, although it has yet to be confirmed. The image below is the highest speed I've ever seen the speedometer reach (for 1 frame) so far:
* The underflowed speed glitch from hitting a mine at ~0km/h is yet another exceptional case of exceeding the speed limit. Although details regarding that won't be covered here.
The possibility of a future V2 TAS
This TAS is crazy fast, but it's actually improvable. This is indeed due to the discoveries of new tech and strategies along the way. Most of the time that can be reduced here with my current knowledge is naturally within Lap 1 and Lap 2. I estimate that the V2 lap splits would end up around: 08"8 + 05"8 + 05"3 = 19"9
I said I would upload this TAS tonight, and I'm quite sleep deprived from trying to get everything ready for publication here, so bear with my spelling and possibly other mistakes in this forum post (lol). Will probably adjust and correct a few things soon, too.
OK, just tested some stuff and updated this post accordingly. Should be more accurate and better explained now. If you read my post prior to the 3rd of March, I suggest giving it a read once more.
|"Patience is useful in any moment"|
Amazingly, the replay file does sync on console. That was actually one of the first things I tested once it was finished, hence why the YouTube video description mentions it as "console verified". Sounds to me like someone "might" want the replay file here? If you want, I can get the file hosted on my website and then add a link to it here once my next website update is made.
|"Patience is useful in any moment"|
|Index » F-Zero GX » Tool-Assisted Speedrun(s)||
Goto page Previous 1, 2, 3, 4