RTA timing ends on Frame 3267 3258 3231 (see edit), the final necessary input frame.
ENCODE/PLAYBACK INSTRUCTIONS:
- Required arguments: "--no-gui".
- File SHA-256: 150820E4EE058F833BFDF06199FC0C6633104A13C019041651EFB2D1BBBC19AF
ERRATA/ISSUES:
DESCRIPTION: TIME TO UNLEASH THE CHEESE.
- STEP 1: Play the game until Stage 4.
- STEP 2: Hold down the mouse button.
More seriously: I was going to do a "P+Gless" run in order to
not get this kind of end result, but an offsite TASer already
beat me to it, so here we are. Similarly to TiTOL2, speedrun convention has it timed based off IGT, with rampant pause abuse for time shaving; unlike TiTOL2, this game's pause abuse doesn't even hypothetically offer any RTA timesave, so it's been totally set aside for this recording. And because of this, I think this might be my first movie that is 100% truly, down to the individual frame, unimprovable, which is pretty sweet. And of course the rerecord count is only
30, which is just stupid (and hilarious).
EDIT: FORGOT A 9-FRAME TIMESAVE ON STAGE 3, DAMMIT! Updated movie in userfiles
here.
EDIT EDIT: More timesave, but there's still an apparent .12 IGT disparity between the external video and this recording, and it might be impossible to tell where that disparity comes from or if it is actually real in RTA terms without examining the recording itself. Hmmmm.
EDIT EDIT EDIT: I just noticed that A: the external video appears to be running different quality settings, judging by the lack of motion blur, and B: it does some prep stuff in the menu, such as deleting the save and visiting the credits, which both could explain the IGT disparity and also loses time over my any% run regardless.
This is an interesting case, which requires some explanation for this judgement.
Firstly, what is this category? For our purposes, this seems to fall squarely on our fastest completion category. For the SRC community, this equates to their
Any%, Pauseless category.
The Pauseless part of the category is interesting, in pausing is used in the SRC community's
Any% category. This is "faster" by their measure as abusing pausing can allow for the IGT to be paused during stage transitions. This however does not save any time RTA wise. In fact, SRC runners can abuse this to effectively "frame advance" in stages too. The SRC times by IGT, rather than RTA, so this ultimately "saves" time in their regard.
However, for TASVideos, we judge based on the "gameplay" time. Pausing here could likely be used in order to shave off IGT time (for the stage transitions), although it would ultimately be doing so while having the same RTA time. In this case, it doesn't save any actual gameplay time, as it's just stopping IGT during periods of no player activity. Although whether to pause or not could be argued to be a stylistic choice, so movies abusing pausing and ones not pausing could likely obsolete each other in this regard.
Now that the category is established, the main issue with this TAS comes to light:
This is the current world record in SRC for this category. This record was set 2 years ago from this submission's submission. Given that we have IGT, we should expect this submission to beat (or at least tie) this record by IGT, as per the rule that submissions should
beat or tie all known records at the time of submission.
However, this ends up not being the case, as this record beats this TAS. This submission has an IGT of 1:14.475. The SRC record has an IGT of 1:14.375.
(To be clear, the submission's encode (at the time of writing this) is for an older movie, so the IGT I mention is not the same as what you find in the encode).
While it could be possible there's something weird with Ruffle causing a difference, doing some research leads me to believe this is not the case, and rather this is coming from plain suboptimality. The SRC record abuses a fullscreen window in order to move the mouse outside of the typical range a native resolution sized window could. This allows for a faster Stage 28, ultimately pulling ahead of this submission. This can similarly be done in Ruffle by just abusing out of bounds mouse movement in libTAS. Given this, it should be expected that a submission should abuse out of bounds mouse movement to match the SRC record's timesave.
As this is not done, this just leads this submission to be plain suboptimal, and so unacceptable.
There are some other details regarding the optimality of this submission. The ".12 IGT disparity" mentioned by the author is from something different, and ultimately is also just another plain suboptimality. More details can be found in my post
here.
Rejecting.
